Android application to manipulate sd image from the site

aaaa

UnTarBZ has been fixed and should work correctly.

aaaa

Android?!?

As has been mentioned, extracting files on something that isn’t RISC OS will fail because RISC OS uses metadata to hold file type information.

Why complicate things with Android? Here’s a rough guide of how to do it on RISC OS native…

http://www.heyrick.co.uk/blog/index.php?diary=20131105

The thing is i have the feeling that i’ll probably have to reset the sd card a few time if i want to work on some part of the os, it would be pratical to have a tool to setup the whole sd card from the website image in one click, and i’m sure it could help some new comers to get the things running.

I believe that the U-boot startup is capable of loading the boot OS from a network (TFTP) server in which case you could have several different files on the server and swap as required.

aaaa

but tftp protocol normally it’s not supposed to serve file over 32Mo or something,

The Pi OS image is 4MB, the other baggage in the NOOBS image is disc content that is largely applications, utilities, games.

I was thinking you’d be working to produce small modules to hook into the OS or a revised OS image around 4MB and loading that, once that’s loaded any disc content can be loaded locally.

aaaaa

aaaa

aaaaa

The thing is it’s in the very likely case where i’ll find myself with a crashing non booting system, and bugged source, that i can have a way to restore clean system without loosing 1h dl/burn/dezip everything. I don’t see any other way to do this than from an android application, because it’s the only device i have that can manipulate sd card.

It depends upon how much you value your time. I’m assuming that you have a generic PC. You can pick up fairly inexpensive USB→SD adaptors, and there are even tiny USB→µUSB things too. Performance won’t set the world alight, but it’s better than other options.

Then, you can just use the image reader/writer applicable to your system (Win32DiskImager for Windows).

it doesn’t unpack the thing, well it did decompress the bzip2 archive to the tar, but i was unable to make it untar the tar file

Which file did you download and attempt to unpack?

I guess there isn’t any hope to fix the file attribute thing from android ? The source tree has to be stored on a riscos file system and extracted by riscos, there is no way to do this from any other os at all ?

Pretty much, no. I believe there is some rudimentary support for Filecore media in ArmLinux, so you might be able to write a filing system? Otherwise, no. I’d like to be able to use Filecore content natively under Windows; but it isn’t possible, too many differences (and Windows historically is crap and anything non-Microsoft).

Otherwise the most sensible thing to do i think is that

…buy a little USB SD interface for your main computer. Set up the RISC OS machine as you like it, then take an image of the SD card. If something should happen, just re-image the SD card.

Additionally – be sure that when you copy your custom ROM image to the FAT partition, you keep the previous one (rename it “riscos.old” or something). That way, if it all goes wrong and won’t boot, you just need to pop the card into the reader, and on the PC, rename “riscos.img” as “riscos.kak” (or whatever you like) and “riscos.old” as “riscos.img”. It will then boot with the previous (good) version. No wasting hours and hours.

I don’t know about your neck of the woods, but E.Leclerc sells these things for about €7,00 for a basic model. If you have a specialist shop you might be able to get one cheaper. Some µSD cards come with a reader. Or the cheapest way of all, hit eBay. €7 is about an hour at SMIC rates, so… yeah… it’s a better option, really. ;-)

aaaa

aaaaa

aaaaa

So i struggled with android and eclipse a little bit, but i got the thing to compile and run and so it can read the sd card sector/sector, and already managed to compile some of the code to manipulate the file system.

Sounds interesting. Do you need to have a rooted device, or can this run as an app on generic Android? Mmmm, would generic Android even attempt to do anything with an SD card in an unknown format? Well, it will mount the FAT part, but the rest?

So on the riscos image, there are 2 partition, that are wrote as regular partition in the MBR of the sd card like regular partition entry, with one as fat and the other as sdfs ?

I don’t think we use MBR at all (any confirmation?) and generic Filecore doesn’t support partitioning. It has always just assumed that a connected drive will be such and such a type of drive. It is possible to partition with other people’s firmware – my RiscPC has a large drive (8GiB?) in five partitions via a Simtec IDE card, but it is a mechanism specific to Simtec. For all I know it lies and fakes there being five harddiscs?

The way the dual format SD card works is, essentially, smoke and mirrors. Thanks to luck, the sectors important to SDFS are not the same as the ones important to FAT. So an SDFS format volume is created first. Then with a lot of care, a smaller FAT volume is created within the SDFS volume. Both start “at the beginning of the media”. From the RISC OS side, the FAT partition is marked out by wiping the space out of the free space map and mapping it out as “there is a file here”. RISC OS believes that the FAT volume is “just a file” and since DOSFS can access FAT images, we can access it via RISC OS in that manner. Note: As a result of this, the FAT volume ($.!Boot.Loader) can be opened and the files within changed, but the Loader file itself must not be altered (copied, deleted, etc). You can move it (say, from an old !Boot to a new one) but if you copy it, it will copy as a regular file and all of the specific and important associations with the FAT side will not be preserved. That would be a bad thing.
I have not checked, but I would imagine the initial sectors that are important to SDFS but appear within the FAT area (boot block, for instance) would likely be mapped out as a “bad sector”. In that way, a FAT system will leave those sectors alone.

When inserted into anything non-RISC OS, the device will see the FAT partition and mount it.
When inserted into RISC OS, the SDFS partition will be seen and used.
Clever!

I wanted to make my own software to create a 4GiB SD image (as 2GiB cards are harder to come by these days) and maybe to make a Beagle xM compatible version. It is… really complicated. Deep magic, smoke and mirrors type stuff. ;-)

Make life easier on yourself if you want larger SD cards → http://piccolosystems.com/disctools/systemdisc

aaaaa

aaaa

aaaaa

but it wouldn’t make much sense to make several filecore partition on the same physical drive.

For smallish drives that is true, however modern drives are tending to be rather large and partitioning to keep map sizes down is useful. (See the bounty page for the requirement to make the system partition aware).

aaaaa

Maybe the shortest route to get there would be to emulate whole hard drive, with a certain number of cylinder from the whole drive and call it an harddrive, and make filecore consider it as a drive of its own.

True. But Filecore should also be simplified/optimised for SSD as hard drive are EOL products now.

Early Acorns were limited to 31 files per disk (BBC B & Master etc.). All RISC OS computers were limited to 77 entries per directory until RISC OS 4 appeared.

RISC OS machines rarely spend noticeable time accessing discs. The operating system and native applications very rarely have more than 40 entries per directory and programs normally load as single file so the type of filing system optimization you are talking about weren’t really necessary.
Here at CJE we do now notice a significant slowdown when accessing our product images directory which has grown to have 1600 files in it! Though with faster hardware coming along it isn’t a problem for us and I suspect there are other areas that would benefit more from time being spent on them.

aaaaa

It could work the same with sdcard

+ TRIM support of course. I hope Picollo Systems will ad this some day.

Not sure how windows behave in such situation

Windows users saving images on a windows server in a file structure referenced by a database with naff indexing complain that the network is slow when trying to retrieve one of the 7,000 plus images all held in one directory.

Cynical? What? Anyone would think I maintain the network and get annoyed about the misattribution of the problem. Wireshark delta values for request in to server and data send from server didn’t convince the database authors. Idiots.