Beagleboard Xm

But obviously I have no idea when exactly this happens during initialisation.

Neither do I. But it’s certainly sometime after “HAL initialized” should be output.

And I don’t know how the original BeagleBoard behaved on the serial port, because I never had the appropriate cabling to try it out.

It certainly behaved properly with all the HAL-produced debug output. But I’ve always had difficulty getting RISC OS to interact with the serial port properly (whether on a RiscPC, Iyonix or BeagleBoard) so I haven’t confirmed that the HAL_UART* functions that RISC OS uses to interact with the serial ports work correctly. AFAIK the UART hardware hasn’t changed on the AM/DM37xx (beyond the addition of a 4th UART), but it’s possible that something which used to “work” before now fails and corrupts the output. Or the UARTs are fine and something goes wrong elsewhere which just happens to call the HAL’s debug output function with a bad string pointer :)

Is the initial configuration of RISC OS on the Beagleboard XM predictable? For example could it be the default ‘2 stop bits’ RISC OS setting that turns the serial output into garbage after ‘HAL_Init’ is received? I can try some variations on the remote terminal but specific information would be helpful!

could it be the default ‘2 stop bits’ RISC OS setting that turns the serial output into garbage

Extremely unlikely. Normally serial receivers only need to see half a stop bit, regardless of setting. The transmitter obeys the setting – but it’s identical to transmitting the characters with a tiny pause between them.

Well until we can sort out why RISC OS won’t start, I’ve built a case for my Beagleboard based on the Maplin Ice Blue case N09GC - there’s room for the power supply (Farnell 1279547) and the USB, Network and HDMI connectors fit neatly against the sides. There’s also room inside for a Samsung USB connected 500Gbyte HDD (if RISC OS will recognise it).

My XM is scheduled to arrive today by UPS…

I’m expecting mine this week! I’ll get a straight m/f RS232 cable too, as my RiscPC isn’t USB equipped. (Unless I try a m/m null modem adapter meaning I could presumably couple with my existing null modem cable used with the original board.)

Meanwhile is there anything I can do (using my Beagleboard XM plus serial cable) to test? I have tried switching the remote computer to various different serial speeds to see if the garbage after ‘HAL_Init’ (the debug output from riscos trying to start) would suddenly turn into meaningful text. I suspect there’s not much I can do until someone produces a different ROM image to try.

What is the plan? Is a different ‘XM’ ROM image being put together? Even one that will just produce some helpful debug output to move it along? Or even one that can be loaded manually (fatload mmc 0 0×810000000 riscos) with breakpoints added (fatload mmc 0 0×8100DABC return) at different points before issuing ‘go 0×810000000’. Hence trying more and more code until it falls over. But to do this I would need to know where to put the breakpoints (presumably MOV PC,R14)...

Try this new ROM image here. I’ve tweaked the code that calculates the clock speed so that it matches the behaviour of the latest version of u-boot (the old code used to temporarily disable the system clock divisor, which could be bad), and added a little bit more debug output.

That’s better (but not actually giving a visible screen outout because the monitor (Sony SDM-M61) says ‘out of scan range 08.12 kHz 15Hz’.

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)
Beagle xM Rev A
Reading boot sector
Loading u-boot.bin from mmc

U-Boot 2010.03-dirty (Aug 19 2010 - 02:49:51)

OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz,
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MB
NAND:  256 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial

Probing for expansion boards, if none are connected you'll see a harmless I2C er
ror.

No EEPROM on expansion board
Beagle xM Rev A
Die ID #5c6200001bf00000015739ea0703401e
Hit any key to stop autoboot:  0
mmc1 is available
The user button is currently NOT pressed.
reading boot.scr

120 bytes read
Running bootscript from mmc ...
## Executing script at 80200000
reading riscos

4194304 bytes read
## Starting application at 0x81000000 ...
OMAP3 HAL init
Board config=BeagleBoard
HAL_Init
sys_clk=00c65d40
GPIO_Init
Video_Init
USB_Init
I2C_Init
Timer_Init
Interrupt_Init
GPMC_Init
nDoneARTStartUp
HAL initialised
InitCMOSCache entry
InitCMOSCache done
IMB_Full done
Keyboard scan complete
FIQ enabled
IRQ enabled
VduInit
ExecuteInit
Machine ID duff,zero substituted
KeyInit
MouseInit
OscliInit
Enabling IRQs
IRQs on
HAL_InitDevices
HAL RTC detected!
Leaving LookForHALRTC
InitVariables
AMBControl_Init
ModuleInit
OMAPVideo:
OMAPVideo: ***** Debug Session Started **************************************
OMAPVideo: DebugLib is (c) Pace Micro Technology plc. 1997-2001
OMAPVideo: System: DebugLib 0.65
OMAPVideo:         remotedb 0.10
OMAPVideo:         PDebug 0.07
OMAPVideo: Task:   OMAPVideo
OMAPVideo: Time:   Fri Jan  2 00:00:00 1970
OMAPVideo: Levels: Not specified.
OMAPVideo: ******************************************************************
OMAPVideo: Using DMA channel at f9e56c20
OMAPVideo: dss_reset
OMAPVideo: Finished module initialisation, DSS regs=f9e50000
OMAPVideo: dispc_set_lcdmode: rate=25175000 syncpol=3
OMAPVideo: hsw=96 hfp=18 hbp=46 width=640
OMAPVideo: vsw=2 vfp=11 vbp=32 height=480
OMAPVideo: dsi_pll_program_for_dispc: Changing pixel rate from 0 to 25175000
OMAPVideo: REGM=122 REGN=6 REGM3=8 REGM4=8
OMAPVideo: Fint=1857142
OMAPVideo: dsi_pll_program_for_dispc: Done
OMAPVideo: dispc_set_lcdmode: Done (0)

OK, well that’s better than it was before :)

The log output looks OK, but the monitor thinks the video clock is 4x slower than it should be. I know there have been some changes made to the DPLLs (the multiplier/divisor fields have had an extra bit added to increase their range), so if my code was being well behaved and preserving the unknown bits instead of clearing them to zero then that could explain the problem. Although thinking about it, I’m not sure if there was any space for the fields to be made wider without adjusting their positions within the registers, so if that’s the case then that could easily explain the problem.

Many thanks. Hopefully the solution will be relatively simple …

Chris – do you have a speaker connected to the board?

Yes, it says ‘Click!’ and then ‘Beep’.

That sounds about right. Although I’ll hopefully get round to fixing the click one day ;)

That’s reassuring :-) Hopefully Jeffrey’s fixes to date mean it’s now just the video clock solution that’s needed.

• Without any disk/storage attached, you should be at the command line, so Ctrl-G should say ‘Beep’ again if the keyboard is detected
• If the keyboard works and you attach a memory card, you could try accessing this and see if it flashes when you do (you might need *scsi first – I can’t remember)
• *desktop ? (Ctrl-G then shouldn’t beep unless you press F12 first)

(Note that the USB devices might take a while to be enumerated )

I tried CRTL-G but no beep.

If I interrupt the booting to get to the ‘OMAP3 beagleboard.org #’ line on the serial device (i.e. after ‘MLO’ and ‘u-boot.bin’ have run but nothing else, then the monitor says ‘out of scan 11.47kHz / 14Hz’ so is this a ‘u-boot.bin’ issue? The ‘u-boot.bin’ is as supplied with Beagleboard XM.

...is this a ‘u-boot.bin’ issue?

For info, I think the lack of agreement Gerald refers to in response to your post was this thread

I had read that thread. But the display ends up at something like 640×480 at 60Hz (which is fine) but it is 4 times too slow after ‘u-boot.bin’ (at 14Hz). Surely this is just the issue you raised about the timing registers being changed but uboot not being updated?

I can’t give any insight into why u-boot might not be working, but by comparing the TRMs it looks like the method of programming the DPLLs has changed quite significantly between OMAP35x and AM/DM37x. Once I’ve had a closer look at the docs and rewritten any relevant code I’ll upload a new ROM for you to try.

Many thanks. The ‘bug’ in the uboot is acknowledged by the designers but as the Angstrom is distributed and works OK and all that is on the uboot screen is a beagle image and nothing useful they are not planning to fix this.

OK, here’s a new ROM image

Although the DPLL programming method has changed a bit, after looking through the docs it didn’t look like it had changed significantly enough to affect RISC OS. But then while looking through the Linux sources I noticed some ‘undocumented’ (i.e. not mentioned in the BB reference manual) GPIOs being used. Specifically, there’s one GPIO for enabling USB power, and another for enabling DVI power – both of which are different on the XM than on pre-XM. And it looks like the default state of those pins at power-on would have left the affected devices in the ‘off’ state (or in the case of DVI, an indeterminate state since the GPIO would have been configured as an input instead of output – which could explain the bad signal your monitor was getting)

So I’ve now added code to set those GPIOs to their correct values depending on the machine type.

I’ve also enabled the debug terminal; this means that, apart from when in the desktop, RISC OS will ignore keyboard input and accept characters through the serial port instead. Character output is also echoed to the serial port. So if USB (or video) still isn’t working right you can at least poke around at the command line to try and see what’s happening (e.g. use *usbdevices to check if anything other than the EHCI & MUSB root hubs have been detected)

Having had some time to play over the weekend, I can get the BB booting using the latest (4th Sept) ROM - at least, I hear the traditional beep, but nothing on screen that the monitor will latch on to. I’ve tried typing blind to change resolution or get at a desktop, but nothing seems to happen. What do I need to access the BB serial port from my Iyonix (USB to RS232 or RS232 to RS232, null-modem or straight?) and what is the best terminal program to use? I’d like to get confirmation as to how far it is getting and to see the results of my typing at least! Works OK with the Angstrom SD card, so it’s not the board itself or the cabling.

You need a straight RS232 cable. As a terminal program, I used Connector on my Risc PC, but there is no publically available IYONIX version of Connector. I have one on my IYONIX, but I am not sure of its state – it was changed from Desk to DeskLib for 32bit compatibility and seemed to be a bit unstable, but I can’t find the changed source…

If you have Hearsay or ARCterm (don’t know if the latter was 32bitted), you should be OK. Don’t know if Nettle or RiscTerm can communicate with the serial port.

Maybe one of the old BASIC terminals could be used (Grapevine, ARCterm 3.1)?

Hmmmm. Seems to be another big hole in RISC OS software availability…I once developed a terminal emulator when BBS systems were still state-of-the-art and 2400 bps modems were considered fast, but basically dropped it when ZAnsi became available.

What do I need to access the BB serial port from my Iyonix (USB to RS232 or RS232 to RS232, null-modem or straight?)

Try either this straight m/f serial cable or a USB-RS232

...and what is the best terminal program to use?

Connector v.1.03 doesn’t work but v. 0.83ß works on the RiscPC. Was a 32-bit version of Connector ever tracked down?

Trying the latest ROM (4 Sep 2010 from J.Lee above) gives:

Texas Instru X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)
Beagle xM Rev A
Reading boot sector
Loading u-boot.bom mmc

U-Boot 2010.03-dirty (Aug 20 2010 - 20:50:46)

OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz,
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MB
NAND:  256 MiB
*** Warning - ba or NAND, using default environment

In:    serial
O serial
Err:   serial

Probing for expansion boards, if none are connected you'll see a harmless I2C er
ror.

No EEPROM on expansion board
Die ID #5c620000000015739ea0703401e
Hit any key to stop autoboot:  0
OMAP3 beagleboard.org # mmc init
mmc1 is availablOMAP3 beagleboard.org # fatload mmc 0 0x81000000 riscos
reading riscos

4194304 bytes         
OMAP3 beagleboard.org # go 0x81000000
## Starting application at 0x81000000 ...
OMAP3 HAL init
Board config=BeagleBoard
HAL_Init
I2C_Init
GPIO_Init
GPIO  for XM

a ‘beep’ but the monitor displays ‘no signal’ (using the previous ROM it displayed ‘out of scan 14Hz’).

So I’ve now added code to set those GPIOs to their correct values depending on the machine type.

I take it you’ve already seen this GPIO selection info (or similar elsewhere). However, as it’s a hardware page, perhaps not too relevant after all.

Edit: The clock frequency is also scaled up from 96Mhz to 200Mhz ... which is a different factor to that already referred to, if I followed it correctly. (Or is that just SGX?)