RC15

I think the image ought to be 4GB. I don’t know about you guys, but it is damn near impossible to find 2GB cards in the shops, and when you do find one, it is often noted as being “SD” as opposed to “SDHC” for compatibility with older devices. That’s a clever way of saying “costs more than a 16GB branded card”!

I still don’t understand why we have to have this dos partition as a file hack.

It would be much nicer if the disk structure had ADFS as the first partition, with a DOS style entry for the registered type, and then had the FAT partition after. (The remainder of the disk would be able to be manipulated with regular tools on other systems.)

It is possible to mark the RISC OS partition with its length etc. (appears in partitioning software as type unknown) and to mark the DOS partition (as normal) but you then have difficulty in saving CMOS settings as you can’t easily see the DOS partition and not at all from SDFS. Using fat32fs has its own issues. Better is to make RISC OS aware of partition tables, identifying where the filecore partition and the DOS partition (separate) are located so that it can see the DOS partition on is own.

I still don’t understand why we have to have this dos partition as a file hack.

Because the RO file system doesn’t support multiple partitions at present and the first stage bootloader needs a FAT style partition to load the second stage bootloader from.

It would be much nicer if the disk structure had ADFS as the first partition, with a DOS style entry for the registered type, and then had the FAT partition after.

Indeed it would, which is probably why the Filing System Improvements part 2 bounty was created…

Because the RO file system doesn’t support multiple partitions at present and the first stage bootloader needs a FAT style partition to load the second stage bootloader from.

But that’s not what I suggested.

RISC OS doesn’t support partitioning at present. However it does support different disk sizes. It also ignores partition tables.

Therefore create a regular format as though the disk is smaller, Then make a corresponding entry in the partition table (apparently ROOL have registered a type for ADFS). Then the FAT partition (and others for different OSes) can be created in the space remaining.

This should work with current RISC OS (for the single partition only) and be compatible with partition aware OSes (including hopefully a future RISC OS).

i.e a small stepping stone to the bounty

Then the FAT partition (and others for different OSes) can be created in the space remaining.

Problem. ADFS expects that it is the first (only?) thing on a device.
Bootloaders expect the FAT partition to be the first thing on a device.

If it was as simple as sticking FAT at the end, we wouldn’t need this complicated bit of magic…

Is the bootloader that dumb? It just looks at where the first partition should start rather than the partition table? (Even it it’s hard wired to the first entry, that’s shouldn’t be a problem)

Problem. ADFS RO expects that it is the first (only?) thing on a device.
First stage Bootloaders expect the FAT partition to be the first thing on a device.

Minor amendment to your text. ADFS isn’t the issue and I’m pretty sure it isn’t present on various of the current builds (OMAP3 for one)
The problem of course being that said first stage bootloader is in the SoC and generally cannot be changed.

Is the bootloader that dumb?

Yes.
It’s the very simple first stage bootloader baked in to the SoC we’re talking about.

That looks for a file system holding the second stage bootloader which is what sits in that hacked in FAT based partition. Limited space for the code and consequent limited capability for reading file systems.

Steve – fair point, I was writing it in a hurry… It is likely FileCore rather than any specific file system (although some in the past have worked around this in various proprietary ways, such as Simtec IDEFS).

Yes – bootloaders are generally extremely dumb. Look at the OMAP where not only does the FAT have to be the first thing on the device, it also needs “MLO” to be the first thing it finds or else it just won’t boot…

Update – I just used gparted on an old pi card I removed all the partitions except the pi-boot. I then resized and moved it so there was 1GB empty before it, and formatted it.

I copied the contents of a NOOBS download to it and tried it.

It worked as far as to the partition resizing, (understandable).

This implies that whereas RISCOS needs the first space on the drive, the bootloader needs the first partition entry. These are not mutually exclusive, though I expect there will be a limit within which the pi boot partition must be contained.

I still don’t understand why we have to have this dos partition as a file hack.

We don’t. It’s just a way to access the DOS partition from RISC OS.

With Systemdisc you have:
Format 100% of the card with ADFS.
Make a FAT partition somewhere on the disc.
Put a file in the ADFS partition that maps exactly the space used by the FAT partition.
Tell this file it’s a DOS formatted virtual disc.
When you write in one, you’ll write on the other, since they use the same space and format.

Alternative :
- Format 90% of the card with ADFS.
- Make a FAT partition at the end of the disc (on the last 10%).

And it will work perfectly too. But no Loader any more.

I should point out that the Pi bootloader is quite clever – so one can do stuff like unpacking NOOBS to a blank card and It Just Works.
Other bootloaders are not as smart. Not even slightly.

As I said, I tested my Pi with a single partition that was not at the physical start of the the disk and it loaded.

This thread is about the Pi release, not those for any other systems, so if they look for a DOS partition at the start of the drive, rather than where the first partition entry says, why would that be relevant?

Although it would potentially allow one image to do the Pi and another system.

Although it would potentially allow one image to do the Pi and another system.

I wonder how many people have taken the Pi image, reformatted the FAT part, and set it up for a different device? Certainly it is simpler than a FAT (micro)SD card and a FileCore partition on another (USB) device.

When I formatted my uSD card with SystemDisc, I set it up first with the boot files for the Beagle. Afterwards, I added the Pi files. So it should boot on either device, though I’ve not tried the Beagle boot as my Pi is always on, but it should work.

As I said earlier, the Pi’s bootloader is pretty (impressively) flexible.

This thread is about the Pi release, not those for any other systems, so if they look for a DOS partition at the start of the drive, rather than where the first partition entry says, why would that be relevant?

It started as a thread about a potential new release of the full blown system image tailored for the Pi but the proper use of partitions vs hacks was raised – thread drift.
Since the current Pi OS build saves the CMOS settings to a distinct file in the hack/file and the previous versions saved it into the ROM image in the hack/file then RO needs access to the hack/file. Done, sorted, sort of…

Now make the loader sit in a partition along with the ROM image (it needs to sit where the bootloader can see it).

Now save your CMOS settings to the ROM image, or to the distinct file, sitting in the FAT partition – isn’t that a bit difficult if RO doesn’t understand partitions?

When I formatted my uSD card with SystemDisc, I set it up first with the boot files for the Beagle. Afterwards, I added the Pi files. So it should boot on either device, though I’ve not tried the Beagle boot as my Pi is always on, but it should work.

I suspect that if you had that setup in a bootable FAT partition and RO understood partitions then a partition based build should be more portable in fact the loader/OS image partition can be changed independently of the System/application partition. Preparation of new loader/OS partitions can be done on other platforms with standard tools.

I created an SD card which boots in both my RPi and my Beagleboard, after I got fed up keeping separate ones in step, and then wondering which was which! Just a matter of being very careful what is in the Loader partition.

Steve – I used my XP box to blank and copy the FAT “partition” files, then did chkdsk on the PC and CheckMap when back in RISC OS.
That’s what SDFormatter is about. Once a “small” FAT partition has been created, that’s all Windows will ever see, so SDFormatter reads the actual card size and restores it (‘cos Windows format can’t).

;-)

Of course, proper partition support would be easier, but….. [insert long list of things Acorn should have done]

@ Chris Evans:
bq. I see where you are coming from,
why? I am responsible for what I write, not my country.
bq. but !SystemDisc is commercial software
I know that. Have bought it myself and its worth its money. I don’t want anyone loosing money from what’s their rightful IP at all, if you might think I’m after that. I wrote ‘it might be a charged download’ and ‘Hform with Systemdisc -capabilities-’.
However it shouldn’t be that since !Systemdisc exists nothing can be improved anymore on how RCxx is distributed. The idea is faster in use, needs only one SD-card, no external cardwriter and, if the !Hform part is automated, no Riscos knowledge. On Raspbian, expanding the card size is automatic, Ubuntu only needs one button. Both need only one card and no ext cardwriter, many people even don’t have such a thing.

bq. I see where you are coming from,

why? I am responsible for what I write, not my country.

Small misunderstanding Jan, the words “I see where you are coming from” are a colloquialism meaning they understand how you are thinking when you say “An idea for RCxx distribution”

BTW. The bq use needs a blank line before the quoted line ( blank line, bq dot space ) and a blank line to end the quoted bit.

I’m sorry Steve.
Didn’t know both things.

No problem.
We agree that there needs to be more support in the build for partitioning, resizing etc.

Didn’t know both things.

That’s okay. Expressions are often confusing in any language. In English when it rains hard, “it’s raining cats and dogs”. I’ve had a few soakings in my life but I’ve never ever seen any furry creature fall out of the sky…

Here in France, calling somebody an “espèce de chameau” is so much worse than calling them a “chameau”. And when the poop hits the fan, a phrase often heard is “la vache!”. I refer to this as “invoking the cow” as saying “the cow!” doesn’t make a lot of sense. Then again saying “bloody hell!” doesn’t either…
Sometimes when you say “merci” the reply is “c’est moi”. That, at least, makes e when you know what it means.
Expressions are difficult.

(^_^)

espèce de chameau

That because they’ve “got the hump?” :)
Heading for Aldershot perhaps?