Beagleboard and 5.27

Has anybody tried to run 5.27 on a Beagleboard-xM with success ?
I have tried a download, and a build from source, and both stall because the USB and network are not working…
Going back to 5.24 and all is fine.

I have todays ROM and latest HardDisc image , including ZeroPain module installed on my Beagleboard -Xm and it runs OK.

In fact I have made this post via Netsurf running on it.

What firmware have you got as my MLO/U-Boot and Uimage are dated 19th April 2011, how the years have passed.

I have the same MLO/U-Boot time stamps as you…
HD image from a couple of days ago as well.

Could it be board revision level as I am sure mine is a Revision C.

You could also check if there are any modules unplugged that have now changed between versions as I am sure the module order/list changed.

Also try booting with a totally clean Choices directory just to see if there is anything in there causing an issue.

Same setup as Doug, sans ZeroPain, also rev C. Firmware dated 08 Nov 2011. No issue.

Extreme long shot. The BB -xM isn’t from ROOL? I donated one with iffy USB that Steve R thought would still be useful.

Its a brand new board from Mouser…
I did get it to boot a couple of times, but it never reboots from shutdown, or from the onboard reset button. Unplugging the power 15-20 times and it might boot once.
The SD card is a fresh install from the ROOL download, so no extra bits in there…
The fact that it can boot sometimes but not others is puzzling.

Sounds rather like the familiar problem with the SD card not being quite the condition it ought to be.

Try with a different SD card

As I mentioned in the first post, it boots to a screen with a networking error, and no USB working, so it just seems the USB is not enabled/initialised correctly.

Has anybody tried to run 5.27 on a Beagleboard-xM with success ?

I will try it this week sometime. My Beagleboard XM is slightly unusual in that it has eMMC (although I don’t use it) as the correct memory chips were in short supply (I think).

Sounds rather like the familiar problem with the SD card not being quite the condition it ought to be.

Tried with a new card and another clean download of the HD and ROM with the same results…

I will say that once it does boot up its rock solid.

I have tried with a fixed IP and DHCP as well.
With DHCP it locks at the server request point in the startup screen.
With a fixed IP it gets to a window with an error relating to the gateway address.
Neither with working mouse.

Tried on my beagleboard XM using latest HardDisc4 and the very latest RISC OS 5.27 rom.

All works OK (including Internet using DHCP) USB pen drives, mouse, keyboard.

*Dir Boot:Loader
*ex
Dir. SDFS::HardDisc0.$.!BOOT.Loader Option 02 (Run) 
CSD  SDFS::HardDisc0.$.!Boot.Loader
Lib. SDFS:"Unset"
URD  SDFS:"Unset"

MLO          WR/     &700      22:43:20 20-Aug-2010   24 kbytes
BOOT/SCR     WR/     DOS       22:00:04 20-Aug-2010  549  bytes
RISCOS       WR/     &FE5      02:35:30 06-Oct-2020 2571 kbytes
U-BOOT/BIN   WR/     DOS       22:43:20 20-Aug-2010  205 kbytes
uImage       WR/     DOS       22:43:20 20-Aug-2010 3116 kbytes
USER/SCR     WR/     DOS       22:43:20 20-Aug-2010  755  bytes
RISCOS523    WR/     DOS       05:13:14 04-Oct-2012 2210 kbytes
RISCOS527    WR/     &FE5      02:35:30 06-Oct-2020 2571 kbytes
*sp.

Contents of Boot/scr:
led all off
sleep 1
led 0 on
sleep 1
led 1 on
led 0 off
echo Press USER button to enter Angstrom GUI
sleep 3
mmc init
if userbutton; then echo Entering Angstrom GUI; setenv bootargs 
    'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rw 
    roofstype=ext3 rootwait omapfb.mode=dvi:1280x1024MR-16@60'; 
    setenv bootcmd 'fatload mmc 0 0x80300000 uImage; bootm 
    0x80300000'; boot; fi
echo Entering RISC OS
fatload mmc 0 0x4020F000 cmos;fatload mmc 0 0x80100000 riscos
go 0x80100000

Contents of USER/scr:
led 1 off
mmc init
setenv dvimode 1024x768MR-16@60
setenv vram 16M omapfb.vram=0:8M,1:4M,2:4M
setenv console tty0 console=ttyS2,115200n8
if test "${beaglerev}" = "AxBx"; then
setenv rdaddr 0x81000000
setenv optargs mem=80M@0x80000000 musb_hdrc.fifomode=5
elif test "${beaglerev}" = "Cx"; then
setenv rdaddr 0x88000000
setenv ramroot /dev/ram0 rw ramdisk_size=131072 
    initrd=${rdaddr},128M
setenv optargs mem=80M@0x80000000 mem=128M@0x88000000 
    musb_hdrc.fifomode=5
else
setenv rdaddr 0x88000000
setenv ramroot /dev/ram0 rw ramdisk_size=131072 
    initrd=${rdaddr},128M
setenv optargs mem=80M@0x80000000 mem=384M@0x88000000
fi
run loadramdisk
led 0 off
run loaduimage
led 1 on
run ramboot

*fx 0
RISC OS 5.27 (06 Oct 2020)
*sp.

Hi Tank

So at least two of us , possibly three, have 5.27 working on a -Xm Rlse C, as Chris has not said what the revision of his board is, and as you say yours is new so can you confirm what board revision it is. I think C3 is the last?

What version of ZeroPain module do you have installed just to rule out that being the issue as 0.10 is the last.

Did you check for any unplugged modules , *Unplug , on Rlse 5.24 as module order may have changed.

What CMOS file are you using or is it the add on board type?

Just another thought I have noticed that there is a change in the monitor detection code as on my monitor if I put it in one HDMI slot it comes up in a very basic screen mode but in the other it works Ok so is that something halting the boot sequence and if so is that an issue you are having.

Either !Reporter or perhaps Rick Murray’s Harinezumi may help to see what is going on with the Boot sequence as they can both write, certainly Rick’s app can, to a file and create a boot log.

Hope that helps.

certainly Rick’s app can

And certainly Reporter can as well – with the Disc Logging option.

Well I’m still struggling to get it to boot. Could someone send me their Loader directory (less the ROM) please, so I can use a known good set and then I can see if it still fails. Thanks (webmaster@tankstage.co.uk)

Sent

Sent

Thanks for that both of you…
Same result for me though.
It does seem to be related to how long its powered down.
Leave the board off and it will power up fine.
A quick test and 5 seconds will not power, 10 seconds it will.
Reset from shutdown or press the reset button and no chance.
So maybe something on the board is still slightly powered up and is affecting the USB initialization.

My Beagleboard used to back-power via a KVM…

My Beagleboard used to back-power via a KVM…

So, a couple of quick reboots without my KVM USB plugged in, and Voilà….
Never used my previous boards with a KVM so never had this problem.

Thanks Grahame…..

I had interesting effects with one USB KVM and the Titanium (I think with RO 5.23) – it completely hang when booting up while connected to that (perhaps terminally broken, I’ve replaced it asap) KVM.

Lesson learned: always keep additional hardware out of the loop when strange things start to happen. This even extends to jerky mouse movement and stuck keys. Those were the days when keyboards and mice “just worked”…

Those were the days when keyboards and mice “just worked”…

There speaks a man who never dealt with keyboards jammed with biscuit crumbs and mice with dirty balls.
The former probably still happens and sanitiser would probably deal with the latter these days. :)

I have never many to jam my keyboard with a mouse with dirty balls. It is said they can fit into very small crevices.

sanitiser would probably deal with the latter these days

Pest control officer. Best not to handle meeces! They’ve probably all got dirty balls, but I ain’t gonna pick ’em up to inspect.

dealt with keyboards jammed with biscuit crumbs

I make it a rule to not eat over a keyboard. Been there, done that, nearly threw up when I opened it up (and trust me, as a former Care Assistant in nursing homes, I’ve dealt with some pretty grim things, but little of that compares to the insides of a badly treated keyboard).

and mice with dirty balls.

I find it’s not the balls that are the problem, it’s a little band of crud stuck to the rollers that the ball rolls. It can be a pretty delicate/difficult operation to repair, because if there’s too much crud, you might find that the roller no longer touches the ball when it is cleaned off, meaning it’s basically open-mouse surgery.

Oh, and my favourite, when some twat drops it or gets angry and beats it on a desk. Not hard enough to break it, but hard enough to knock the IR sensors out of line. That can be a delicate repair too.

They’ve probably all got dirty balls.

I do wonder about what’s inside a trackball. What’s dirtier, a person’s hands, or a mouse mat? Hmm…