Multi Boot for Armini

That’s a good idea. But doesn’t the RAMFS bug still exist?

Yes but..

No-one seems to be able to cause a malfunction when the size is fixed non-zero on boot-up and then left alone.

Thanks – that seems fine then (as the size can’t currently be altered once it contains files).

How easy would it be to extend the idea of loading a small file ‘cmos’ from the SD card under the control of RISC OS [before it gets to the ‘booting’ stage as the file ‘cmos’ may determine the boot drive] into searching for, and loading if present, a larger file (perhaps several megabytes) which would form the contents of an initialised RAM disc which could then be set as the boot drive.

This idea (which I have called RISC OS Lite and added it to the ‘Bounties’ discussion thread) would allow a bare Beagleboard (i.e. one with no external RISC-OS formatted boot drive) to have what could be described as a ‘validation’ RISC OS SD card image which would allow various features of the card to be operated. Even to format and populate a pen drive with a RISC OS Boot structure.

As the target hardware would be known, the image on the SD card, including ‘cmos’ and the larger ‘RAM disc contents file’ could be set by default to present itself to the prospective user, with no familiarilty or experience of RISC OS, as an immediately working example of a RISC OS desktop. Perhaps it might attract new users?

Adding a particular application to the !Boot structure to be run on initialisation would turn a Beagleboard into a dedicated item, such as a ‘point of sale’ terminal or whatever.

Even better (but more work involved to implement the starting up of a non-RISC OS uImage from within RISC OS) if we then offer the user the ability to select boot options other than RISC OS (command-line Linux, GUI Linux for example) from the RISC OS desktop. Thus making it [the SD card with RISC OS Lite (and perhaps other operating systems as well) on it] useful even to someone with no knowledge or requirement of RISC OS but just to select how their BeagleBoard should start up in a friendly way. Sooner or later they would look at the RISC OS desktop – even if just out of curiousity.

Even for the RISC OS user, we could offer several choices: if the ‘cmos’ boot drive was indeed the RAM disc [or there is some way to provoke a ‘factory default’ start up (akin to power-on-delete) which would boot using the RAM disk] other options could be to re-boot up from a manually selected SCSIFS drive.

Functionally, this would be very similar to a Beagleboard which used the SD card as its !Boot drive but with the following advantages:
- no worry about writes to the SD card shortening its lifetime;
- only a few tens of megabytes lost to provide the RAM disc;
- the SD card can offer other boot options other than just RISC OS.

searching for, and loading if present, a larger file (perhaps several megabytes) which would form the contents of an initialised RAM disc

In principle there is plenty of room on the fat32 partition of the SD card. So if we can (i) decide what bits of the !Boot image are ‘luxuries’ and can be cut right down [if any]; (ii) find a way of saving the contents of a RAM disk in memory into a single file and (iii) searching for and loading such a file so that it is present as a RAM disc from which RISC OS can boot, then such an approach is, prima facie, possible.

My contention is that it would be a vaulable and useful thing to be able to do.

So this would create a “LiteBoot” alternative to “UniBoot”?¹ What about Putting Scrap on a RAM Disc? Is the required memory info referred to at FileSys/RAMFS/RAMFS/Doc/CoreNotes2 (RAM ptr & length)? Am I right in thinking this would be quite easy for someone knowledgeable to check?

[Edit: It looks like OS_ReadRAMFsLimits would do the trick.]

¹ Is the RO5 boot still termed UniBoot?

I think this is good idea but I also see some problems with it, I used to own & run Microbits in the uk so i have a little bit of insight into what a customer wants.
Problem 1
anybody new to Risc OS will not have any clue how things work (it’s ok for us we have used it from ver 2)
so the first thing the the see is a blank desktop, so the first thing we must do is to present a text file with instuction on how to use the desktop, mouse, menu’s etc.
problem 2
how to run apps and what apps to include to give them a good idea that they can get from The OS.
A good plan might be to have a running demo of how all apps work together to make a better system.
there was a piece of software that recorded keypress,s i think it was called !keystroke that we could use (we all no how but users from different systems do not. do we have them as short cuts on the desktop???)
anybody else care to add there ideas.

anybody new to Risc OS will not have any clue how things work

Not sure it’s quite as bad as that. When I tried the Linux GUI I knew nothing about Linux but was able to look around and work out what was happening. I agree that we need to give some clues: for example we need the application !Help in the Apps folder (it’s in Resources so therefore in ROM) and perhaps to auto-launch it as well so that it’s on the icon bar.

A good plan might be to have a running demo of how all apps work

Virtual Acorn does something like this I think with a few Help files on the default Desktop. Easiest perhaps is a Netsurf window (or !Pheonix or !Webster) with the information held externally on the web?

But I think this is detail and polish. Adding helpful text is something we can build on, almost anyone can suggest – why not add a reminder that…

The fundamental thing is can we provide such functionality in RISC OS itself?

So this would create a “LiteBoot” alternative to “UniBoot”?

It’s not actually that necessary (certainly at first) to cut down the !Boot image. The standard HardDisc4 image is actually just 14Mbytes and I would suggest that a RAMdisk of about 64Mbytes is quite tolerable. It just cuts the ‘RAM available’ down from 512Mbytes to about 446Mbytes.

[Edit: It looks like OS_ReadRAMFsLimits would do the trick.]

So step (i) is unnecessary.
Step (ii) is relatively simple as we know where the RAM disc resides and can save a file with its contents.
Step (iii)

searching for [on the SD card] and loading such a file [into memory] so that it is present as a RAM disc [in memory where RISC OS allows and expects a RAM disc to be] from which RISC OS could boot [so that ‘cmos’ could select it as a boot source and it be intact at boot time]

This functionality could be added to RISC OS (Beagleboard entry point) without affecting existing users (as a file called whatever we choose to call it, say ‘RORAMDisk’ would not exist on their SD card).

Would it be possible to put boot in resourcesfs, like paint, draw, etc?

(It would obviously need to be modified to work with being read only.)

Not sure that a read-only !Boot structure would work. I can think of lots of applications that need it to be read and write.

Don’t NCs run from a common read only network share?

I would think you would need a special version of !choices that silently discards changes (if a full version hasn’t been seen) and !scrap would need to be RAM based.

• !Boot
• Partition support in RISCOS

!Boot

I agree that (at present) simplification of the !Boot structure is for another day.

Partition support

I do not agree with the quote below:

To be able to use the BeagleBoard internal SD card as a bootable device for RISCOS itself but also to boot riscos from it, we need partition support too.

at least in functional terms. The Linux distro provided with the Beagleboard uses a ramdisk to boot itself up, and the ramdisk is provided in the fat32 partition on the SD card.

The method described above in my earlier post achieves the functional ability to boot RISC OS from the SD card (by loading a RAM disc from the SD card and booting from that) at a sacrifice only of about 64Mbytes of memory. This allows a scrap dir of about 40Mbytes and no change to the ‘standard’ HardDisc4 disc image including !Boot [which would occupy about 14Mbytes of the 64M RAM disk].

What about Putting Scrap on a RAM Disc

I agree with the thread quoted. This only makes sense if there is no external storage available and then it is purely for compatability reasons for applications that expect it. My idea, where the only external storage is read only (the SD card) fits this criterion.

I do not agree with the quote below:
“To be able to use the BeagleBoard internal SD card as a bootable device for RISCOS itself but also to boot riscos from it, we need partition support too.”

I think it means to use the internal SD card like a hard drive.

(However, would it be possible to create the required FAT partition above an ADFS partition, with a suitable partition table? As can be done, with a lot of fiddling, on USB drives.)

Wouldn’t it be possible to create a RISCOS HD image (ISO) file on the FAT formated SD card. This file could be used by a ‘SDFS’. You only need to add a fixed number of sectors to read the image.

This way it would be very simple to create a SD for RISCOS. Copy the bootloader, the cmos file, RISCOS and the ‘HardDisc4.iso’ file to the SD card.

The validation image for the Beagleboard

[beagleboard-demo-201008201549-configured.img.gz]

Two scripts then control how the Beagleboard boots, ‘user.scr’ and ‘boot.scr’ as follows:

boot.scr:

led all off

sleep 1

led 0 on

sleep 1

led 1 on

led 0 off

echo Press USER button to enter Angstrom GUI

sleep 10

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:1280×1024MR-16@60’; setenv bootcmd ‘fatload mmc 0 0×80300000 uImage; bootm 0×80300000’; boot; fi

echo Entering RISC OS

fatload mmc 0 0×80100000 riscos

go 0×80100000

user.scr:

led 1 off

mmc init

setenv dvimode 1024×768MR-16@60

setenv vram 16M omapfb.vram=0:8M,1:4M,2:4M

setenv console tty0 console=ttyS2,115200n8

if test “${beaglerev}” = “AxBx”; then

setenv rdaddr 0×81000000

setenv optargs mem=80M@0x80000000 musb_hdrc.fifomode=5

elif test “${beaglerev}” = “Cx”; then

setenv rdaddr 0×88000000

setenv ramroot /dev/ram0 rw ramdisk_size=131072 initrd=${rdaddr},128M

setenv optargs mem=80M@0x80000000 mem=128M@0x88000000 musb_hdrc.fifomode=5

else

setenv rdaddr 0×88000000

setenv ramroot /dev/ram0 rw ramdisk_size=131072 initrd=${rdaddr},128M

setenv optargs mem=80M@0x80000000 mem=384M@0x88000000

fi

run loadramdisk

led 0 off

run loaduimage

led 1 on

run ramboot

Thus the ARMini will now boot up into one of the following three operating systems:

User button not pressed – RISC OS
User button pressed immediately after reset – into command line Linux
User btton pressed a few seconds after reset – into Angstrom Linux GUI

One useful thing now is that I can leave the SD card in the micro slot on the Beagleboard, start the Angstrom Linux GUI and copy a file (a risc os rom image for example) from somewhere on my network directly onto the Sd card.

So this would create a “LiteBoot” alternative to “UniBoot”?1 What about Putting Scrap on a RAM Disc? Is the required memory info referred to at FileSys/RAMFS/RAMFS/Doc/CoreNotes2 (RAM ptr & length)? Am I right in thinking this would be quite easy for someone knowledgeable to check?

An illustration of what I mean is here – it is a bit long-winded but would require no user twiddling at all [just three files on the SD card – ‘riscos’, [‘cmos’] and ‘ramfsimage’] if RISC OS could load a RAMFS image from SD card into RAMFS and then (if it was present) boot from it.

That is https://www.riscosopen.org/forum/forums/8/topics/703?page=1#posts-7970 unless anyone can think of a more elegant way of referencing it.

just three files on the SD card – ‘riscos’, [‘cmos’] and ‘ramfsimage’] if RISC OS could load a RAMFS image from SD card into RAMFS and then (if it was present) boot from it.

Is there anything I can do to help code such a facility? It should be easy if whoever coded the ability to load ‘cmos’ into RAM, protect it, move it to somewhere safe etc. offered assistance/knowledge. It would be ‘harmless’ to users not interested in this functionality (no file called ‘ramfsimage’ on the SD card means no action would be taken) but it offers a superb way to introduce new users that just have a Beagleboard with no RISC-OS formatted external storage. They would then have everything necessary to try out RISC OS, create a formatted pen drive with a !Boot image (if they wanted) etc. etc.