Getting at the flash of the n30
mtd-utils
After getting the NAND flash driver running, I downloaded the cvs tree from http://www.linux-mtd.infradead.org/ and compiled nanddump for the arm. Since the first 11 blocks of the flash have invalid erase marks I had to patch nanddump to ignore the erase marks, otherwise i just got ff for those blocks. With the patched version I could dump and upload the flash contents to my laptop.
jtag
Before I even think of writing Linux into flash on the n30 I want a way of writing back WinCE if I mess up real bad. jtag is one of the ways to get to memory on the unit even when the firmware is totally hosed.
First I tried jtag-arm9. It detects the s3c2410 and can halt it, but reading the registers or trying anything else seems to just return garbage.
After that I tried OpenWinCE jtag. It couldn't read out the idcode so I hardcoded the s3c2410 ID and added a BSDL file for the s3c2410. With this program I managed to control the LED pin on the processor. So this program is probably a possible way to go.
The Samsung jtag programmer to my surprise came with sources in the zip filer, so I ported it to Linux and hacked the flash driver to understand the flash chips on the n30. The source code is ugly, but it works quite well. I read out the first 8 megs of flash (which took about 6 hours) and compared it with the image dumped with nanddump and it matches. So it seems that the jtag programmer is stable too.
Addresses
Address Contents Info
0x0-0x3fff Bootstrap Code A minimal bootloader that just does minimal setup and copies one of the images from the TOC into RAM and executes it.
0x4000-0x4fff TOC Table of contents.
0x8000-0x27fff eboot.nb0 SMDK2410 Bootloader. This is a bootloader that can download an image via USB or from the SD-MMC card and reprogram the flash.
The MAC address and Security ode presented by the booloader can be found at 0x24000 in this image.
0x28000-0x2bfff Partition Table 1
0x2c000-0x2ffff Partition Table 2
0x1ccc000-0x1e04000 WinCE kernel
0x1e0c000-0x1e10000 WinCE module chain? Pointed out by chainInfo.dwFlashAddress in the TOC?. It seems to be a bunch of WinCE module descriptors with associated RSA1 signatures. They are named XIPKERNEL, KERNEL, OS, SHELL, BROWSING, COREAPPS, EXAPPS, and MISC. This may be the sections (bad link, I must have messed up) described by Microsoft.
The Linux kernel complains about "Bad eraseblock" for sector 0-10. It seems that the bootloader just assumes that block 0-10 will be ok and never develop any faults.
TOC
This part of flash contains a table of contents that seems to contain some configuration and two entries, one entry for "eboot.nb0" and another entry for the WinCE kernel.
00004000 4e 54 4f 43 01 00 00 00 - 20 38 00 00 0f 00 00 00 NTOC.... 8......
00004010 00 00 00 00 00 00 00 00 - 00 00 00 00 ff ff ff ff ................
00004020 05 00 02 00 54 4f 42 45 - 65 62 6f 6f 74 2e 6e 62 ....TOBEeboot.nb
00004030 30 00 00 00 00 00 00 00 - 02 00 00 00 00 01 00 00 0...............
00004040 00 80 03 8c 00 80 03 8c - 40 00 00 00 00 01 00 00 ........@.......
00004050 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
...
000040b0 00 00 00 00 00 00 00 00 - 00 00 00 00 01 00 00 00 ................
000040c0 49 53 46 43 00 00 00 00 - 00 00 00 00 00 00 00 00 ISFC............
000040d0 00 00 00 00 0e 00 00 00 - c0 09 00 00 00 00 20 8c .............. .
000040e0 00 10 20 8c 60 e6 00 00 - c0 09 00 00 00 00 00 00 .. .`...........
000040f0 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
...
00004150 00 00 00 00 00 00 c7 01 - 00 00 00 00 00 00 00 00 ................
00004160 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
...
000041f0 00 00 00 00 00 00 3c 8c - 60 f0 00 00 20 00 00 00 ......<.`... ...
00004200 ff ff ff ff ff ff ff ff - ff ff ff ff ff ff ff ff ................
...
00008000
And here's the output from the bootloader.
TOC_Read
sizeof TOC : 0x200
TOC {
dwSignature: 0x434F544E
BootCfg {
ConfigFlags: 0x3820
BootDelay: 0xF
ImageIndex: 1
IP: 0.0.0.0
MAC Address: 00:00:00:00:00:00
Port: 0.0.0.0
SubnetMask: 255.255.255.255
}
ID[0] {
dwVersion: 0x20005
dwSignature: 0x45424F54
String: 'eboot.nb0'
dwImageType: 0x2
dwTtlSectors: 0x100
dwLoadAddress: 0x8C038000
dwJumpAddress: 0x8C038000
dwStoreOffset: 0x0
sgList[0].dwSector: 0x40
sgList[0].dwLength: 0x100
}
ID[1] {
dwVersion: 0x1
dwSignature: 0x43465349
String: ''
dwImageType: 0xE
dwTtlSectors: 0x9C0
dwLoadAddress: 0x8C200000
dwJumpAddress: 0x8C201000
dwStoreOffset: 0x1C70000
sgList[0].dwSector: 0xE660
sgList[0].dwLength: 0x9C0
}
chainInfo.dwLoadAddress: 0X8C3C0000
chainInfo.dwFlashAddress: 0X0000F060
chainInfo.dwLength: 0X00000020
}
-TOC_Read
The Partition Tables
There is a partition table at 0x28000 (where Linux complains about a bad eraseblock:
00028000 e9 fd ff ff ff ff ff ff - ff ff ff ff ff ff ff ff ................
00028010 ff ff ff ff ff ff ff ff - ff ff ff ff ff ff ff ff ................
...
000281b0 ff ff ff ff ff ff ff ff - ff ff ff ff ff ff 03 0c ................
000281c0 01 00 21 98 20 00 80 01 - 00 00 a0 f1 00 00 01 99 ..!. ...........
000281d0 01 00 0b ee 20 00 20 f3 - 00 00 c0 0a 00 00 00 00 .... . .........
000281e0 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
000281f0 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 55 aa ..............U.
00028200 ff ff ff ff ff ff ff ff - ff ff ff ff ff ff ff ff ................
...
0002c000
The first two bytes and the last two seem to be some kind of magic. Just before the last two bytes there is a partition table with four PARTENTRY structures. So the decoded table is:
BootInd FirstHead FirstSector FirstTrack FileSystem LastHead LastSector LastTrack StartSector TotalSectors Offset in bytes Size in bytes Offset + Size
03 0c 01 00 21 98 20 00 00000180 0000f1a0 0x30000 0x1e34000 0x1e64000
01 99 01 00 0b ee 20 00 0000f320 00000ac0 0x1e64000 0x158000 0x1fbc000
Partition type 0x0b is W95 FAT32 according to Linux fdisk. What is 0x21, BinFS?
What is strange is that the FAT file system seems to start at 0x30000:
00030000 eb fe 90 4d 53 57 49 4e - 34 2e 31 00 02 01 01 00 ...MSWIN4.1.....
00030010 01 00 02 e0 0e f8 0c 00 - 01 00 01 00 00 00 00 00 ................
00030020 00 00 00 00 80 00 29 07 - 00 41 08 20 20 20 20 20 ......)..A.
00030030 20 20 20 20 20 20 46 41 - 54 31 32 20 20 20 00 00 FAT12 ..
00030040 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
A file that is written to /ROM Storage ended up at address 0x360000 in flash, so it seems that the partition table isn't as simple as I would like it to be.
It may be that the offsets are after the sectors have been translated using NTFL or something similar.
There is another partition table at 0x2c000:
0002c000 e9 fd ff ff ff ff ff ff - ff ff ff ff ff ff ff ff ................
0002c010 ff ff ff ff ff ff ff ff - ff ff ff ff ff ff ff ff ................
...
0002c1b0 ff ff ff ff ff ff ff ff - ff ff ff ff ff ff 03 0c ................
0002c1c0 01 00 21 78 20 00 80 01 - 00 00 a0 ed 00 00 01 79 ..!x ..........y
0002c1d0 01 00 0b ef 20 00 20 ef - 00 00 e0 0e 00 00 00 00 .... . .........
0002c1e0 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0002c1f0 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 55 aa ..............U.
0002c200 ff ff ff ff ff ff ff ff - ff ff ff ff ff ff ff ff ................
...
00030000
The decoded table is:
BootInd FirstHead FirstSector FirstTrack FileSystem LastHead LastSector LastTrack StartSector TotalSectors Offset in bytes Size in bytes Offset + Size
03 0c 01 00 21 78 20 00 00000180 0000eda0 0x30000 0x1db4000 0x1de4000
01 79 01 00 0b ef 20 00 0000ef20 00000ee0 0x1de4000 0x1dc000 0x1fc0000
Number magic: 0x2c000 + 0x1de4000 = 0x1e10000 which is the end of the second entry in the TOC.
ps：Platform Builder for Microsoft Windows CE 5.0
Boot without a Boot Loader
In some cases, the boot loader does not download the image, but the run-time image is already present on the system. The image might be located at the location where the CPU starts executing. In case the image is not located at the address where the CPU starts executing, use RESETVECTOR to specify the jump address.
Boot using RESETVECTOR
If the image is not at the address where the CPU starts executing, use RESETVECTOR in Config.bib to specify where to jump to and start looking for the StartUp function. RESETVECTOR tells Romimage.exe where the reset vector for the CPU is located. At the jump location, add a jump instruction to the start of the image. Romimage.exe is a locator application that creates Windows CE binary image (.bin) files.
The image can overwrite code that instructs the CPU to jump to the start of the image. To prevent this from happening, reserve a page of memory using the RESERVE keyword. For example, if the microprocessor starts executing after reset at 0x9FC00000, but the image is loaded starting at 0x9F80000, instruct ROMIMAGE that the reset vector is 9fC00000. The following code example shows how to reserve one page of this portion of memory using the RESERVE keyword in Config.bib so the jump instruction to the start of the image is not overwritten.
RESETVECTOR=9F800000
The following code example shows how to reserve 4 KB at reset vector for boot loader and diagnostics:
RESERVE 9fc00000 00001000
Boot without using RESETVECTOR
If you are not using the boot loader and RESETVECTOR is not defined, the jump page is at the start of the image. The image is located at the address where the CPU starts executing.
See Also
Boot with a Boot Loader | Modes for Booting the OS
转自：http://zoo.weinigel.se/n30/flash.html
從 APP 打開
X