Any updates about RiscOS on the Raspberry Pi?

When I attemp to compile a ROM all goes well until I select ‘ROOL.Bcm2835’ for the Environment in the !Builder window. This produces an error ‘undefined instruction at &000212BA’ but if I ignore that and then compile a ROM all goes well until near the end when I get:

...
#autoscr_state         = R12+&0000047C
Workspace used               &0000516C bytes.
Selection data      = handle+&0000001C
0 Errors, 5 Warnings suppressed by --no_warn
do mkdir -p rm.ARM11ZF
link -rmf -o rm.ARM11ZF.Wimp o.ARM11ZF.Wimp 
copy  rm.ARM11ZF.Wimp Fat32Fs::96Gb.$.RISCOS.BCM2835Dev.Install.ROOL.BCM2835.Desktop.Wimp FR~C~V~N
WindowManager: rom module installed

Desktop (castle.RiscOS.Sources.Desktop.Desktop)...
amu -E  install_rom INSTDIR=Fat32Fs::96Gb.$.RISCOS.BCM2835Dev.Install.ROOL.BCM2835.Desktop COMPONENT=Desktop TARGET=Desktop 
do mkdir -p o.ARM11ZF
objasm -Stamp -quit -depend !Depend    -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"ARM11ZF\"" -pd "UserIF SETS \"Sovereign\"" -o o.ARM11ZF.Desktop s.Desktop
ARM AOF Macro Assembler 4.01 (Acorn Computers Ltd) [04 Jul 2011]
Assembling with user interface type = Desktop
do mkdir -p rm.ARM11ZF
link -rmf -o rm.ARM11ZF.Desktop o.ARM11ZF.Desktop 
copy  rm.ARM11ZF.Desktop Fat32Fs::96Gb.$.RISCOS.BCM2835Dev.Install.ROOL.BCM2835.Desktop.Desktop FR~C~V~N
Desktop: rom module installed

SharedRISC_OSLib (castle.RiscOS.Sources.Lib.RISC_OSLib)...
amu -E  rom_link ADDRESS=4229115600 LINKDIR=Fat32Fs::96Gb.$.RISCOS.BCM2835Dev.Install.ROOL.BCM2835.Lib COMPONENT=SharedRISC_OSLib TARGET=RISC_OSLib 
do <Perl$Dir>.perl build:xtentries > syms.C_Entries kernel.s.k_entries kernel.s.k_entries2 clib.s.cl_entries clib.s.cl_entry2
print rlib.swi { >> syms.C_Entries }
do <Perl$Dir>.perl build:xtentries > syms.A_Entries1 kernel.s.k_entries clib.s.cl_entries
egrep -v "^(0x00000000 . )?_swix?$" < syms.A_Entries1 > syms.A_Entries

<b>Internal error: undefined instruction at &000212BA</b>

Postmortem requested
212b6 in anonymous function
  Arg2: 0x000216c8 136904 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe15d000a]
  Arg1: 0x00025e20 155168 -> [0x65726765 0x762d2070 0x285e2220 0x30307830]
fc13c704 in shared library function
83ec in function ___init
AMU: *** exit (1) ***

AMU: *** 'rom_link' not re-made because of errors ***

Error running make rom_link on module 'SharedRISC_OSLib'.
Fatal error running make rom_link on module 'SharedRISC_OSLib'.
Batched errors...
Error running make rom_link on module 'SharedRISC_OSLib'.
------------------------------------------------------------------------------
Closing log file 'Fat32Fs::96Gb.$.RISCOS.BCM2835Dev.BuildSys.Logs.bUVZ00-00'.

Any ideas please?

I notice that addresses 212BA and 212B6 are not word aligned.

I suspect what you’ve discovered is that the version of grep/egrep in CVS isn’t ARMv6/v7 safe.

If you replace the copy that’s in RiscOS.Library.Unix with a copy from riscos.info and do

set UnixEnv$egrep$nonametrans ””

then it should work.

When I attemp to compile a ROM all goes well until I select ‘ROOL.Bcm2835’ for the Environment in the !Builder window. This produces an error ‘undefined instruction at &000212BA’

I get this too if I try to build a rom on a Beagleboard Xm but it works fine on a Pandaboard.

egrep -v “^(0×00000000 . )?_swix?$” < syms.A_Entries1 > syms.A_Entries

Internal error: undefined instruction at &000212BA

The rom build already has a fixed grep. It should be in ‘RiscOS.Library.Unix’ dated 15th Apr 2011.

You might have ‘alias$grep’ pointing to an old one.

Many thanks for the help.

I now get a bit further, compiling it on the Iyonix:

...
USBDriver (mixed.RiscOS.Sources.HWSupport.USB.NetBSD.build)...
amu -E  rom_link ADDRESS=4229536588 LINKDIR=ADFS::FastHard4.$.RISCOS.BCM2835Dev.Install.ROOL.BCM2835.USB COMPONENT=USBDriver TARGET=USBDriver 
link -LIST maps.USBDriver -MAP -Xref -Symbols rm.symUSBDriver  -o linked.USBDriver -rmf -base 4229536588 aof.USBDriver RISC_OSLib:o.abssym
copy  linked.USBDriver ADFS::FastHard4.$.RISCOS.BCM2835Dev.Install.ROOL.BCM2835.USB.USBDriver FR~C~V~N
USBDriver: rom_link complete

DWCDriver (mixed.RiscOS.Sources.HWSupport.USB.Controllers.DWCDriver)...
amu -E  rom_link ADDRESS=4229584344 LINKDIR=ADFS::FastHard4.$.RISCOS.BCM2835Dev.Install.ROOL.BCM2835.USB COMPONENT=DWCDriver TARGET=DWCDriver 
AMU: Don't know how to make 'o.dwc_notifier'
AMU: *** 'rom_link' not re-made because of errors ***

Error running make rom_link on module 'DWCDriver'.
Fatal error running make rom_link on module 'DWCDriver'.
Batched errors...
Error running make rom_link on module 'DWCDriver'.
------------------------------------------------------------------------------
Closing log file 'ADFS::FastHard4.$.RISCOS.BCM2835Dev.BuildSys.Logs.aUVZ00-00'.

Any ideas please?

Any ideas please?

I think I mentioned this earlier/in a different thread. The issue is that the dwc_notifier file is getting truncated to dwc_notif, so you just need to rename the .c and .h file back to the proper name

The issue is that the dwc_notifier file is getting truncated to dwc_notif, so you just need to rename the .c and .h file back to the proper name

I have done this (but why does the daily ROM generation work OK though – does it use different source files?)

Many thanks – the help is much appreciated. I have also noticed that some of the files in the directory such as castle.RiscOS.Sources.Video.Render.Fonts.ROMFonts.Fonts.Corpus.Bold.Oblique.IntMetrics0
are also getting truncated (so that the ‘,ttt’ is being cut off leading to the wrong file type and in extreme cases wrong file name being given).

Hope this helps (is it being overcome in the daily ROM build – if so how and why please)?

The daily ROM builds get the source directly from CVS.

As far as I know there’s nothing wrong with the source archives; the problems that you and other people have are all down to the version of tar in UnTarBz2 being broken.

As far as I know there’s nothing wrong with the source archives;

In the current rom build for the BCM 8235 Resources.$.Fonts.Corpus.Bold.Oblique.Outlines0 provides a counter-example where it has been truncated from ‘Outlines0,ttt’ to ‘Outlines0’ and thus compiles OK but with the wrong file type (set to Text in the rom build).

the version of tar in UnTarBz2 being broken.

has this been fixed yet please? My plan is to compile a BCM8235 ROM from the downloaded sources and then check the ROM byte by byte with the pre built ROM and enquire into any bytes that are not the same until I get an exact match and then to try to alter a couple of things.

Can’t find Kernel.s.NewBoot – it isn’t in $.RISCOS.BCM2835Dev.castle.RiscOS.Sources.Kernel.s.

Sorry Chris Hall, my fault !!!
kernel.s.NewReset…….
As pointed to by Chris Gransden.

Chris, I tried your alpha distro and updated to today’s ROM. Not sure of what to make of the results, it boots up into a screen with a beautiful color gradient cube but that’s it. Clearly there’s some code running, but I can’t figure out what! I don’t see any of the usual “boot” messages, but then again, my TV takes about 5 seconds to “get” the signal so I may simply be missing it. Next step, I need to hook it up to the serial port again and see what’s going on there.

BTW: Thanks for putting your distro together!

EDIT: Nothing coming out of the serial port, so I’m guessing it’s not booting into the ROM, perhaps the color gradient cube is coming from the GPU. I will refresh the bootcode.bin, loader.bin and start.elf files.

EDIT2: Everything checks out, I even went back to a previously working ROM image from last week. Still no luck; my guess is now that there is something wrong with the SD card filesystem image (or the way I wrote it to the SD card).

I tried your alpha distro and updated to today’s ROM. Not sure of what to make of the results, it boots up into a screen with a beautiful color gradient cube but that’s it.

Your changes to the FAT partition have trashed it – hence the multi-coloured cube from the GPU. Try copying the files out of the original unaltered version to another place. Alter them as required. Reformat the SD card using quick format under Windows and then copy them back in. That way seems to work 100% of the time. Or try the unaltered distro!

check the ROM byte by byte

Remember that development ROMs include in their footer the build date/time, so you’ll want to skip that in your comparison.

Remember that development ROMs include in their footer the build date/time, so you’ll want to skip that in your comparison.

So long as that doesn’t involve a variable length string somewhere near the beginning I should just be able to spot it and move on.

Chris, I tried your alpha distro and updated to today’s ROM.

Distro (39Mbytes) now updated to today’s rom with tweaks to recover the icon bar, set SDFS as the default filing system (192) and automatically boot from it using the RAMFS. No doubt other bugs introduced!

Screenshot (full size) here

[tar in UnTarBZ2] has this been fixed yet please?

The version of ‘tar’ included in UnTarBZ2 is from a third party port of ‘tar’. We’ve tried to address issues over time – there have been four or five revisions of it since we created UnTarBZ2, but clearly we’ve not fixed everything. If someone out there is able to test/fix it, they’d be more than welcome. The source code is in the zipfile

Your changes to the FAT partition have trashed it – hence the multi-coloured cube from the GPU. Try copying the files out of the original unaltered version to another place. Alter them as required. Reformat the SD card using quick format under Windows and then copy them back in. That way seems to work 100% of the time. Or try the unaltered distro!

I’m not so sure about this. I never got either of your images to boot on my Pi – just the multicoloured GPU screen. If I reformat and copy the individual files on, same result. I only get some success when I replace the Pi firmware files with older ones ripped from (IIRC) a Debian image, then I can see something happen for a split second before the screen goes blank (yes I have retained the config.txt from your image). The Pi is quite clearly able to read the card because changes to config.txt such as the resolution / overscan do make a difference. So I’m not sure what is going on.

Being the idiot I am I managed to successfully boot it over the weekend, got the command prompt etc, but then formatted the SD card by mistake (thought it was a different one)!

I only got the multi-coloured screen once, just after I had edited the files on the SD card (in a similar way to what you did). I could not get the Pi to boot into RISC OS with the earlier Debian image (13 April) files, had limited success with 19 April image Debian files but all was OK with the latest (7 June) files which are the ones in my image (see earlier post in this thread).

sorch, I tend to agree. I had a previous SD image that would boot up; I created it myself from the RPi arch linux distribution with the ROM image dropped in over kernel.img, I had grabbed the latest firmware files, made the config changes and was able to boot.

But with Chris’ image, I get the color screen — I also noticed that it is reading the config.txt file as I am have to set the overscan to 15 in each dimension. I had thought it was the Mac I’m using to write it out that was trashing the SD card with it’s meta files, but I was very careful about writing this time and left it completely unaltered — I even double checked it by mounting it on a Linux system (no junk files) … same result with the color cube.

What system are you using to “burn” the SD card? I’m going to try with my Linux box this time around instead of my Mac …

EDIT: Tried to write today’s distro to an SD card [that worked with a hand-built arch linux based image] from my Linux box and it exhibits the same color cube.

sorch, I tend to agree. I had a previous SD image that would boot up; I created it myself from the RPi arch linux distribution with the ROM image dropped in over kernel.img, I had grabbed the latest firmware files, made the config changes and was able to boot.

Maybe that’s what I did – I do have the arch image on my HDD. Going to try that now…

What system are you using to “burn” the SD card? I’m going to try with my Linux box this time around instead of my Mac

Windows 7 and CentOS. Also tried different memory cards – some weird brand 8GB and a genuine Sandisk 4GB. In both cases I’ve made a small (1-2GB) partition, formatted it as FAT and plonked all of the files on (or tried to load Chris’ image using either the “USB Image Tool” in Windows or dd in Linux). Not getting too much success so far.

One thing I really wish I had now is a power switch, all of this micro USB unplugging/replugging can’t be good. I think I’ll have to buy one of those micro USB extension leads off eBay and bodge in a power switch or something.

What system are you using to “burn” the SD card?

I’m using Win32DiskImager under Windows XP.

I’ve just written the card image (1.9 Gbytes) to another SD card using Win32DiskImager.exe (using a type of SD card I know SDFS on RISC OS does not handle) and RISC OS starts up but the boot process fails because it cannot read the SD card and jumps straight into the desktop with an error message. But no multi-coloured screen.

After you burn the SD card, you should be able to see several files in the FAT partition such as ‘start.elf’ etc. There is only one partition, a single FAT partition of 2Gbytes. It won’t work on smaller cards.

After you burn the SD card, you should be able to see several files in the FAT partition such as ‘start.elf’ etc. There is only one partition, a single FAT partition of 2Gbytes. It won’t work on smaller cards.

No problems there, but it just won’t boot. If I replace the firmware it seems to boot okay but I can’t see anything after a split second (but the ethernet initialises, keyboard function keys respond to being pressed, etc). With the firmware as supplied in the image I get the multicoloured screen. I wish I remembered what I did at the weekend to get it to work…

Guys, don’t forget the known issue with SDFS… not sure if that’s relevant but keep it in mind.

Looks like it’s known as the Rainbow Square of Death. According to the elinux troubleshooting guide, it’s present in new firmware and is shown early in the boot process. In theory the kernel.img should then replace it almost immediately so if you see it, it means kernel.img failed somehow.

So I’m guessing that replacing the firmware with an older version means you just now have a version that doesn’t show the cube. Maybe there’s some other error booting RISC OS (as sorch is seeing with older firmware).

I am not seeing anything at on the serial port, it’s clear that the bootloader is able to read the file system given that the overscan settings in config.txt are clearly being processed — is anyone with a working boot seeing serial output? I’m beginning to wonder if maybe it [HALDebug] got turned off in the more recent RISC OS builds?