Re: [E3-hacking] Config / content filesystem

2019-04-18 Thread Nick Griffin 
live@commodoreos /media/live/E3
READY.
sudo nand-oob-strip.py e3-nand-backup.0 e3-nand.0: No such file or directory


Spanner..

http://amstrad-e3-hacking.freeforums.net

From: Jonathan McDowell
Sent: ‎Thursday‎, ‎18‎ ‎April‎ ‎2019 ‎21‎:‎09
To: Discussion of the Amstrad E3 emailer 
hardware/software

Yes, you run it on a proper Linux box, not the E3. The script isn't
going to magically fix anything, but it'll turn the dumps that include
OOB information into dumps without OOB information that might help you
do some sleuthing about their contents.

On Thu, Apr 18, 2019 at 12:52:37PM +, Nick Griffin wrote:
> Where do I put attached Python script, in my Linux not in the E3..?
>
> So I do each file with it..?
>
> Spanner..
>
> From: Jonathan McDowell
> Sent: ‎Thursday‎, ‎18‎ ‎April‎ ‎2019 ‎11‎:‎58
> To: Discussion of the Amstrad E3 emailer 
> hardware/software
>
> On Wed, Apr 17, 2019 at 01:26:40PM +, Nick Griffin wrote:
>
> > Do you remember if you were able to mount the Cramfs and look at its
> > filesystem..?  What's Q;Q; blocks in flash, another files system…?
> > Can’t find any info on it, were you able to mount that too. So does it
> > have 2 partitions on mtd4 then..?
>
> You need to remember the E3 dates from a time when embedded Linux
> systems were a lot simpler, and the E3 was designed to be a low cost
> platform (even allowing for the subsidy). It doesn't have the sort of
> NAND setup seen on modern systems; it simply didn't have the resources.
>
> So, the MTD partitions do not directly map to a kernel or a Linux
> filesystem. The "Q;Q;" blocks are an Amstrad specific way of putting
> data into those partitions, with a type + description associated with
> each one. For example the kernel lives in a Q;Q; block in mtd3 called
> "LINUX". mtd3 also has Q;Q; blocks for LDR (the second stage boot
> loader), and PARMS (the kernel boot parameters).
>
> The CRAMFS filesystem is in mtd4; Q;Q; block name "LNXFSYS". There are 2
> of them (I imagine to allow for an active + fallback). There are various
> other bits of content in mtd4 too - you can see them by doing:
>
>  hexdump -C e3-nand-backup.4 | grep -A 1 "Q;Q;"
>
> Finally the nanddump files have 16 bytes of out of band (OOB) data per
> 512 byte block, so if you want something that might be writable back to
> the flash you need to strip those out. The attached Python should do the
> trick:
>
>  nand-oob-strip e3-nand-backup.0 e3-nand.0
>
> will dump out e3-nand.0 with the OOB data stripped.

J.

--
I'm dangerous when I know what I'm doing.

___
e3-hacking mailing list
e3-hacking@earth.li
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.earth.li%2Fmailman%2Flistinfo%2Fe3-hackingdata=02%7C01%7C%7Cec5f9e059ac04cfb6dfa08d6c439c19c%7C84df9e7fe9f640afb435%7C1%7C0%7C636912149665586653sdata=DdEDodAV1hnS9KjUDy6bAmwvHU5phkgshzFfYCk9r8Y%3Dreserved=0
___
e3-hacking mailing list
e3-hacking@earth.li
https://www.earth.li/mailman/listinfo/e3-hacking

Re: [E3-hacking] Config / content filesystem

2019-04-18 Thread Jonathan McDowell 
Yes, you run it on a proper Linux box, not the E3. The script isn't
going to magically fix anything, but it'll turn the dumps that include
OOB information into dumps without OOB information that might help you
do some sleuthing about their contents.

On Thu, Apr 18, 2019 at 12:52:37PM +, Nick Griffin wrote:
> Where do I put attached Python script, in my Linux not in the E3..?
> 
> So I do each file with it..?
> 
> Spanner..
> 
> From: Jonathan McDowell
> Sent: ‎Thursday‎, ‎18‎ ‎April‎ ‎2019 ‎11‎:‎58
> To: Discussion of the Amstrad E3 emailer 
> hardware/software
> 
> On Wed, Apr 17, 2019 at 01:26:40PM +, Nick Griffin wrote:
> 
> > Do you remember if you were able to mount the Cramfs and look at its
> > filesystem..?  What's Q;Q; blocks in flash, another files system…?
> > Can’t find any info on it, were you able to mount that too. So does it
> > have 2 partitions on mtd4 then..?
> 
> You need to remember the E3 dates from a time when embedded Linux
> systems were a lot simpler, and the E3 was designed to be a low cost
> platform (even allowing for the subsidy). It doesn't have the sort of
> NAND setup seen on modern systems; it simply didn't have the resources.
> 
> So, the MTD partitions do not directly map to a kernel or a Linux
> filesystem. The "Q;Q;" blocks are an Amstrad specific way of putting
> data into those partitions, with a type + description associated with
> each one. For example the kernel lives in a Q;Q; block in mtd3 called
> "LINUX". mtd3 also has Q;Q; blocks for LDR (the second stage boot
> loader), and PARMS (the kernel boot parameters).
> 
> The CRAMFS filesystem is in mtd4; Q;Q; block name "LNXFSYS". There are 2
> of them (I imagine to allow for an active + fallback). There are various
> other bits of content in mtd4 too - you can see them by doing:
> 
>  hexdump -C e3-nand-backup.4 | grep -A 1 "Q;Q;"
> 
> Finally the nanddump files have 16 bytes of out of band (OOB) data per
> 512 byte block, so if you want something that might be writable back to
> the flash you need to strip those out. The attached Python should do the
> trick:
> 
>  nand-oob-strip e3-nand-backup.0 e3-nand.0
> 
> will dump out e3-nand.0 with the OOB data stripped.

J.

-- 
I'm dangerous when I know what I'm doing.

___
e3-hacking mailing list
e3-hacking@earth.li
https://www.earth.li/mailman/listinfo/e3-hacking

Re: [E3-hacking] Trying to Flashing the backup of the Original Firmware Again

2019-04-18 Thread Ralph Corderoy 
Hi Nick,

> looks like it has bad blocks too and they and made the files bigger in
> size than the partition..???

No, I don't think so.

> Image 3784704 bytes, NAND page 512 bytes, OOB area 512 bytes, device size 
> 3670016 bytes
...
> Image 270336 bytes, NAND page 512 bytes, OOB area 512 bytes, device size 
> 262144 bytes
...
> Image 270336 bytes, NAND page 512 bytes, OOB area 512 bytes, device size 
> 262144 bytes
...
> Image 29196288 bytes, NAND page 512 bytes, OOB area 512 bytes, device size 
> 28311552 bytes

3784704 - 3670016 = 114,688
114,688 / 1024 = 112
3670016 / 1024 / 32 = 112
3784704 / 3670016 = 1.03125

270336 - 262144 = 8,192
8,192 / 1024 = 8
262144 / 1024 / 32 = 8
270336 / 262144 = 1.03125

29196288 - 28311552 = 884,736
884,736 / 1024 = 864
28311552 / 1024 / 32 = 864
29196288 / 28311552 = 1.03125

1 / (1.03125 - 1) = 32

The image is always the same factor bigger than the device size, 1/32th,
suggesting a consistent overhead in the data format.

-- 
Cheers, Ralph.

___
e3-hacking mailing list
e3-hacking@earth.li
https://www.earth.li/mailman/listinfo/e3-hacking

Re: [E3-hacking] Config / content filesystem

2019-04-18 Thread Nick Griffin 
Where do I put attached Python script, in my Linux not in the E3..?

So I do each file with it..?

Spanner..

From: Jonathan McDowell
Sent: ‎Thursday‎, ‎18‎ ‎April‎ ‎2019 ‎11‎:‎58
To: Discussion of the Amstrad E3 emailer 
hardware/software

On Wed, Apr 17, 2019 at 01:26:40PM +, Nick Griffin wrote:

> Do you remember if you were able to mount the Cramfs and look at its
> filesystem..?  What's Q;Q; blocks in flash, another files system…?
> Can’t find any info on it, were you able to mount that too. So does it
> have 2 partitions on mtd4 then..?

You need to remember the E3 dates from a time when embedded Linux
systems were a lot simpler, and the E3 was designed to be a low cost
platform (even allowing for the subsidy). It doesn't have the sort of
NAND setup seen on modern systems; it simply didn't have the resources.

So, the MTD partitions do not directly map to a kernel or a Linux
filesystem. The "Q;Q;" blocks are an Amstrad specific way of putting
data into those partitions, with a type + description associated with
each one. For example the kernel lives in a Q;Q; block in mtd3 called
"LINUX". mtd3 also has Q;Q; blocks for LDR (the second stage boot
loader), and PARMS (the kernel boot parameters).

The CRAMFS filesystem is in mtd4; Q;Q; block name "LNXFSYS". There are 2
of them (I imagine to allow for an active + fallback). There are various
other bits of content in mtd4 too - you can see them by doing:

 hexdump -C e3-nand-backup.4 | grep -A 1 "Q;Q;"

Finally the nanddump files have 16 bytes of out of band (OOB) data per
512 byte block, so if you want something that might be writable back to
the flash you need to strip those out. The attached Python should do the
trick:

 nand-oob-strip e3-nand-backup.0 e3-nand.0

will dump out e3-nand.0 with the OOB data stripped.

J.

--
One-seventh of your life is|  .''`.  Debian GNU/Linux Developer
 spent on Monday.  | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.
___
e3-hacking mailing list
e3-hacking@earth.li
https://www.earth.li/mailman/listinfo/e3-hacking

Re: [E3-hacking] Config / content filesystem

2019-04-18 Thread Jonathan McDowell 
On Wed, Apr 17, 2019 at 01:26:40PM +, Nick Griffin wrote:

> Do you remember if you were able to mount the Cramfs and look at its
> filesystem..?  What's Q;Q; blocks in flash, another files system…?
> Can’t find any info on it, were you able to mount that too. So does it
> have 2 partitions on mtd4 then..?

You need to remember the E3 dates from a time when embedded Linux
systems were a lot simpler, and the E3 was designed to be a low cost
platform (even allowing for the subsidy). It doesn't have the sort of
NAND setup seen on modern systems; it simply didn't have the resources.

So, the MTD partitions do not directly map to a kernel or a Linux
filesystem. The "Q;Q;" blocks are an Amstrad specific way of putting
data into those partitions, with a type + description associated with
each one. For example the kernel lives in a Q;Q; block in mtd3 called
"LINUX". mtd3 also has Q;Q; blocks for LDR (the second stage boot
loader), and PARMS (the kernel boot parameters).

The CRAMFS filesystem is in mtd4; Q;Q; block name "LNXFSYS". There are 2
of them (I imagine to allow for an active + fallback). There are various
other bits of content in mtd4 too - you can see them by doing:

 hexdump -C e3-nand-backup.4 | grep -A 1 "Q;Q;"

Finally the nanddump files have 16 bytes of out of band (OOB) data per
512 byte block, so if you want something that might be writable back to
the flash you need to strip those out. The attached Python should do the
trick:

 nand-oob-strip e3-nand-backup.0 e3-nand.0

will dump out e3-nand.0 with the OOB data stripped.

J.

-- 
One-seventh of your life is|  .''`.  Debian GNU/Linux Developer
 spent on Monday.  | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.
#!/usr/bin/python3

import sys

if len(sys.argv) < 3:
print("Must provide filename to dump + file to write.")
sys.exit(-1)

with open(sys.argv[1], mode="rb") as infile:
with open(sys.argv[2], mode="wb") as outfile:
data = infile.read()
ofs = 0
while ofs < len(data):
outfile.write(data[ofs:ofs + 512])
ofs += (512 + 16)
___
e3-hacking mailing list
e3-hacking@earth.li
https://www.earth.li/mailman/listinfo/e3-hacking