Beagleboard Xm

f9e4ff0c: 07e18c0f dsi_pll.configuration1
f9e4ff10: 0001210c dsi_pll.configuration2

Trevor, did you resolve the 0 bytes of riscos loaded problem – now I’ve got a serial cable, that’s where I’m at too – using Chris’ boot method (combi script).

I overcame that by right clicking on the drive letter for the micro SD card under Windows and selecting format. Then copying the files back on, starting with ‘MLO’, then ‘u-boot.bin’ and them the rest, including the file ‘riscos’. Check the files are all visible by giving the commands ‘mmc init’ and ‘fatls mmc 0’ at the ‘OMAP3 beagleboard.org #’ prompt on the serial port. You should see riscos listed with the rest. You can proceed manually from that point (to prove it is all there) with the command ‘fatload mmc 0 0×81000000 riscos’ and ‘go 0×81000000’.

Just copying the file under Windows to a SD card already prepared elsewhere can mean the file is visible under Windows but on no other system. Windows just loves not being standards compliant in so many ways.

...did you resolve the 0 bytes of riscos loaded problem...

...You can proceed manually from that point (to prove it is all there)...

New ROM image here

After staring at the docs & source code for a few hours I resorted to my old tactic of checking for any relevant changes in the Linux sources, which led me to this change. The TRM & errata don’t make any mention as to why a change like that would be needed, and the text about the DSI PLL/HSDIVIDER in the 37x TRM matches that in the 35x TRM, so it looks like trawling through source control logs (or lots of hands-on experimentation) would have been the only way to find the solution to this problem :(

Thanks, Jeffrey – I’ve got a desktop running now, using a copy of the boot drive from my Iyonix (replacing ADFS with SCSI where necessary) I can run a number of apps and utilities. I running this on a 250GB USB hard disc. I can’t get out of 640×480 so far, even with the MDF I have that is used on the Iyo and the same monitor, but that’s not a big issue right now. I had to issue the following to reach a useable desktop: -

conf. SCSIFSDrive 4

dir SCSI::4.$

!Boot

desktop

There’s some things I can do to tidy up, such as removing Geminus from the disc, but a great start. Thanks for all your efforts.

Many thanks for your latest effort, Jeffrey. It now works (nearly) fine with my xM, same screenmode as before (1280×720). One problem: Keyboard input on CLI does not seem to work – is this still hardwired to serial?

Anyway, I guess we now need to publish widely with a catchy phrase – how about “RISC OS breaks the 1 GHz barrier!”

;-)

One problem: Keyboard input on CLI does not seem to work – is this still hardwired to serial?

Yes. Once I’ve tidied & submitted my changes I’ll upload a new build with the debug terminal turned off.

Anyway, I guess we now need to publish widely with a catchy phrase – how about “RISC OS breaks the 1 GHz barrier!”

Not quite yet; we need a SmartReflex driver to be able to run at 1GHz. Luckily all the SmartReflex documentation is in the TRM this time, unlike the OMAP35x where it still seems to be under NDA.

...Luckily all the SmartReflex documentation is in the TRM this time, unlike the OMAP35x where it still seems to be under NDA.

And in your usual thoroughness, I’m sure you’ve taken a local copy just in case the inclusion is a mistake ;-)

Thanks so much for doing all this! When’s your -xM due, BTW?

When’s your -xM due, BTW?

No idea; it doesn’t look like Farnell have received any stock yet. Hopefully it won’t be more than another week or two.

The Angstrom GUI has a little widget that allows selection of CPU speed (300/600/800/1GHz) – don’t know if there’s any useful hints in there?

Many thanks Jeffrey – the latest ROM (13th Sept 2010) works fine.

Some minor glitches though. It boot straight into RISCOS but with a screen that is (just) outside the capability of my monitor at 50.84kHz / 81 Hz and so I have to type f12 and then (on the serial port) *WimpMode 21 (which gets 33.28kHz / 63 Hz). Then accepting the default AKF80 monitor, I can select 1024×768 16M and get this. I get some strange colours in 32k mode and I noticed (under the Angstrom GUI) that copying the new ‘riscos’ image from my NAS to the SD card only operated at 40kbytes/s.

Another picture here.

... but with a screen that is (just) outside the capability of my monitor at 50.84kHz / 81 Hz

Yes, I did warn you that the timings might not work right :) But now that you’ve reminded me, I’ll check what the Nvidia driver on the Iyonix does with the border values and make the OMAPVideo driver mimic that (I’m assuming it just adds the border values onto the porch values). If all goes well I’ll get everything checked in tonight.

I get some strange colours in 32k mode

The OMAP doesn’t support the pixel format that RISC OS (5) uses for 16bpp modes, so there’s nothing that can be done until someone volunteers to add support for some new pixel formats.

If you’re having trouble getting your existing MDFs to work then you might want to try taking a few of the entries from the bottom of the OMAPVideo page

... but with a screen that is (just) outside the capability of my monitor at 50.84kHz / 81 Hz

I have changed !Boot.Resources.Configure.Monitors.Acorn.AKF60 to include a few more screen sizes and have edited the last line of !Boot.Choices.Boot.PreDesk.Configure.Monitor to say ‘WimpMode 21’ and so get a visible screen with no need to intervene, just turn on the Beagleboard.

I have put EtherUSB into the !Boot sequence but am not sure how to get OmniClient and LAN Manager going – I have OC 2.15 (01-Oct-09) and LM 2.34 (01-Aug-09) – are these sufficiently recent? I put OC into !Boot.Choices.Boot.Tasks but it just gives an error ‘Task not known’.

Everything’s now in CVS, and there’s a new ROM image here with the debug terminal disabled.

This worked on ubuntu 9.10.

Save MLO and u-boot.bin from the supplied sd card. Format the sd card as fat32 with gparted. Then set the ‘boot’ and ‘lba’ flags. Copy back MLO and u-boot.bin. Then copy boot.scr and riscos.

Either way, I now have a few extra days to practice with the soldering iron before I get to try fitting the ridiculously tiny battery to the beagleboard.

Has anyone here actually tried fitting this yet? Although I’ve not yet bought/fitted a battery to my pre-xM board, at least the holes were a sensible distance apart. The -xM battery choice truly is “ridiculously tiny” so I’m glad I didn’t order one! I think it will "require a very steady hand" _¹

¹ Or a robot.

And you need to remove a tiny resistor.

I would like a battery for my BeagleBoard. I don’t want to fit it myself, so who does such work?

And you need to remove a tiny resistor.

Indeed – perhaps not quite such a tricky job as the battery itself, though. Any idea what the consequence would be of removing the resistor and not managing to successfully fit the battery? If not, I’ll check/ask on the BB group.

[Edit: The battery situation may be reviewed ]

I would like a battery for my BeagleBoard. I don’t want to fit it myself, so who does such work?

A friendly local TV repair shop, perhaps?

Fitting the RTC battery is definitely not something for the feint of heart – removing the resistor was a bit tricky, but certainly doable. Soldering the battery legs to the underside of the board was a doddle. Then I got cocky and tried to solder the top side as well – big mistake. First I got solder on the underside of the battery, leading me to think that I’d soldered the two terminals together. Then during the cleanup operation I managed to melt away part of the plastic surrounding the DC jack. And then because I still hadn’t had enough punishment I went back and had another go at soldering the top side, only to fail again. Plus at some point while sodering the underside I was definitely touching bits which I shouldn’t have been, because the red “bad power” LED flickered to life once or twice.

But the good news is that both the board and the battery seem to be working OK. After leaving the board turned off for over an hour it still had the correct time, and the battery voltage hadn’t dropped, so there don’t appear to be any shorts.

I’ve got some rough code for detecting if a battery is fitted and enabling the charger, so sometime tomorrow I’ll have a go at putting it into the HAL.

You don’t need to solder through-hole components on the top side. All the holes are plated through, so once you’ve soldered them on the non-component side, the job is done. It’s much easier than you thought.

I’m posting this in case it helps anybody else.

Good point. The only reason I tried soldering the top side as well was because the bottom joint didn’t seem to provide much stability – a gentle poke was all that was needed to push the battery to one side.

I’ve got some rough code for detecting if a battery is fitted and enabling the charger, so sometime tomorrow I’ll have a go at putting it into the HAL.

Jeffrey, is your code just writing to the BB_CFG register on the TPS? If so, might we need to be careful about adding this into the HAL, because people could have soldered different components onto their boards as a solution? For example, I might have a 2.5v supercap while you have a 3v NiMH battery. The two could need different charging currents and voltages. Just a thought!

Jeffrey, is your code just writing to the BB_CFG register on the TPS?

Yes.

If so, might we need to be careful about adding this into the HAL, because people could have soldered different components onto their boards as a solution?

Well I’d hope that people would have stuck to the batteries that are recommended in the different board hardware manuals. Or at the least, stuck to batteries that can be charged in an identical manner to the recommended ones (e.g. the 5.5mAh battery that I’ve got in place of the recommended 1mAh one)

But if you (or anyone else) think (or know!) that people might have done this, then now is the time to speak up! It would be a bit of a pain from the user’s perspective, but we can always make the RTC battery charging fully configurable.