Beagleboard Xm

i get a red background when i get to the risc os 512mb cortex-a8 etc is this normal???

It should be a black background. Have you been able to try any 32K or 16M colour modes yet? If the background’s coming up red at boot then it might be that they’ve changed the way the palette hardware works. Which would also explain why everything’s fine in Linux, since I doubt they make much use of palettised modes.

It’s the same in all modes not forgeting that it will not boot to ris os without first booting linux to setup the usb

I’ve uploaded a new ROM image here – let me know if you see any improvement. Although I haven’t been able to find any bugs, I have changed the GPIO setup to be a bit more rigourous, and to initialise things which were previously being left alone.

Also, which mlo & u-boot are you currently using? If I use the ones from the 3.3 or 4.25 images then RISC OS won’t boot, because u-boot is looking for a uenv.txt file. So I’ve created a uenv.txt with the following contents, and am using that:

uenvcmd=fatload mmc ${mmcdev} ${loadaddr} riscos;go ${loadaddr}

Great work Jeffrey this image works with 4.25 mlo & u-boot with the uenv text file i would like to post an sdimage but not sure if i can??? so people with new boards will not have a problems.
Thanks again for all your hard work
regards rob

i would like to post an sdimage but not sure if i can???

You could give it a go via the Wiki, perhaps linked as I was thinking of doing.

Sent a copy to the webmaster to put on the download page

So all the problems are sorted then?

Tonight I’ll check in the fixes and update SDCreate to deal with the uenv.txt file.

Yes great Jeffrey thanks, been moving over some software to try & i have also been talking to Nufront about getting a couple of NuSmartTM 2816 boards for a separate interactive display project. it would be good to get Risc os running on these but being 2GHz dual-core ARM Cortex-A9 processors that a project for another day.

Jeffrey, Is there a way to detect which board you are running on ?
I ask as I would like to add the GPIO mapping for the other boards to the module first created by Peter van der Vos.
Sorry if this has been covered before….

There’s no official/easy way, no. I think the best thing to do would be to add a new HAL device which the GPIO module can look for.

Jeffrey, how safe would it be accessing the SRAM copy of the board structure that you copy on boot ?
Could this be a simple way of telling which board we are running on ?
A quick test prog shows the data is still there and untouched.

Not particularly safe, since I don’t want to restrict the HAL to storing the data there, and to make sure it’s all done in a backwards-compatible manner.

What kind of info do you need? Just the board type & revision? Some time in the next week or two I’ll hook up a new HAL device for you to use.

Yes, its just so I can match the GPIO mapping to the actual hardware on board.
Is there any plans to actually use the SRAM for anything ?
The data seems to be preserved over a software reboot, but not a hard reset as in the reset button.

Something on my todo list is to get suspend-to-RAM working, mainly for the Pandora & Touch Book. As I understand it the best way of doing it is to store a small piece of recovery code in SRAM so that the main SDRAM and most of the rest of the SoC can safely be put to sleep.

The SRAM also has much lower latency than SDRAM, so if something like an audio or video codec would benefit from a small area of faster RAM then it would make sense to add new APIs to RISC OS to allow programs to claim and use the memory.

IIRC Phoebe had SRAM – it might be worth a quick search of the Ursula branch kernel to see if anything got as far as being implemented.

Has anyone got a copy of Jeffreys OPP.BAS program they can send me ?
A few weeks ago I was taking my system to work, and the inevitable, oop’s I’ve dropped the hard drive, happened.
Not everything was saved to two locations, so trying to rebuild what I had before.
webmaster@tankstage.co.uk if you can.
Also on another day, I plugged the wrong power connector into the xM.
Even though the 12v adaptor was unplugged, and had been for about a day, it still fried one chip (TPS2141IPWP) on the board.
Plugging in the correct adaptor and the chip developed a small chimney and started smoking!!
A quick visit to Farnell’s website and a replacement ordered.
Luckily its alive…

Sent.

Thanks Andrew.

By replacement (above) I mean replacement chip (as I do have a spare xM anyway)

Has anyone got a copy of Jeffreys OPP.BAS program they can send me ?

You do know that that program has been redundant since March, don’t you? (Unless of course you’re just using it as a quick reference for how to do stuff)

Oh, and I’ll add that new HAL device this week, I promise!

Actually until I ran it on the board and it reported a clock speed of 800mhz I didn’t…
I used to run it at boot on my previous HDD set-up pre-set to 800.
No rush with the HAL device Jeffrey.
[cheeky](how about the smart reflex stuff so we can all run at 1Ghz though!!)[/cheeky]

(how about the smart reflex stuff so we can all run at 1Ghz though!!)

It’s coming… eventually! At the moment my immediate todo list looks something like this:

1. HAL device for GPIO stuff
2. Report ROM build date in switcher
3. USB CD support
4. SmartReflex/1GHz

Plus along side that there’s the zero page protection stuff (although that can be postponed indefinitely, as long as nobody makes any big kernel changes and leaves me with a massive merge conflict), and us potentially shifting focus to make a 5.18/5.20 stable release.

I wish to communicate via serial cable (called debug?) to a BBXm, at this stage while still having the original Angstrom microSD card fitted. I have tried with both my RISCOS machines using “Connector” v0.83 and v1.03 to no avail. A short-and-dirty BASIC program showed that the Acorn serial ports appear okay. Data is being transmitted by the three machines, as I can see the ‘TxD’ line, (pin 3), drive a small LED+resistor circuit I have connected.

Suspiscion is growing that the signal levels from the BBXm are too low for an Acorn to “see”. Open circuit voltages on the RISCOS serial ports are close to 12V. While I have not been able to record the BBXm’s port voltages I suspect these will be around 5V, (TTL levels). This difference in comms signal levels seems to be a regular problem in industry, if what I have been reading off the web is to be believed.

Has anyone else experienced similar difficulties or am I barking up the wrong tree? Suggestions, solutions, work-arounds, (or point me to where I should have looked first before posting this), would be most welcome.

One possible solution, assuming I am on the right track, is to use a MAX232 chip which cleverly does all the signal level conversion. The chip requires a 5 volt supply, which very handily reposes adjacent to a BBXm of mine :-)

In a related matter, does anyone know what value to set R1 to in SWI “OS_SerialOp 5” or “OS_SerialOp 6” in order to access the baud rates above 19200. The PRM3 I have does not cover this info.

My recommendation is to use a Windows machine running Tera Term Pro (free to download) set to 115200 baud rate 8bit no parity 1 stop bit. That is if the purpose is simply to debug something on the Beagleboard. If however you just want to experiment with setting up a serial port to an Acorn computer then a complex and interesting solution will be what you want and a circuit to do some level shifting looks as if it would be a lot of fun.

Thank you Chris. The in-constant-use ‘family’ PC is in another room and it would mean aquiring a USB to RS232 convertor …, whereas all the ARM devices are very close to each other and I am their only user (ah, bliss). Besides I don’t mind having a wee tinker with some electronics and writing a little simple software.