Multi Boot for Armini

Is there a simple way to make use of (a small number of) the I/O header pins so that a DIL switch can be connected and interrogated by the uboot script (in a similar way to the ‘user’ button) to provide a multi-boot option. For example into command line Linux, GUI :inux or RISC OS depending which switch is set?

There aren’t any u-boot commands to read arbitrary GPIOs, I know that much. There are commands to read arbitrary memory locations, but I think they just print the results out to the screen instead of storing them in script variables.

Not sure whether something connected to the expansion header could appear as (for example) a memory location allowing (for example) a RISC OS ROM image to be loaded with preceding code which either does a jump to RISC OS or returns for the next (uboot script) command which could enter Linux.

Hence instead of ‘go 08000000’ you would ‘go 7FFFFC0’ or whatever which would interrogate the expansion header in some way and, depending on the result, return to the calling command e.g. ‘MOVNE PC,R14’ (assuming ‘go …’ does put the calling address on the stack) or simply continue to enter RISC OS. The uboot script can then have further commands to enter Linux.

A further thought – if the boot script can choose between different start-up options by interrogating the user button then why not load two different operating systems in memory and let RISC OS provide a simple user interface to choose between them?

The script (using the user button) is as follows:

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 0x80100000 riscos
go 0x80100000

So what about:

mmc init
echo Loading Angstrom GUI
setenv bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rw roofstype=ext3 rootwait omapfb.mode=dvi:1280x1024MR-16@60'
fatload mmc 0 0x80300000 uImage
echo Loading RISC OS
fatload mmc 0 0x80100000 riscos
go 0x8010xx00

The entry point would initialise RISC OS (in absence of a boot drive) only sufficiently to present a simple option on the screen whether to run Linux or RISC OS and jump to 0×80100000 or 0×80300000 as appropriate. That is would not affect the Linux uImage in memory in case the decision was to run Linux. This might be possible now that we know how to get RISC OS running on the beagleboard and how much we can do with a ‘standard’ works-on-all-machines basic screen size and a USB keyboard for input.

If we can make this as convenient as possible then users of the beagleboard might be persuaded to put riscos in their boot scripts and have a play with it (multi-booting the Beagleboard is not easy at present and a convenient solution might be attractive).

Also worth considering whether RISC OS can make use of the expansion header (like the user port on the BBC computer) for simple control I/O utilising some sort of simple plug-in circuit board?

One further thought: if we can allow RISC OS to boot to the supervisor prompt if it does not find a boot disc (as it would do in a non-RISC OS user machine) AND we can print a bit more information AND we can retain in memory the Linux uImage code then we could present something like:

RISC OS 512MB

Cortex-A8 Processor

Acorn SCSIFS

Waiting for boot drive to be ready; press Escape for multi-boot options

[on Escape being pressed]

Type 'Linux' to enter Linux

RISC OS requires a formatted pen drive with system components: 
instructions on how to prepare this are on this site:
[ROOL web address]
*

If we can make this as convenient as possible then users of the beagleboard might be persuaded to put riscos in their boot scripts and have a play with it

I hope you’re right that:

1. It’s possible
2. People will have a play

make use of the expansion header (like the user port on the BBC computer) for simple control I/O utilising some sort of simple plug-in circuit board?

This sounds like what Andrew Conroy is interested in. Did you speak with him about it last Saturday? Would the BeagleBoard Trainer help?

I hope you’re right that:

1. It’s possible

What happens if you press Escape (while RISC OS is looking for the boot drive) and then try to execute the Linux uImage at its expected address 0×80300000:

*run uImage [with load and execute addresses set to 80300000]

What happens if you press Escape (while RISC OS is looking for the boot drive) and then try to execute the Linux uImage at its expected address 0×80300000:

*run uImage [with load and execute addresses set to 80300000]

You get ‘no writeable memory at this address’!

If you substitute 300000 for 80300000 (as that is where memory seems to be under RISC OS) then you get ‘undefined instruction at &0030000C’ so you can’t simply execute the uImage file.

What happens if you press Escape (while RISC OS is looking for the boot drive) and then try to execute the Linux uImage at its expected address 0×80300000

Then it will fail horribly, because by that point all the RAM will have been cleared and the MMU will be enabled (so the addresses won’t match). The Linux kernel will be expecting the MMU to be disabled on entry, plus it’ll need to be in a privileged CPU mode with some boot arguments in the registers.

I think there are several approaches to getting this to work:

1. Write a boot menu/utility which can be run from within u-boot (u-boot essentially acts as a mini operating system). I know it’s possible to write programs which can operate like this, but I’m not sure if the version of u-boot used on the xM has been compiled with support for that.
2. Modify RISC OS as you suggest, so that it can preserve the in-memory linux kernel image, and can boot into it on request. This is easy enough if you just want to interrogate a few GPIO pins, but if you want to print things on screen or respond to keyboard input it’ll get a lot trickier since they rely on the kernel being fully initialised (which in turn means the RAM has been cleared, the MMU is on, etc.)
3. Expand the softload tool to cope with more than just RISC OS ROM images. This is the best solution in terms of not messing too much with RISC OS’s initialisation, but it might be tricky if you want it to be able to use the linux kernel & boot args that have been set up in u-boot.

Modify RISC OS as you suggest, so that it can preserve the in-memory linux kernel image, and can boot into it on request. This is easy enough if you just want to interrogate a few GPIO pins,

I’m always for the ‘easy’ option – are there some GPIO pins that can be interrogated? If so then that allows a multi-boot on the ARMini [where all these things such as a boot select switch, the contents of the SD card etc. can all be controlled].

With the RAM cleared and MMu on RISC OS running and USB keyboard input received that says ‘No I want Linux’ then is it possible to load the Linux uImage into memory and then to turn the MMU off and put the processor into priveleged mode and let Linux execute?

I am keen to find a solution that can be offered to users with no pen drive (i.e. no !Boot structure) and no prior knowledge of RISC OS in the hope that they might be drawn in.

Don’t tie up any GPIO pins in deciding what OS to boot to, various users may already be using these pins for something else. Also, requiring a hardware addition in order to multi-boot seems a bit OTT.

Didn’t Matthew Philips post something about how to dual-boot RISC OS & Linux using the User button some time ago?

Apologies for the duoble post, it told me it hadn’t worked first time :-(

Would the Beagleboard Trainer help?

Yes, the Trainer by TinCanTools looks handy, I’ve been looking at it for a while, but I’m planning on making my own ‘variant’ of it instead. Having 22 GPIO lines from the expansion header (or 20 and an I2C bus) would make it even more ‘interfacable’ than the Beeb! In fact, given that you’ve got a total of 45 GPIO lines from the various headers, then you could control a whole range of inputs & outputs with the BB quite easily.

I currently have a line of flashing LEDs (well, you have to, don’t you!), an I2C temp. sensor and somethig else (more fun than serious though) hanging off my BB at present. More details later.

Didn’t Matthew Philips post something about how to dual-boot RISC OS & Linux using the User button some time ago?

This is straightforward, see my fourth post from the top. Taking the top off the ARMini and pressing the user button it is a simple matter to boot into Linux. I am trying to do it without taking the top off!

With the RAM cleared and MMu on RISC OS running and USB keyboard input received that says ‘No I want Linux’ then is it possible to load the Linux uImage into memory and then to turn the MMU off and put the processor into priveleged mode and let Linux execute?

Yes. The easiest way of starting the image would be using the upgraded softload tool (since it already has to deal with disabling the MMU, entering a privileged mode, etc. in order to boot RISC OS). It’ll be trivial to include the tool in the ROM image (e.g. in Resources) so it can be run if necessary.

The tricky part would be working out how to get hold of the Linux kernel in the first place. We’d either need to make u-boot load the image and modify RISC OS to not overwrite it during the startup sequence, or we’d need working SD drivers so we can load the image ourselves (and come up with a system for getting the boot args – a seperate text file would be easiest, rather than trying to extract the args from the u-boot environment/script).

The tricky part would be working out how to get hold of the Linux kernel in the first place. We’d either need to make u-boot load the image and modify RISC OS to not overwrite it during the startup sequence, or we’d need working SD drivers so we can load the image ourselves (and come up with a system for getting the boot args – a seperate text file would be easiest, rather than trying to extract the args from the u-boot environment/script).

The Linux uImage file is on the SD card – we only need read-only SD drivers. It would need to be done this way as we don’t want to anticipate any other drive being present.

I know that running RO binaries under Linux is a separate project, but what’s config ARTHUR? (RISC OS personality here too.) Is this related to ARMLinux or am I completely lost?

Surely the config ARTHUR description tells you all you need to know?

“Say Y here to include the kernel code necessary if you want to run Acorn RISC OS/Arthur binaries under Linux. This code is still very experimental; if this sounds frightening, say N and sleep in peace. You can also say M here to compile this support as a module (which will be called arthur).”

Is this related to ARMLinux or am I completely lost?

The fact that it’s in the ARM Kconfig file means it’ll be only available for ARM targets.

It seems part of Chris’s aim (correct me if I’m wrong) is to supply an SD card with RISC OS and Linux on it, with an easy way of choosing between the two, so that non-RISC OS users can be persuaded to try RISC OS.

I am keen to find a solution that can be offered to users with no pen drive (i.e. no !Boot structure) and no prior knowledge of RISC OS in the hope that they might be drawn in.

However, if they have no pen drive and no !Boot structure, RISC OS won’t exactly work very well at the moment, so they’re unlikely to get drawn in.

If you want to do it just with an SD card, and don’t want to have to press the user button (and we surely don’t want extra hardware on the GPIO lines as that’s even more unlikely) then you need to detect keypresses or have a menu system.

So I would say the nicest solution would be to boot into the RISC OS Wimp fully, and have an application which can switch to Linux.

If RISC OS could have its hard drive on the SD card, which it can’t at the moment, then one way to do it would be to partition the card into three: uboot, RISC OS, Linux. The Linux image and boot parameters could be stored on the RISC OS partition and the modified softload tool could run it on request. This is, after all, how ARMLinux was first run on the RISC PC.

Disadvantages: it’s easier to obtain and build a new Linux boot image from Linux, and I’m not sure writing to modern Filecore discs is supported under Linux at present.

Given we cannot use the SD card for RISC OS’s hard drive at present, this all sounds rather academic. You could have the RISC OS hard drive on a pen drive and take much the same approach, obviously, but that doesn’t fit Chris’s criteria.

What’s the market? Most people who have a BeagleBoard can easily get at the user button, and dual booting is not a problem. If the problem is that ARMini users can’t get to it, what’s the aim of the idea: they already have RISC OS, and I got the impression Chris was wanting to draw other people into using RISC OS.

However, if they have no pen drive and no !Boot structure, RISC OS won’t exactly work very well at the moment, so they’re unlikely to get drawn in.

If we can make it give a choice of boot by a keyboard input so that (for example) Linux command line or Linux GUI (which can co-exist on the same SD card) are selectable then, who knows, they may try RISC OS just to see. Without a boot structure you can do very little but if the ‘Supervisor’ message was expanded a bit to say something like ‘RISC OS requires a formatted pen drive containing drivers to provide storgae and network access. This may be obtained here (web link to relevant ROOL page). Press DESKTOP to see the bare desktop.’

There may be scope for sufficient resources in the ‘Resources’ area to get RISC OS up and running. Or do what Linux does and have a boot structure in the RAM disc filing system. Or do what the BBC computer did and have it in the ROM filing system. After all it is not a physical ROM and can therefore be several Mbytes bigger. I think the RAM filing system looks promising – this could be loaded from ‘ROM’ with a default Beaglebaord !Boot structure or loaded from the SD card (as the file ‘cmos’ is presently).

My aim is to present something useful that can be stored in about 7Mbytes on the SD card.

@Jeffrey & Trevor:

The introduction of EABI on ARM Linux has rendered the RISC OS personality and thus the Arthur module useless. It was intended to pass on SWIs to a user space app that could be run as a wrapper for running RISC OS binaries. On older machines it even allowed switches to and from 26 bit mode.
A long time ago I teamed up with Philip Blundell to get this patch in the mainline kernel and it is still there. However with the introduction of EABI SWI 0 has been chosen for the default Linux syscall.

Currently i am collaborating with Simon to take another shot at this approach.
ROLF (http://ro-lookandfeel.blogspot.com/) is being prepared with the help of a kernel patch to enable running RISC OS binaries on Linux. There is still a long way to go and one of the hurdles is the SVC mode used by modules.

Thanks for the info, Jan.

ROLF

Yes, that looks like the specific that I failed to recall.

@Trevor: ROLF is a much newer project than riscose or ‘rose’ which were used during the time that the patch was submitted to the Linux kernel. http://sourceforge.net/projects/riscose/ is still there and was the followup on ‘rose’.
The strategy in riscose was to rewrite all the SWIs in C since back then there was no open source available. Obviously that strategy was a bit too much for the small group of developers.

My aim is to present something useful that can be stored in about 7Mbytes on the SD card.

I have just looked at the default !Boot.Resources and realise that it is some 78Mbytes. To get a basic functioning RISC OS most of this is probably unnecessary – a stripped-down !Boot structure loaded from SD card into the RAM filing system would allow a more presentable RISC OS environment to be presented to the casual curious onlooker and perhaps drag them in?

a stripped-down !Boot structure loaded from SD card into the RAM filing system

That’s a good idea. But doesn’t the RAMFS bug still exist? If so, then the system would be running with alignment exceptions disabled… what would be the consequences if they were subsequently reenabled (maybe by some software, not necessarily by the user)?