When should we have a new BeagleBoard ROM image?

Is there anyone else who tried, say, to unpack riscos on either medium who can share information on that?

I did test unpacking the RISC OS sources using both SparkFS and the command line unzip tool. I also tested unpacking from the SD card onto the SD card, and from the USB stick onto the SD card. I didn’t run into any errors (apart from when I pressed Escape!), but I didn’t think to try checking if the source would compile, or whether it matched the original copy. I guess I should check that tonight (although I can’t fully test whether the source compiles anyway, since I have a copy of the compiler from before it was recompiled for ARMv7, and something went wrong last time I tried it with my prototype unaligned load/store handler)

You might want to doublecheck using the (big enough) RAMdisc as you have the revC Board. This is much faster than using USB mass storage. Maybe it’s not the USB?

I normally unpack using untarbz2 though it’s a bit restricted in that you have to stay on one medium.

Is there anyone else who tried, say, to unpack riscos on either medium who can share information on that?

...but I didn’t think to try checking if the source would compile, or whether it matched the original copy...

I tried the build some time ago. It eventually worked although I’ve unfortunately been unable to do any subsequent testing¹ :-(

¹ My board is currently bricked (unrelated to the RO build process) and I’ve had no success with the board recovery procedure either. A mate of mine is now going to have a look, as he’s interested in ARM devices… so I should be back to experimenting again soon (either on my current board or an xM).

One of the USB fixes that I merged in from the NetBSD sources was a fix for VIA’s dodgy EHCI implementations that sometimes fail to write back the transfer status before firing off an interrupt. If the CPU was fast enough it could end up thinking that the transfer was still in progress when actually it had actually completed. Apparently this bug was most evident as a stall in the mass storage drivers, so it could be the same problem you’re seeing. When I get a chance I’ll try enabling the fix for the OMAP build and upload a ROM for you to test with.

Unfortunately it doesn’t look like this fix works on RISC OS - it just results in a “Not a heap block” error during the boot sequence, presumably due to some kind of memory corruption :(

You might want to doublecheck using the (big enough) RAMdisc as you have the revC Board.

Doublecheck the archive extraction or the ROM compiling? The strange compile error will almost certainly be a hidden ARMv7 incompatability, and I’m not sure 256MB of RAM is enough to extract the latest OMAP .tar.bz2 into a RAM disc (The tar file is 111MB, and the contents could easily be over 140MB once all the small files have been rounded up to the disc block size)

I normally unpack using untarbz2 though it’s a bit restricted in that you have to stay on one medium.

I’m currently testing this now, although it’s so slow that I’m regretting doing an initial test of getting the Iyonix to extract everything to USB!

Here’s a good question for you: How are you using untarbz2 if the bzip & tar tools haven’t been recompiled for ARMv7? :) Have you replaced them with new versions from riscos.info, or are you disabling alignment exceptions?

Here’s a good question for you: How are you using untarbz2 if the bzip & tar tools haven’t been recompiled for ARMv7? :) Have you replaced them with new versions from riscos.info, or are you disabling alignment exceptions?

Something fishy is definitely going on here… The riscos.info version of bunzip2 fails with the same SIGSEGV recursion error, and the riscos.info version of tar doesn’t like the command line it receives (after I had to increase untarbz2’s wimpslot size setting since it was failing to load at all)

Doublecheck the archive extraction or the ROM compiling?

You are right, the tar and the unpacked sources won’t both fit onto ramdisc. But if you place the tar.bz2 – file to ramdisc, the tar file will also go there which accelerates things greatly. The destination must be SD card again, but will have much less interference by USB load.

Compilation should work too, if you merge to the ramdisc after removing the tar file :-)

Here’s a good question for you: How are you using untarbz2 if the bzip & tar tools haven’t been recompiled for ARMv7? :) Have you replaced them with new versions from riscos.info, or are you disabling alignment exceptions?

I use the rool version and disabled align exceptions, but I have to check the versions this evening.

I also unpacked with !untarbz2 and re- zip’ped in RPCemu to unpack with unzip on the BeagleBoard once for doublechecking reasons but the problems were comparable.

I’ll be doing some more stress testing of the driver of the next few days, mainly to look into a problem Uwe mentioned in an email to do with zip file extraction, but apart from that I’m hoping I’ll finally find the time to try porting the Linux DSS driver to RISC OS so we can see if it fixes the IGEP video problems.

A very selfish vote here for IGEP video work! ;-)

I’m currently testing this now, although it’s so slow that I’m regretting doing an initial test of getting the Iyonix to extract everything to USB!

Did’nt you patch your Iyonix with the latest USB driver updates fom J.L.? :-))

I guess you never tried it on a riscpc :-) it takes loooong time.

A very selfish vote here for IGEP video work! ;-)

tsk tsk ;-)

You are right, the tar and the unpacked sources won’t both fit onto ramdisc. But if you place the tar.bz2 – file to ramdisc, the tar file will also go there which accelerates things greatly.

Ah, OK. I’ll have to remember that next time :)

I use the rool version and disabled align exceptions, but I have to check the versions this evening. I also unpacked with !untarbz2 and re- zip’ped in RPCemu to unpack with unzip on the BeagleBoard once for doublechecking reasons but the problems were comparable.

Hmm. I was going to lecture you on disabling alignment exceptions and then complaining when you get random corrupt files/discs, but if you get the same problems when extracting zipfiles then maybe it’s not ARMv7 incompatabilities that are causing the problems.

I guess you never tried it on a riscpc :-) it takes loooong time.

It surely can’t be as slow as extracting to USB. It only took a few minutes to extract everything to my Iyonix’s hard disc, but seemed to take half an hour or more to extract to USB. Most of the time was spent extracting the files from the tar archive, and it took far longer than it took to copy the already-extracted files from the HD to USB. I’m not sure whether to blame tar for not buffering files well enough or whether to blame SCSISoftUSB for not supporting background transfers. In particular, if tar doesn’t buffer writes properly then it could generate a hell of a lot of low-level writes, which could conceiveably wear out any cheap USB sticks (or cheap SD cards). But I’m not an expert on the wear-leveling techniques that USB sticks & SD cards use, or on how many erase cycles modern flash memory can withstand, so don’t draw too many conclusions from my theory. Certainly the SD card I’ve been using was still working fine afterwards, and the files the Iyonix extracted to USB matched the ones that were extracted to the HD.

But to get to the point: I now have a much stronger desire to add support for background transfers to SCSISoftUSB! I’ll also do some more tests tonight using ROOL’s untarbz2 with alignment exceptions off, to see if I get any corrupt files.

Hmm. I was going to lecture you on disabling alignment exceptions and then complaining when you get random corrupt files/discs, but if you get the same problems when extracting zipfiles then maybe it’s not ARMv7 incompatabilities that are causing the problems.

Well that’s a problem anyway, is it not? To run the compiler I have to disable alignment exceptions.

BUT the good news is: I tried the whole process again with SD card and card reader and it worked! I am now ‘proudly’ running a beagle built riscos on the beagle :-)

This is just to let you know – and that working on usb sticks at least at the otg port seems not to be really stable. But for me this works for the time being. I will postpone the USB development.

OK, at least you’ve found a solution that works.

I haven’t done the extra testing yet; I’ll try and do it tonight. I think I’ll also buy a new USB stick and see if that reveals any problems.

While testing things tonight I’ve found another fun USB issue – if I place the latest (ish) versions of x-loader and u-boot on the SD card and boot using those instead of the ones in NAND, then what often happens is that the enumeration of the USB devices attached to the OTG port occurs a few seconds after RISC OS has reached the command line. This obviously has the effect of preventing the machine from running the boot sequence :(

When the USB modules initialise they do attempt to enumerate the attached devices straight away, so I’m guessing there must be a timing issue somewhere that causes the initial enumeration to fail. Hopefully it won’t be too hard to track down.

When the USB modules initialise they do attempt to enumerate the attached devices straight away, so I’m guessing there must be a timing issue somewhere that causes the initial enumeration to fail.

Interesting; I still get an occasional failure to boot with my newer USB stick and a recent version of your USB code. It sounds to me as if this might explain it.

It would probably make sense to have a “pre boot” service call which the OS issues before starting the boot sequence. The USB drivers can then stall the system until they’ve successfully enumerated all the attached devices (and any USB device drivers in ROM can stall until the devices are fully registered with the system, etc.)

I get these occasional boot failures too – either not booting at all or not booting into the desktop, but thought it to be a memory initialisation problem. This happens with my (older) SD card based loader.

I’ve just noticed that there are new ROM builds available from a few days ago.

[Bump]