Flash layout

Hi,

i've just added MTD support for the DPCM to the kernel. It seems to me that 
the flash layout as described by 
http://www.embeddedlinuxinterfacing.com/ewiki/index.php?id=FlashProgrammingNotes 
is wrong! In particular the "0x0040C000: Begin OS writable flash segment 
(16k)" is not correct. The correct layout is (with an offset of 0x400000 of 
course!):

<5>0x00000000-0x00010000 : "bootloader"
<5>0x00010000-0x000b0000 : "kernel"
<5>0x000b0000-0x00200000 : "filesystem"
<5>0x00004000-0x00008000 : "config"
<5>0x00000000-0x00200000 : "complete flash"

Actually the second number of each line needs to be decremented by one, but 
this is what the kernel MTD driver says.

One interesting thing is that the partition for the config data is completely 
within the bootloader partition. I wonder why it's done this way.

I also wonder why Actiontec only used 2048 bytes for the config (which is 
accessible via /dev/mtdc0). There are actually 16384 bytes reserved for 
configuration data (0x4000-0x8000), but the original firmware only uses 
0x5000-0x5800. I've verified this by doing a "cat /dev/zero >/dev/mtdblock3". 
No problem, the device reboots fine and after the reboot the data is still 
there, so it doesn't break anything.

The strange thing is that the flash driver seems to devide the 16k config 
space into 8 2k chunk and protect each chunk with a 44 byte CRC (44 byte is 
odd, it's neither md5 nor sha1). I noticed this because after overwriting the 
16k config partition, I got the following messages at the next boot:
---
<4>Conexant Flash Driver version: 001
<4>Initializing Flash Segment 1
<4>Initializing Flash data Segment 1,  40402C
<4>CnxtFlashProg src=9683ac, dst=404000, size=44
<4>Initializing Flash Segment 2
<4>Initializing Flash data Segment 2,  40482C
<4>CnxtFlashProg src=9683d8, dst=404800, size=44
<4>Initializing Flash Segment 3
<4>Initializing Flash data Segment 3,  40502C
<4>CnxtFlashProg src=968404, dst=405000, size=44
<4>Initializing Flash Segment 4
<4>Initializing Flash data Segment 4,  40582C
<4>CnxtFlashProg src=968430, dst=405800, size=44
<4>Initializing Flash Segment 5
<4>Initializing Flash data Segment 5,  40602C
<4>CnxtFlashProg src=96845c, dst=406000, size=44
<4>Initializing Flash Segment 6
<4>Initializing Flash data Segment 6,  40682C
<4>CnxtFlashProg src=968488, dst=406800, size=44
<4>Initializing Flash Segment 7
<4>Initializing Flash data Segment 7,  40702C
<4>CnxtFlashProg src=9684b4, dst=407000, size=44
<4>Initializing Flash Segment 8
<4>Initializing Flash data Segment 8,  40782C
<4>CnxtFlashProg src=9684e0, dst=407800, size=44
---
After that there were indeed some numbers at 0x00404000, 0x00404800, 
0x00405000, 0x00405800, etc.

Although this behaviour is strange, I won't examine it further. There is no 
reason to use the conexant flash driver anymore because the default mtd 
driver works fine. After adding a mtd map for the DPCM the kernel booted 
without any problem:
---
<4>Linux version 2.4.29-uc0-cvs20050330 (jonny@dh3mb) (gcc version 2.95.4 
20010319 (prerelease)) #1 Sun Apr 17 17:59:06 CEST 2005
<4>Processor: ARM/CNXT Arm940sid(wb) revision 2
<4>Architecture: CNXT CX821XX
<4>On node 0 totalpages: 1920
<4>zone(0): 0 pages.
<4>zone(1): 1920 pages.
<4>zone(2): 0 pages.
<4>Kernel command line: root=/dev/mtdblock2 init=/linuxrc
[...]
<5>Actiontec DPCM flash driver (size->0x200000 mem->0x400000)
<6>Search for id:(89 8891) interleave(1) type(2)
<4>Found: Intel 28F160B3B
<6>Actiontec DPCM flash memory: Found 1 x16 devices at 0x0 in 16-bit mode
<7>0: offset=0x0,size=0x2000,blocks=8
<7>1: offset=0x10000,size=0x10000,blocks=31
<4>Using word write method
<5>Creating 5 MTD partitions on "Actiontec DPCM flash memory":
<5>0x00000000-0x00010000 : "bootloader"
<5>0x00010000-0x000b0000 : "kernel"
<5>0x000b0000-0x00200000 : "filesystem"
<5>0x00004000-0x00008000 : "config"
<5>0x00000000-0x00200000 : "complete flash"
[...]
---

We now have 16384 bytes for storing configuration data. I plan to simply put a 
gzip-compressed tarball into it for saving the config. This is as easy as 
executing "tar cf - /var/etc | gzip >/dev/mtdblock3".

BTW, having reasonable space for storing the configuration was one of the last 
problems I had for a GPL firmware. I'll now look for a proper way for 
controlling the modem LED and monitoring the reset button. As soon as I've 
solved this, I'll release the first GPL firmware. However, I'll probably not 
implement a web interface, because I don't need it for myself. There will be 
simple text files for configuring the interfaces, routes, etc. which you will 
be able to save by executing "save_config".

Cheers, Johann
__
actionhack Mailing List - actionhack-W7/[email protected]
http://www.express.org/mailman/listinfo/actionhack
http://www.embeddedlinuxinterfacing.com/wiki.php/ActiontecDualModem