Beagleboard Xm

Hi all – long time lurker, first time poster.

I was informed today that my xM is on the way – I wasn’t expecting it for a couple of months yet. I’ll be happy to test things out as and when necessary. I’ll just need some pointers on where to start to get it up and running and I will be able to compare results against my Iyonix.

Bad news for anyone hoping to get 1GHz right off the bat – it looks like the version of u-boot they’re using doesn’t alter the CPU clock frequency from the default (I think the default will be 800MHz). Also the DM37x datasheet doesn’t seem to have been released yet, but judging by the contents of the AM37x datasheet it looks like we’ll need a smartreflex driver in order to (safely) run at 1GHz.

Grahame – there is a getting started guide on the wiki, but I shan’t link to it yet since it contains a few instances of glaringly obvious inaccuracies/bad advice, and it needs updating for the -xM anyway.

...a few instances of glaringly obvious inaccuracies/bad advice…

Maybe these cropped up in the collation of previously conflicting pieces of advice – and recent ROM changes probably render the OTG/MUSBDriver note out-of-date too. Anyway, it could probably do with tidying up when specifics are added for the -xM.

My XM is scheduled to arrive today by UPS. I must say I am expecting it to run at 1GHz (as advertised) but I know America has no consumer protection legislation and is therefore more unrestrained about what it promises!

Is there any testing I can do? I shall start by checking hardware compatibility (i.e. without RISC-OS present) for the display (a Sony SDM-M61) and hard drive (500Gbyte SamsungPortHDD, Maplin A43KB) and ost the results. Is it worth loading the non-XM ROM image and testing it?

Is there any testing I can do?

Checking that the USB hub works properly in RISC OS would be a good start. AFAIK it should work fine, but it wouldn’t surprise me if there’s an obscure bug that will prevent it from working :)

Is it worth loading the non-XM ROM image and testing it?

Yes. AFAIK the current ROM image should work fine, apart from the video driver thinking that you’re running on an ‘old OMAP’ and so limiting the maximum porch/sync timing values.

Also in order to get the ROM to boot you’d have to make sure that your SD card is set up correctly (formatted in a way the OMAP boot ROM understands, and containing x-loader, u-boot, and the RISC OS boot.scr and ROM image). I’ll upload a rough version of my SD card creator tool tonight, but if you want to try building an SD card yourself you should find the right versions of x-loader (the ‘MLO’ file) and u-boot (‘u-boot.bin’) on this page. Copy them to the SD card without renaming them and hope that your computer hasn’t done anything to upset the boot ROM ;)

Grabbed my BeagleBoard-xM from the hands of the UPS guy one hour ago. Unfortunately I can’t start unpacking and testing it till tonight. I don’t even know if the package really contains a BeagleBoard ;-)

Have ‘quick-formatted’ an SD card (under Windows XP FAT32) and copied ‘MLO’ ‘u-boot.bin’ ‘boot.scr’ and ‘OMAP3Dev’ onto it. But I just get a blank screen from the Beagleboard. Put the supplied SD card back in and it’s fine (in Angstrom or something like that, displaying a ‘log-in:’ line).

‘OMAP3Dev’

Did you rename the ROM image to riscos ?

OMAP3Dev

Needs to be renamed to ‘riscos’ :) And make sure you’re using the beagleboard-specific boot.scr from the OMAP3 ROM zip file (renamed to boot.scr)

I am doing all those things. Screen still blank. Remove SD card [with the four files on it including ‘riscos’) and install supplied SD card and press ‘reboot’ button and lights flash and I get the Angstrom login OK. Any ideas please?

I am doing all those things. Screen still blank. Remove SD card [with the four files on it including ‘riscos’) and install supplied SD card and press ‘reboot’ button and lights flash and I get the Angstrom login OK. Any ideas please?

Is the screen in range (i.e. the monitor is happy with both horizontal and vertical scan rates) and still blank, or blank because the video is out of range?

Try connecting a serial cable and see what’s happening, or try copying the boot.scr & ROM image onto the Angstrom card (as long as you don’t mind overwriting it!), or try reformatting the SD card using the steps on this page, or wait until tonight when I can give you my SD creator tool.

I probably had the same problem after formatting under Windows(XP)

Try using the HP SD formatter tool and then copy MLO first (I don’t know the name right now but it’s in the forum) this worked for a small 64MB SD card for me.

If this still does not work, try making the FAT32 partition smaller, I had the same problem with a 2Gig SD card that did work with a smaller FAT32 partition – (but I don’t know any windows tool for this)

I have prepared an SD card using Ubuntu Win32DiskImager downloading the beagleboard-validation-201008192024.img and then copying ‘boot.scr’ and ‘riscos’ onto it (overwriting the ‘boot.scr’ from the validation image).

Pressing ‘boot’ on the XM and the two LEDS next to each other both come on and stay on. Screen stays blank. [Normal start up one of those two goes off soon after switch on].

In that case, it sounds like you’ll have to wait until someone with a serial cable turns up.

Serial cable gives the following:

 ...
 reading boot.scr
 120 bytes read
 Running bootscript from mmc ...
 ## Executing script at 80200000
 reading riscos
 ** Unable to read "riscos" from mmc 0:1
 ## Starting application at 0x81000000

In that case, Windows has decided to do something to screw you over by not calling the ROM image ‘riscos’. I’ll try and get a rough version of the SD creator uploaded in a little while, but if you want to try booting manually you can do this:

• Stop the autoboot by pressing a key when it says
• Enter ‘mmc init’
• Enter ‘fatls mmc 0’ to find what the ROM image is really called
• Enter ‘fatload mmc 0 0×81000000 <foo>’ to load the ROM image
• ‘go 0×81000000’

Hmmmm. I am getting very confusing results. Tried to copy RISC OS onto a 2 GB, Fat16 formatted card. Screen stays black. Added a serial cable to my Risc PC. Got as boot output “DAASBAUAUA”. Thought that perhaps my serial setup was somehow fishy. Read somewhere that you need a nullmodem cable configuration, but the serial port on the Beagle xM looks more like “connect a standard cable”. Refitted the original card. Got a lot of good serial output on my Risc PC, starting with the TI bootloader and ending with a nice login.

Thought that perhaps the card needs to be 4 GB and/or FAT32. Took a 4 GB FAT32 card and copied over the necessary files. Same as before: “DAASBAUAUA”. In fact, the bytes sent were 04 01 01 13 02 01 15 01 15 01.

Not sure what that should tell me, but I guess that’s what you earn for being an early adopter ;-)

Each file I copy onto the SD from Windows appears only when the card is interrogated by Windows. Copying the file ‘riscos’ but named as one of those (e.g. ‘user.scr’) already present but not required appears to work under Windoze. Then rename it ‘riscos’.

On the XM the files originally present are seen, plus the amended ‘boot.scr’ but any displaced or newly copied file is invisible on XM. Put SD card back into Windoze machine and all the files are shown. Puzzled. The must be more than one file allocation table on the device.

OK, well here’s that rough SD creator program: http://www.phlamethrower.co.uk/riscos/sdcreate.zip

Since it’s the first version it isn’t entirely foolproof, but as long as it doesn’t fail with an error it should leave you with a functional SD card. Check the !Help file for instructions.

Got as boot output “DAASBAUAUA”.

Interesting…. I’ve never seen that output myself, but since everything works OK with the Angstrom SD card it’s reasonable to assume that “DAASBAUAUA” is what the bootloader sends when it’s trying to boot from serial. So it doesn’t look like your card was bootable either :)

Tried again – reformatted the SD card under Windows and just copied the four files onto the SD card.

All now show as present on XM but it hangs after loading the RISCOS ROM thus:

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
              ## Starting application at 0x81000000 ...
OMAP3 HAL init
Board config=BeagleBoard
HAL_InitEø`(±(Ç2©-§Nø é®£Nè*+×:é®£Nè*«™¢¨¢cç<~™¢¨*pÉ-‡­++Á*§6Á%BªÉ)™j  &(ç"J6'á
'·*é.0"6št¤<Xr‘(§4ç-—.vª46§t¤*©n ¢É-G|xrJ*Åzw!ö2Jz™h¤N0f±¢ü`'±('&Ç2dNø ¨"!*§r§

Now what??

Now what??

Panic :)

The next thing that should be printed after “HAL_Init” is “HAL initialised”, which means something has gone wrong between the HAL printing HAL_Init (at HAL.OMAP3.s.Boot line 519) and return controlling to RISC OS (which is where “HAL initialised” will be printed).

I’ve uploaded a ROM image here which should give some more debug output. Or you can always try debugging the issue yourself if you’re feeling brave :)

OK I’ve tried Panic fear. The ROM image you provided gives the same output on the serial port (perhaps a bit more of it than before though) – this looks like transmitted information that is not at the correct 115200 baud rate? Does RISC OS default to a different setting perhaps? Or is the 800MHz/1000MHz clock affecting its timing?

I’m not sure what baud rate RISC OS defaults to, but I’ve never had problems with RISC OS messing up the default settings. I’d also expect there to be some more useful debug output before RISC OS changes anything (although I guess it’s feasible that RISC OS could change the settings while the TX FIFO still contains data, causing the data to be lost/corrupt).

Or is the 800MHz/1000MHz clock affecting its timing?

Possibly. Right after printing HAL_Init the HAL enters some code that attempts to calculate the system clock rate and set up some of the clock generators. So it’s possible that code has gone wrong somewhere. But there are so many seperate clock sources in the OMAP that I wouldn’t expect that code to affect the UART clocks.

I’ll have a closer look at the TRMs tonight and see if there’s anything UART/clock related which could be going wrong. I can also stop RISC OS from using UART3 (i.e. the BB’s serial port)

I think RISC OS switches the baud rate and other parameters (number of data bits, if parity should be used etc.) according to its CMOS settings. I remember

*configure baud

*configure data

But obviously I have no idea when exactly this happens during initialisation. 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. But fact is that the xM with the latest ROM build only displays grzmzk after “HAL_Init”.