When should we have a new BeagleBoard ROM image?

At what point should we have a newly built BeagleBoard ROM image?

Probably not right now – there are probably significant changes in the works. I’m wondering when there will be enough good stuff checked in so that a new build would be sensible. The existing one is 6 weeks old.

Good question!

There are a few things I’m working on at the moment:

• Making sure that our cache/TLB maintenance code is properly ARMv7 safe (the current code doesn’t use data/instruction barriers in all the right places). I had a read through the docs last night, and am planning on getting this finished and checked in in the next couple of days.
• Adding the CDFS modules to the ROM image. Should just be a case of grabbing the source and checking it compiles – nothing too tricky, I just haven’t gotten round to it yet!
• I’ve also got a pending change to update the beagle ROM to build FPEmulator from source instead of using the prebuilt version.
• That abort handler to emulate pre-ARMv6 rotated load behaviour. Main problem is that I/we haven’t settled on an API to allow the module to register itself with the list of abort handlers, so it’ll need at least a couple of good days of work to tidy it up and get it checked in.
• The VFPSupport module. The bulk of the code is written, I just need to tie up all the loose ends to get it to a state where it compiles and runs. Although it would need another few hours ontop of that if I was to hook it up into the Wimp and test it properly.

So the first three should be done in the next couple of days, the rest will take longer. The only problem is that we’re just entering crunch time at work, so I won’t have much spare time over the next month or two to dedicate to RISC OS - so I can’t give a firm estimate for how much longer the last two items will take.

So if you want to see something in the build sooner rather than later, let me know and I’ll try and prioritise it :)

CDFS should be easy – I successfully softloaded the prebuilt modules from the Download page without problems on the BeagleBoard. I am not 100% sure however in what way the “Resources” are bundled into the ROM - these were missing from the Download page (usually, in the old days, there was a module called “CDFSResources”).

The resources needed by all the ROM modules get bundled together and built into one module (ResourceFS, possibly?). So that should work properly if I build the CDFS modules as part of a ROM image. For standalone builds of modules they’d usually get built into the module itself, maybe you were getting errors because the CDFS modules haven’t really been tested in standalone form before.

Do you know exactly which CDFS modules you need including in the ROM? It’ll save me some time working out what they all do :)

CDFSDriver, CDFS and CDFSFiler.

I’d vote for priority for anything to do with CD/DVD handling. I’ve just ordered a USB DVD writer.

Plus anything that can stop the BB from stiffing – mine’s just done it 3 times in rapid succession.

All the floating point stuff doesn’t bother me much right now. Nor does emulating rotated LDR/STR instructions.

I second that last vote, as I also have an USB DVD writer that I’d like to use, and it would be convenient if the ROM image already had support for it (Item 2).

Item 1 also seems like a good thing: Anything that can improve its stability is good.

And finally, item 3 (building the FPEmulator from the sources), if it’s not too much work to implement, would be nice. This way, it would be in the toolchain, and possible to read and tinker with the source (for example, to figure out how to implement one using the VFP instructions).

Then ship! :) And feel free to have “crunch time” at work… :)

Should only be another day or two before items 1-3 are in CVS. I just need to figure out what’s wrong with the CD modules (there was a CD icon on the iconbar when the desktop started, clicking it resulted in a crash) and check over the cache fixes to make sure I haven’t done anything silly.

I’ve just noticed that there is a new BB ROM image dated last Friday. Anyone know what’s in it?

This sound really nice, but is any of this tested using the OTG-Port?

I have the impression that there are several issues but unless one has a revision B Board nobody seems to use the OTG

I found out that EtherUSB together with the LogiLink MOSCHIP based device does not work on the OTG port but is reported to work on the normal USB ports.

Most types of USB Sticks do not work (I found two different types that do, and reliably)

Up to now, no harddisk adapter or USB Harddisk I checked, worked ok (I tried 5 different models)

I can not confirm if the situation is generally the same for the RevC Board, as I can’t compare. But it would be nice to have the new additions available for all the Beagleboard users though. Can anybody check? (I would be willing to, but both my ide-usb-Adapters do not work with the OTG port)

I have the impression that there are several issues but unless one has a revision B Board nobody seems to use the OTG

I, for one, have never used the OTG port. I have a Rev C4 board, and I am (currently) only interested in using the BB as a host. All the OTG port would do for me is complicate the cabling. I would guess that the situation is similar for many BB users, which is probably why the OTG port gets so little attention.

I’ve just noticed that there is a new BB ROM image dated last Friday. Anyone know what’s in it?

Just a couple of minor bug fixes, I think. I suspect they just rebuilt it to make sure they had the latest ROM images for the Acorn World show/vintage computer festival at the weekend.

This sound really nice, but is any of this tested using the OTG-Port?

I think once I’ve got the cache/CDFS/FPEmulator changes checked in I’ll put the other stuff on hold and look at some of the USB bugs. I’ve been neglecting them for far too long.

Have you been remembering to use a powered hub with all the devices you’ve been testing? The USB OTG port can only provide 100mA of power, which is only really enough for a simple keyboard or mouse.

Also, although I do have a USB-IDE adaptor, I don’t have any spare hard discs to test it with!

Also, although I do have a USB-IDE adaptor, I don’t have any spare hard discs to test it with!

Where do you live?

Have you been remembering to use a powered hub with all the devices you’ve been testing?

Yes, sure. I have a powered 7 port-Hub that I normally use for Keyboard, Mouse, 2 USB sticks and a card reader (temporarily). When I start testing anything on the USB and it goes wrong I mostly need to do a hard reset even if the system is still running as everything else on the usb (keyboard, mouse..) also gets ‘offline’.

I’ve been neglecting them for far too long.

No, not really. You are doing a fantastic job!

Also, although I do have a USB-IDE adaptor, I don’t have any spare hard discs to test it with!

could you check your Network adaptor too? – maybe you can use the usb-IDE-Adaptor with an old CDrom

Where do you live?

Oxford. However it’s a USB-SATA adaptor, not USB-IDE, so it would have to be a SATA drive if you’re offering to lend me one. Ironically, I have plenty of IDE drives spare. In a few weeks time I’ll be buying a few new bits and pieces ready for my -xM board, so I’ll probably buy a USB-IDE adaptor or USB hard drive then.

I, for one, have never used the OTG port. I have a Rev C4 board, and I am (currently) only interested in using the BB as a host

I am also only interested in using the BB as a host! Due to a bug in the Rev. B Boards, these only have the OTG port working, so Jeffrey configured the port as host. That means that without the OTG port, rev.B boards don’t have any USB!

However it’s a USB-SATA adaptor, not USB-IDE

Ok, so this won’t work with an old cdrom.

In a few weeks time I’ll be buying a few new bits and pieces ready for my -xM board

So you have it already?

However it’s a USB-SATA adaptor

:( It’s IDE drives I have spare.

However it does occur to me that perhaps it would be a good idea for the site to have a section where developers can post things they need and their location.

So you have it already?

If I had my -xM board I’d be ordering the parts I want now, not in a few weeks time ;)

I’d be ordering the parts I want now

Yes, just kiddin’

Here’s an interesting observation that just might be relevant to this thread.

I just tried Friday’s BeagleROM image. My BB must be having a particularly bad night, because it stiffed several times before I could get it to boot into the desktop – and then it stiffed when I launched Zap. So I went back to the 100505 image.

This too kept stiffing, usually a non-stop hourglass after the RISC OS and VProtect splash. Alt-Break, each time I tried it, allowed me to stop “Unknown”, but, on doing so, gave me “Filecore in use”.

I lost patience and pulled the USB stick to verify it on the Iyonix. Immediately BB asked me to insert HardDisc0! I verified the USB stick with DiscKnight and re-inserted it. After the two long waits (one for USB to recognise that a new device was present, one to read the map etc.), I OK’d it and normal service was resumed!

Does this give any clues as to one of the causes of stiffing?

It sounds like at least some of your problems are USB related, then. Are you using a powered hub? Do you have any other USB sticks you can try? Is it always disc access that causes problems? Have you ever had any problems using the USB stick with your Iyonix?

If it is a USB problem, hopefully it will go away when I find the bug that’s stopping some hubs from reporting port status change events (i.e. device insertion/removal).

Are you using a powered hub?

Absolutely. Rated at 3 amps. Plenty spare.

Do you have any other USB sticks you can try?

Not until 7dayshop deliver them!

Have you ever had any problems using the USB stick with your Iyonix?

I’ve never actually used it with the Iyonix except to ADFS-format it originally and to copy the disc image over.

If it is a USB problem, hopefully it will go away when I find the bug that’s stopping some hubs from reporting port status change events (i.e. device insertion/removal).

It will be nice when that has been found and fixed. It’s a 20 second wait for me when anything is plugged in.

Items 1-3 are now in CVS.

... figure out what’s wrong with the CD modules (there was a CD icon on the iconbar when the desktop started, clicking it resulted in a crash)

It turns out this was just because the number of CDROM drives was set to 1 in the default CMOS settings. I’ve changed the default to 0 (for OMAP3 ROMs), and everything seems to be OK (the CD modules stayed loaded, unlike the annoying RISC OS 3 versions)

... and check over the cache fixes to make sure I haven’t done anything silly.

I haven’t exactly tested the code much, but everything seems to be OK. However ARM recommend that TLB maintenance operations should be performed after updating the page tables, not before (which is how RISC OS currently does it), just in case the CPU decides to spuriously perform a page table walk and re-reads the old mapping after the TLB flush but before the page table write. This might require a few tweaks to be made to the ARMop API, so it may be best left until one of us finds the time to do some of the other cache-related tweaks (the PIPT cache tweaks, dual TTBR support, etc.)

However ARM recommend that TLB maintenance operations should be performed after updating the page tables, not before (which is how RISC OS currently does it), just in case the CPU decides to spuriously perform a page table walk and re-reads the old mapping after the TLB flush but before the page table write.

Normally I have a hint of what you are talking about, however this one is totally over my head. :)

However, what I want to ask are the implications.

Which processors does this apply to?

What would the end results be? (Random lock ups?)