Rick's b.log - 2014/01/04
It is the 24th of November 2024 You are 3.144.45.187, pleased to meet you!

Don't like the barrage of geekiness? Try this instead!

Some New Year geekery - JTAG one step closer

I will send out your order by China post air mail today and 40-60 days from China to you .

Unkindly, the address label shouted out my phone number. Sodding bloody eBay/PayPal. Usefully however, it was my old phone number.

Anyway, the RaspberryPi can apparently be coaxed into bashing JTAG out of some of its GPIO and since the Pi runs at 3.3V and the Neuros OSD I want to try to resuscitate also runs at 3.3V, you can join the dots... [the Beagle, contrarily, runs at 1.8V]

More geekery - patching FSLock for Modern Times

Fast forward to modern times. This distinction no longer makes much sense. As it happens, since USB sticks and SD cards are, technically, removeable media, they count from :0.

This brings us to FSLock. This module was originally written for use in an educational environment, to intercept attempts to write to the harddisc or play with the configuration. In effect, when it is running, drives :4 to :7 are read-only. In response to this, RISC OS will automatically - at boot - create a RAMdisc and set up a minimal place for scrap files and user choices (which will not persist) to be stored. Quite a clever way to try to kiddie-proof the system, which wouldn't work against the clued-up children but ought to be enough for the majority.
Unfortunately, you cannot apply the same degree of protections on modern machines. So if you set up a nice installation on a Pi for your own children, you can't lock it down (doubly so as the Pi's write-protect tab is not wired to anything!).

Until now, that is.

This modification is unofficial, not (yet?) a part of the official OS release. So in order to use it, you will need to be able to build the RaspberryPi ROM for yourself. If you have purchased the NutPi, you can! It is not that difficult actually, it just takes a really long time to do it! Follow my instructions here and you'll be all set.

Now to turn our attention to FSLock. Because this program was purchased by Acorn from a company in New Zealand, it is one of the few in the source collection that is assembled from BASIC code. If you installed your code at the same place I put it in the tutorial linked above, you will find FSLock at $.Coding.RISCOS.BCM2835Dev.castle.RiscOS.Sources.FileSys.FSLock.FSLockSRC. Load it into Zap (preferred) or StrongEd, Edit, etc.

If you know assembler, you will see that the program only pays attention to drives over :4, so all we are going to do is tweak the code to look from :0 to :3. FSLock is only designed to handle four drives, so to keep the modifications simple, we'll leave that alone. There is only usually one SD slot on most devices with RISC OS, and at most two. Alternatively, if you prefer to protect USB devices, chances are you won't be running more than four at a time...

Here are the modifications, the parts in bold are the changes:

550 helpstring$   = FNformathelp("FSLock",version%,"")+", Rick's hack#"+MID$(TIME$,17,5)

This follows ".Scan_end_of_FSName":

14320 ;
14330; Hacked by Rick to lock drives 0-3 for SDFS/USB drives, etc
14340;

14450        MOV     R1, #ASC("0") ; Drive number next...             [was '4']

14570        MOV     R9, #ASC("0") ; R9 = ASCII drive number 4....    [was '4']

Afterwards, although it looks a lot, you're only really changing four characters:

14680        CMP    R9, #ASC("0") ;                                  [was '4']

Finally, tweak the out-of-bounds catch:

14890        CMP     R9, #ASC("4") ; Drive number next...             [was '8']

That's it. Save the updated program.

Now, to build it, click Menu within the FSLock directory and choose the "Set directory ^W" option. Then double-click on the FSLockSRC program.

Open the rm subdirectory and drag the FSLock module within to your editor. Don't worry if it looks like gibberish - just look for the version string and ensure it has the suffix you added above.
For the current version, this would be: FSLock 1.22 (11 Jun 2009), Rick's hack#xx:xx (where xx:xx is the time hh:mm of when you built the module).

Here is how that would appear in !Zap - the pink boxes indicating where you should look:

And for completeness, here is how it would appear in !Edit:

Now rebuild the ROM - not completely, this time you only need to Make ROM, Install ROM, and Join ROM. This is a lot quicker than a full build.

How to use. If you are protecting SDFS, there is a quirk in that you cannot directly configure the protection to be off as the settings are held in the ROM image which is in $.!Boot.Loader of SDFS drive :0. That's right, your configuration would be discarded.

Therefore, follow this process to turn protection OFF:

• Open Configure (double-click on !Boot) and click the only thing you can – the Lock icon.
• Select “Unlock” and enter the correct password.
• Open a TaskWindow and go to BASIC.
• Enter CLOSE#255 and press Return. You’re done with the TaskWindow afterwards.
• Click on the Lock icon again and select “Unlock” again and enter the correct password again.
• Done.

Recovering data if your filesytem map is damaged

This is not a good thing to see.
In fact...

This is a very very bad thing to see.

Now, the most important advice I can give you is:

No - seriously. There is a reasonable chance that if you restart your machine, RISC OS will refuse to mount the media. Without specialist tools (for instance, DiscKnight), your data will be lost.
DO NOT REBOOT. Okay?

If you have a copy of DiscKnight, use it. Only continue with what it says below if the problem cannot be repaired by DiscKnight and you have not rebooted.

Assuming you didn't have DiscKnight... [you probably ought to get it, it's only £10! also quoted as €13,99 which is a nasty markup (about 15%), your bank may offer you a better deal if you just pay it in sterling...]

First, check you can still see your files. Open a filer window. It should work. If you cannot, or all you get is "Broken Directory", give up at this point.

If, on the other hand, you can still access files, continue!

Using another machine, you will need:

1. A blank 2GiB SD card
2. A USB SD card reader/writer
3. The RISC OS image (from here - don't worry that it is out of date).
4. Win32DiskImager (or similar if using Linux, Mac, etc).

What you need to do first is download the RISC OS image and write it to the SD card. How to do this is described here in a video.

If you are running FAT32FS, enter the command *RMKill FAT32FS.

Insert the SD card you just made into the USB SD card reader (if you didn't already do this) and then plug it into a USB port on the Pi. This would probably work better if you had a USB hub installed. If not, gently remove the keyboard (you'll definitely need the mouse, the keyboard you could work around).

Clicking on the USB device icon that appears should open the FileCore partition (you'll see !Boot and a bunch of other things). If it opens the FAT partition, dismount this and try right-clicking the icon.
If that still does not work, check that you are not using FAT32FS. You want plain old DOSFS for this to work.

Paying careful attention to the devices, you will want to copy all of your files from the older SD card (window title most likely starting SDFS::) on top of the content present on the disc you just made (window title most likely starting SCSI::) - but do not copy !Boot.

This will be time consuming and boring if you have a lot of files. But be patient. Copy everything you can - but if you see any directories that look wrong, do not go near them. In my faulty disc, I had the directories Co, Cod, Codi, Codin, and Coding. The latter was correct. The other four were not. I didn't even attempt to open them.

Now we will turn our attention to !Boot. This is the glue that holds a lot of things together. You can recover from losing this by reinstalling everything, but it is a right pain in the ass to have to do this.

Open $.!Boot on both devices. Copy everything that is not "Loader" from old to new. There's a fair bit of stuff in there, so give it time.

Now open $.!Boot.Loader on both devices. On the new SD card, delete whatever is in there, and copy across everything from the old SD card. Nominally, this will be the files BOOTCODE/BIN, CONFIG/TXT, FIXUP/DAT, RISCOS/IMG, and START/ELF.

That's it.

But we are not done yet. This is probably your last chance. Check that everything has been copied. A sneaky way to do this if you don't want to actually check every file is to do a Count on the directory on the old and the new and make sure the file counts and byte sizes match. Certainly for things like $.!Boot (3,274 files, ~136MiB) or the RISC OS sources/development (13,221 files, ~345MiB) it isn't really feasible to check off the files one by one.

When you are happy (or at least not about to suffer potty failure), it is time for a minor freak out.

Shut down your Pi, unplug it.

Switch SD cards - put the new one with all the files copied to it into the Pi's SD slot, and put the old damaged one into the SD reader.

Hold your breath, and power up the Pi.

With a little bit of luck, it should boot with most/all of your files present. And chances are you won't be able to access the files on the older card.

There.
Done.

This might be a good time, incidentally, to shut down the Pi, transfer your new SD card back to your PC and read and image of it (for goodness sake, don't write an image on to it!). This will make it easier to recover should this happen in the future.

Having learned from this, I now plan to take periodic images of the SD card so instead of going through all of this I can just image another SD card off of the most recent copy and transfer across the files that I have changed since then. Or, if I don't feel any changes there are worth worrying about, just reimage on top of the damaged one.

Something to consider

The maths is interesting.

The generic movie tends to run for 1h30, the epic you-should-watch-this can easily top two hours. Haruhi Suzumiya's movie rolls in at nearly three hours. So, to end questions of disparity, I will calculate the good running time by averaging the top ten rated movies on IMDb.

The Shawshank Redemption 142m; The Godfather 175m, and part 2 200m; Pulp Fiction 154m; The good, the Bad, and the Ugly 161m; The Dark Knight 152m, 12 Angry Men (only!) 96m; Schindler's List 195m; LOTR: The Return of The King 201m; Fight Club 131m.
As you can see, films worth watching have an extended playing time.
It's at #14 we see a film from this decade (Inception, 148m), the next being #44 (The Untouchables, 112m). It seems that the golden era of epic films was the '90s. Of the top 30, 11 are from the '90s.

Okay - mashing that all together, we get an average film playing time of 160.7 minutes. Or 2h41m. Ten minutes longer than Apocalypse Now but yet twenty minutes short of The Green Mile. Just as long as Suzumiya Haruhi no shōshitsu - epic! ☺

That seems long, so I will pick entries 42, 68, and 123 to check against. Over to IMDb and #42 is Dr. StrangeLove (95m), #68 is Taxi Driver (113m), and #123 is Heat (170m). So let's tweak our expectations down a little for a nice round 2h, shall we? That sounds a good figure.

Okay, this also helps keep the maths fairly simple. 120120 minutes (avg.) to watch 1001 films. Which as you might have already guessed, is 2002 hours. Or 167 days if you watch 12 hours of films a day. Being more realistic, four hours a day and only on weekdays. That's two films a day, ten a week; pretty much 700 days. Which is near enough two years (probably a mite more if you throw in public holidays).

Your comments:

No comments yet...