OMAP4

I have a working PandaBoardES B3 using these MLO and u-boot/bin files.

Mainline u-boot shows the same problems as the ArchLinux one when used on my rev A6 PandaBoard. Tank’s one fails too.

I’ve tidied up my working version so that it will boot properly. I’ve had to hard-code it to load the RISC OS ROM (+ CMOS file), as TI’s sources seem to be missing support for both uenv files and .scr files. I’ve uploaded the builds here, together with the patches I applied to the sources. They should work on other board revisions as well, although I don’t think they’ll work on the ES B3.

After talking with Willi, it seems that the big problem with the latest U-Boot versions is that they run with the caches enabled, but neglect to disable them or perform any cache maintenance prior to starting code using the ‘go’ command. Which means that in order to be able to reliably boot RISC OS we either need to (a) behave like Linux and package the ROM as a uImage (which will have the correct cache maintenance performed) or (b) use a custom version of U-Boot (either with the cache maintenance commands enabled, or with the caches disabled). For PandaBoard/OMAP4 there’s also option (c) of using an older version of U-Boot, but that option isn’t really applicable to new platforms like OMAP5 where there is no older version available.

To me option (a) sounds like the most sensible solution:

• No maintenance overhead for ROOL/developers to ensure that our custom U-Boot is up to date
• Simplifies the setup that users have to perform (should they be trying to use their current U-Boot to boot RISC OS). And for ROMs that target multiple board types it means that U-Boot can directly tell us what board we’re running on instead of us using the current hack of having multiple entry points (which could easily go wrong if the user installs the wrong boot script)
• Some extra error checking added to the boot process, because U-Boot will check the checksum of the image before running it

One other advantage of the new U-Boot versions is that (in my experience) they seem to be a lot faster – 20MB/s read speed loading the ROM from the SD card, compared to around 1-2MB/s for the old version that I’m currently using.

Anyone have any other thoughts? It will essentially be a breaking change for existing OMAP4 users (the uImage header is at the start of the file, so attempting to ‘go’ to the start of the ROM won’t work), but since the port isn’t considered stable yet we do have a bit of extra wiggle room compared to something like OMAP3.

Also I’d be concerned about the experts, who don’t want to spend hours working out how to extract the text from a PDF so that they can work on the code.

While I agree with all that you’ve said the answer to that question is PDF2TXT, which if you’ve used Ghostscript you should be familiar with.

Oops wrong thread.

Dumb question alert: If the cache is enabled, can’t you just turn it off?

I agree option (a) looks the right approach.

we either need to (a) behave like Linux and package the ROM as a uImage (which will have the correct cache maintenance performed) or (b) use a custom version of U-Boot (either with the cache maintenance commands enabled, or with the caches disabled). For PandaBoard/OMAP4 there’s also option © of using an older version of U-Boot

Experience with the ever changing Raspberry Pi firmware suggests to me that (a) might end up in a similar situation when the goal posts keep moving, so (b) has an attraction that in effect you have a branch in the code with the RISC-OS-isms on it.

Anyone have any other thoughts?

It seems odd to offer a go command on something as multi platform as uboot but forget to take into account cache coherency on architectures that don’t do it automatically. A quick search shows many people agree, and that a command ‘icache ’ may well be available. I say may well as I’m not sure which version you’re looking at and there seems to have been some disagreement over calling it ‘flush’ and ‘icache’.

Another option, to avoid having to insert more tools in the chain, is to make a dummy image that just returns as ‘bootm’ definitely flushes, so you end up with a script doing (pseudo) this

fatload dummy.img <— somewhere unused 
fatload actual_os <— at actual_os_base
bootm <— the dummy image, which has cache flush sideeffects
go actual_os_base

Searching the uboot sources, only ‘bootm’ and ‘booti’ call cleanup_before_linux() which flushes the cache.

Dumb question alert: If the cache is enabled, can’t you just turn it off?

The HAL can easily turn it off on startup. However because no cache maintenance has been performed beforehand you’re theoretically executing undefined code. So there’s a chance it’ll crash before it’s able to safely disable and flush the caches.

Experience with the ever changing Raspberry Pi firmware suggests to me that (a) might end up in a similar situation when the goal posts keep moving, so (b) has an attraction that in effect you have a branch in the code with the RISC-OS-isms on it.

In my experience the only breakages with OMAP3 have been related to who is responsible for turning on the power/clocks for various bits of hardware. RISC OS should arguably be doing this for itself, but for simplicity we usually assume that U-Boot will have done the things for us. I’m not sure that the cost of maintaining a custom U-Boot branch containing our tweaks would be less than the cost of just fixing the issues in the OS.

If we were interested in ATAGs or flattened device trees or command line arguments etc. then we’d probably have some more issues to deal with, but as we’re mainly only interested in the “load this and go here” functionality of a uImage I don’t think we’ll run into any extra problems compared to the ones we face when using the ‘go’ command.

a command ‘icache ’ may well be available

The problem there is that U-Boot is very flexible, to the point where support for individual commands can be enabled and disabled by the target configuration files. I haven’t checked what the situation is like with other platforms, but TI’s default configs appear to have the cache commands disabled. So we’d need a custom build in order to allow those commands to be issued via boot scripts.

Another option, to avoid having to insert more tools in the chain is to make a dummy image that just returns so you end up with a script doing (pseudo) this

Hmm, interesting idea. I think we’d have to make sure the dummy image does a full cache flush however, as there’s talk in that mailing list thread about making bootm only flush the area containing the loaded uImage (I’m not sure if that’s how things are currently implemented, but it would need bearing in mind for the future)

There’s also an extra benefit to using a standard version of U-Boot – increased chances of RISC OS appearing in/being used with multi-boot setups. Or for devices with builtin flash where replacing the supplied U-Boot is difficult or ill-advised.

Most of what has been said has gone over the top of my head, but:

There’s also an extra benefit to using a standard version of U-Boot – increased chances of RISC OS appearing in/being used with multi-boot setups.

That I think would be a great benefit in getting more people using RISC OS.

What platforms use u-boot, Beagleboard (and derivatives), PandaBoard & ?

AIUI you can use u-boot on a Pi but its not fully developed and unless the Foundation adopted it (which seems unlikely) it wouldn’t help.

What platforms use u-boot, Beagleboard (and derivatives), PandaBoard & ?

The main u-boot repository has over 1000 board config files. However that does cover all platforms that u-boot supports, not just the ARM ones.

AIUI you can use u-boot on a Pi but its not fully developed and unless the Foundation adopted it (which seems unlikely) it wouldn’t help.

Well in the context of multi-boot setups, it doesn’t really matter whether the Pi uses u-boot or not. All that matters is whether RISC OS can be booted by a standard build of whatever the default/most popular bootloader is for any given device.

Over the weekend I made some changes to romlinker & rompress so that we can now directly produce uImage files as part of the ROM build process. All you need to do is modify the components file to add a few extra options to the top, e.g. the following will work for OMAP4:

%subformat uimage
%load_addr 0x81000000
%exec_addr 0x81000064

Plus of course you need to change your boot script to use ‘bootm’ instead of ‘go’. When combined with Willi’s recent fixes which were spotted by Chris, this now allows us to use standard U-Boot builds to boot RISC OS on OMAP4.