Armbook problem - no OS disk not formatted

After installing th ROM. I put Hard disk 4 on and ran Disc Updates and got it to boot.

But the video is quite interesting as I have 3 mini desktops, so I think I’m missing the video driver.
Now I have hard disk 4 on there, I might try running the rom install again to see what happens. Had to turn it off via the power switch again as I couldn’t really see what I was doing…

Sadly that killed the SD card again. So I’m back to having to reformat it… Oh well, such is the way of these things…

I think I’ll try again tomorrow.

Although given I have never been able to kill an SD quite so easily before & I would have expected some visible files from the OS ROM install, it could be a bad card…

So I might try a different one.

I would have expected some visible files from the OS ROM install

I don’t recall seeing any visible files after running !A64ROM-scsi0, and to be honest I wasn’t expecting to see any: the instructions make it clear that you have to install a full HD4 backup from a working ArmBook SD card after installing the ROM.

I think your best bet is to get a replacement SD card from R-Comp.

Something I did find was when it broke *RMReinit SDFS would let the Armbook see the card again. I never got to the bottom of it, I copied everything off, used a Raspberry Pi to reformat and install the ROM image and then copied everything back.

I don’t think the OS ROM install places any files on the card (like the Pi does) – it maps out the ROM area as defects, so the card will look blank to RISC OS.

When you reformatted did you keep the existing shape / defect list? I think I intentionally didn’t in case that was causing a problem.

Trying a different card probably wouldn’t hurt though – given it’s died twice.

As expected Verify reports “too many errors”. So not much hope there.

‘Too many errors’ or ‘Too many defects’

If the armbook is like the armx6 then ‘Too many defects’ is normal.

When the os is put on a new riscos formatted sd card !OSUpgrade or !iMx6upg maps out defects in certain sectors of the card and puts the loader,rom and cmos in those sectors. Presumably you boot to an internal SSD so the sd card doesn’t need any other files on it and can look blank and verify will indicate defects. The files on the card you got with the machine will be just backup.

Note if you are inclined to build your own roms !iMx6upg can be used to load a rom built from the rool sources. After compiling the rom running !iMx6upg will detect the rom just compiled and load it on the sdcard. The rool imx6 sources don’t have Isochronous USB – not a problem for me – but otherwise I have no problem with them. If anyone is inclined try the rool rom please use a different sd card so you can go back to a working version – I wouldn’t like this post to cause Andrew a headache. You can swap the card when the armx6 is running – easier on a bare board armx6.

To prepare an sdcard the first time use a blank newly formatted card. Once the defects have been mapped in you can put other stuff on the card if you want. Running the !imx6upg or !OSUpgrade on a card with the defects already there doesn’t affect the riscos visible part of the card.

The easiest way to recover the defects is to format the card on windows and then format it on riscos.

What is the Pinebook/Armbook like – ie keyboard tracker/mouse buttons – sound , nice to see if Sib runs. Connection to wifi.

When the os is put on a new riscos formatted sd card !OSUpgrade or !iMx6upg maps out defects in certain sectors of the card and puts the loader,rom and cmos in those sectors.

Have R-Comp developed their own “partitioning” system, then? The rest of the RISC OS world formats as standard filecore, then carefully places a “DOS Partition” file (usually named “Loader”) over part of the disc which it formats to be visible as FAT32. That way, the FAT32 bit is completely accessible on RISC OS, too, using the “partition” file. This is fine unless the DOS file is deleted, because re-creating it will invariably put it somewhere else on the Filecore map and leave the FAT32 partition exposed to writing over by Filecore.

Not really. The section used to store the boot files is not readable on a pc either – unlike the system used on a pi. I think the bootstrap code reads certain addresses on the card directly – there isn’t a directory. Once the card is programmed with the os – which you have to do the first time on a blank filecore formatted disc (if it is not blank it may be corrupted) – you can reformat the disc with filecore and not lose the loader files (so RISC OS will still boot) as long as you don’t remove the defect list when reformating. This also means you don’t have to be careful about moving !boot unlike the pi.

Wow. It’s kind of crazy that such a modern device won’t even try to grok FAT32…

https://linux-sunxi.org/Bootable_SD_card

The OMAP3 was peculiar and finicky, but at least the files (when it agreed to recognise them) were a standard partition, and we’re positively spoiled by the Pi’s bootloader.

Not a fan of the pi scheme. I’m a bit disappointed it hasn’t been replaced by a proper partitioning scheme by now – the number of times I’ve temporarily moved !boot (quickly followed by doh!).

It’s quite normal for many modern ARM boards, Rick. They look for a boot sector on the card, and go from there (often they only read a small chunk, too, which is a bit awkward for RISC OS with its 4MB ROM). As Colin says, there’s pros and cons, but I can’t think of even one time when someone has accidentally made an ARMX6 unbootable, except for an accidentally “popped out” microSD in transit one time.

The “defect” method is just a way to ensure that RISC OS can use the disc, and doesn’t try and overwrite the bootable region. I’m sure someone could concoct a better way, but it has worked well for 5+ years now.

Also worth pointing out that the first few sectors are ignored by the boot firmware, so it is possible to stick a partition table in there and mark the boot firmware as one of the partitions, and then fill the rest of the space with whatever standard partitions your OS wants.

However we do have to wait for the partition support bounty to be completed before we’ll be able to use that approach (and proper Pi SD card partitioning) with FileCore/RISC OS

Not a fan of the pi scheme.

I use it for my Beagle too. Sadly it’s a necessity until RISC OS catches up with the rest of the world and learns about partitioning. In which case, like pretty much every other operating system, the entire issue simply disappears.

Either its a small FAT partition followed by whatever the OS uses, or its just some space marked off as “don’t touch” followed by whatever the OS uses.

Defect lists and applied Loader magic are basically fudges until then…

Still surprised the bootloader is that dumb, mind you.

On a more technical note, how is partitioning actually handled? I have on the old RiscPC a big disc (10G?) which is split into a bunch of partitions via Simtec IDEFS.

Is it something particularly clever, or it is basically taking the regular disc address and adding in the offset to the start of the relevant partition? So if the root directory is at &123000 and the partition starts at &200000, the actual address looked at would be &323000… Is that sort of how it works?

basically taking the regular disc address and adding in the offset to the start of the relevant partition?

^ That.

Not really. The section used to store the boot files is not readable on a pc either – unlike the system used on a pi.

I noticed that. The only contact I’ve had with the Pinebook version is that one version from last year linked to by the Pinebook Wiki. Sadly it doesn’t support the 1080p resolution screen on my Pinebook 11" so it displays a garbled desktop reminiscent of a CRT with an unsupported HSync. For fun I dug into the disk image to see what was going on, and also had a poke around via serial at U-Boot. For reasons which I am sure are known to them they opted to use U-Boot in raw sectors instead of as a partition. I also ripped the ROM from the image to satisfy my curiosity on the CPU mode change. Is there a clause against reverse engineering? I don’t recall it coming with a proprietary software EULA or anything. Whatever.
I guess what I want to say is guard your SD card closely. Do an image dump to keep it safe. There is no fixing it if anything goes wrong.