ARM bootloaders (Zaurus) and CMDLINE

ARM bootloaders (Zaurus) and CMDLINE

[Andrea Adami]

I'm trying to understand in details the boot-process and the changes
between 2.4 and 2.6 kernels.

The idea is to read the mtdparts passed by the Zaurus bootloader
(angel) with a 2.6 kernel.

I found two threads which shed some light:

http://lists.gnu.org/archive/html/qemu-devel/2007-07/msg00344.html
https://kerneltrap.org/mailarchive/linux-kernel/2007/10/25/355025/thread

The question is simple: is it possible to apply the
CONFIG_SHARPSL_BOOTLDR_PARAMS patch to the 2.6 kernels?

We'd need this in the kexecboot-kernel, to be able to recognize the
mtdparts passed in /proc/cmdline. This is actually working only with
u-boot.

Other solution would be a raw read of the nand addresses and a
subsequent edit of the CMDLINE params passed by the kexecboot kernel
to the launched kernel.

Any advice?

TIA

Andrea

Re: ARM bootloaders (Zaurus) and CMDLINE

[Andrea Adami]

An old bootlog illustrating our purposes is there:
http://de.pastebin.ca/1309948

As you see, u-boot passes the customized mtdparts via cmdline (not
sure about ATAGs) and the 2.6.26-kexecboot-kernel finds these and does
NOT default to the standard partitioning hardcoded in the sources.

The code in the initramfs parses then /proc/cmdline and passes the
right arguments to the kexecbooted kernel.

We want to achieve this without u-boot...

TIA

Andrea

Re: ARM bootloaders (Zaurus) and CMDLINE

[Stanislav Brabec]

Andrea Adami wrote:

> Other solution would be a raw read of the nand addresses and a
> subsequent edit of the CMDLINE params passed by the kexecboot kernel
> to the launched kernel.

This is not as raw as it sounds. It is stored in the configuration area
of the NAND. There is a command nandlogical (package survive), which is
able to read these values. Some time ago I tried to decode these areas.
It would solve not only this problem, but also differentiating between
SL-C3100 and SL-C3200, which have different NAND partitioning, but no
other significant differences, and finally create flashing utility,
which would create correct checksums (now NAND diag checks fail).

Flexible part of the command line is stored in Model array, offset
0x1000 (starting by "EQUIPMENT"). Fixed part is probably generated by
the bootloader, using partition info in PartitionInfo* records.


console=ttyS0 root=/dev/mtdblock2 mtdparts=sharpsl-nand:7168k@0k(smf),44032k@7168k(root),-(home) jffs2_orphaned_inodes=delete EQUIPMENT=5 LOGOLANG=1 DEFYEAR=2007 LOGO=1 LAUNCH=q


#!/bin/sh

nandcfg()
{
    ./nandlogical /dev/mtd0 READ $1 0x4000 nanddecode.$2
}

nandcfg 0x00040000 AdjValue
nandcfg 0x00044000 BootFlag
nandcfg 0x00048000 Version
nandcfg 0x0004c000 Clock
nandcfg 0x00050000 ROMount
nandcfg 0x00054000 RWMount
nandcfg 0x00058000 RSV_58
nandcfg 0x0005c000 RSV_5C
nandcfg 0x00060000 PartitionInfo1
nandcfg 0x00064000 PartitionInfo2
nandcfg 0x00068000 Model
nandcfg 0x0006c000 RSV_6C
nandcfg 0x00070000 MVersion
nandcfg 0x00074000 RSV_74
nandcfg 0x00078000 RSV_78


--- nandlogical.c	2006-06-09 17:06:48.000000000 +0200
+++ nandlogical.c	2008-04-30 00:26:26.000000000 +0200
@@ -135,7 +135,7 @@
 	oob.start = offset;
 	ret = ioctl(fd, MEMREADOOB, &oob);
 
-	//ret = nand_read_raw(nand, oobuf, offset, nand->oobblock, nand->oobsize);
+	//ret = nand_read_raw(nand, oobuf, offset, nand->writesize, nand->oobsize);
 	if (!ret) {
     	    int log_no = nand_get_logical_no(oobbuf);
 	    if (((int)log_no >= 0) && (log_no < blocks)) {
@@ -276,20 +276,20 @@
 	}
 
 	/* Make sure device page sizes are valid */
-	if (!(meminfo.oobsize == 64 && meminfo.oobblock == 2048) &&
-	    !(meminfo.oobsize == 16 && meminfo.oobblock == 512) &&
-	    !(meminfo.oobsize == 8 && meminfo.oobblock == 256)) {
+	if (!(meminfo.oobsize == 64 && meminfo.writesize == 2048) &&
+	    !(meminfo.oobsize == 16 && meminfo.writesize == 512) &&
+	    !(meminfo.oobsize == 8 && meminfo.writesize == 256)) {
 	    fprintf(stderr, "Unknown flash (not normal NAND)\n");
 	    close(fd);
 	    exit(1);
 	}
 
-	//printf("erasesize %x\noobblock %x\noobsize %x\nsize %x\n", meminfo.erasesize, meminfo.oobblock, meminfo.oobsize, meminfo.size);
+	//printf("erasesize %x\nwritesize %x\noobsize %x\nsize %x\n", meminfo.erasesize, meminfo.writesize, meminfo.oobsize, meminfo.size);
 	
 	blocks = NAND_LOGICAL_SIZE / meminfo.erasesize;
 	log2phy = (unsigned long *) malloc(blocks * sizeof(unsigned long));
 	readbuf = (char *)malloc(meminfo.erasesize);
-	oobbuf = (char *)malloc(meminfo.oobblock);	
+	oobbuf = (char *)malloc(meminfo.writesize);	
 	oob.ptr = oobbuf;
 
 	scan_logical(blocks, meminfo.erasesize);
@@ -297,7 +297,7 @@
 	//printf("Start: %x\nEnd: %x\n", start_addr, length);
 	
 	end_addr = start_addr + length;
-	bs = meminfo.oobblock;
+	bs = meminfo.writesize;
 
 	for (ofs = start_addr; ofs < end_addr ; ofs+=bs) {
 	    int new_logical_added = 0;


Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: ARM bootloaders (Zaurus) and CMDLINE

[Andrea Adami]

> other significant differences, and finally create flashing utility,
> which would create correct checksums (now NAND diag checks fail).
I insisted for nandlogical committed in OE when I read your post in OESF ;-)

For reference I'll post the disassembled bootloader as found in this post:

http://www.oesf.org/forum/index.php?showtopic=3361&hl=only+root

This was back in 2004...preparatory work for the extended updater
capable to resize nand (sources in survive / fsro_resize.c).

So, writing a new partition schema is possible...the problem is read
it with 2.6.2x kernels!

Regards

Andrea

Re: ARM bootloaders (Zaurus) and CMDLINE

[Stanislav Brabec]

Andrea Adami wrote:

> For reference I'll post the disassembled bootloader as found in this post:
> 
> http://www.oesf.org/forum/index.php?showtopic=3361&hl=only+root
> 
> This was back in 2004...preparatory work for the extended updater
> capable to resize nand (sources in survive / fsro_resize.c).

Thanks for the reference.

> So, writing a new partition schema is possible...the problem is read
> it with 2.6.2x kernels!

My previous mail contains a patch porting nandlogical to kernel 2.6
userspace. Porting to kernel space may require some work.

Kernel 2.4 used a trick - user space utility called writerominfo read
some of these values and sent them to kernel.


Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: ARM bootloaders (Zaurus) and CMDLINE

[Yuri Bushmelev]

> Kernel 2.4 used a trick - user space utility called writerominfo read
> some of these values and sent them to kernel.

Stanislav, can you please explain this a bit more?

-- 
Yuri Bushmelev

Re: ARM bootloaders (Zaurus) and CMDLINE

[Stanislav Brabec]

Fri, 16 Jan 2009 20:08:03 +0300 Yuri Bushmelev wrote:

> > Kernel 2.4 used a trick - user space utility called writerominfo
> > read some of these values and sent them to kernel.
> 
> Stanislav, can you please explain this a bit more?
> 
If you look at Sharp system, you will find /sbin/writerominfo. I didn't
find source code for it, but I guess that it reads NAND config data and
initializes /proc/deviceinfo entries (and it performs some magic
with /.sys).

This utility is called early in the boot process. updater.sh
flashing utility uses it as well.

Other utilities used by update.sh:
nandlogical: source available
verchg: probably changes NAND section version info in NAND
nandcp: probably copies data to NAND
bcut: probably trivial file cutter
eraseall: probably MTD partition eraser

Note: current OE update.sh does not flash correct checksum after
flashing the kernel

Here is a rough and incomplete attempt to map PROM and NAND based on a
SL-6000 map somewhere on OESF (attached as PNG), my experimenting
with SL-C3200 and trying to understand, what one can see in the NAND
diagnostic.

One importand note: Linux kernel does not yet support all settings done
by the bootloader. For example LCD phase settings is done by bootloader
and not touched by Linux. Possible alternative bootloader may need to
set it as well.


PROM and NAND memory map on Sharp Zaurus SL-C3200

(it is known to be different from all other models including SL-C3100)

PROM

8 MiB PROM Read only memory for production models, NOR flash for
pre-production models.

 PROM BOOTLOADER "ROM"
 address 0x00000000, size 0x00140000
 contents: Bootloader.

 PROM MTD0 "Filesystem" "ROM DATA"
 address 0x00140000, size 0x006b0000
 contents: EN-JP dictionary database.

NAND
128MiB NAND flash, erase size 0x00020000

 NAND MTD1 "smf" "BOOT"
 address 0x00000000, size 0x00700000

  address 0x00000000, size 0x00040000 MAINTE

0x48000 0x4000 VERBLOCK
0x70000 0x4000 MVRBLOCK

  address 0x00040000, size 0x00040000 NAND bootloader

Values from SL-6000:
0x00040000 AdjValue
0020020     ffff    ffff    ffff    ffff    ffff    ffff    5554    4843
0020040     80ec    3d87    70dc    3dbc    ffee    ffff    fff0    ffff
0020060     ffff    ffff    ffff    ffff    4850    4441    0000    0000
0x00044000 BootFlag ff
0x00048000 Version *
names of MTD sections
positions of sections
checksums
0x0004c000 Clock 0000000     0425    1971    82b1    4660
0x00050000 ROMount ff
0x00054000 RWMount ff
0x00058000 RSV_58
0x0005c000 RSV_5C
0x00060000 PartitionInfo1 *
0x00064000 PartitionInfo2 *
0x00068000 Model *
0x0006c000 RSV_6C
0x00070000 MVersion *
 master version
 checksums of mtd sections
0x00074000 RSV_74
0x00078000 RSV_78
* verified
0x000e0000 DATA   standard kernel

Values from param_version:
0x00000000 Mainte "MAINTE" "MAINTE.BIN"
1. 00000000-00040000
0x00040000 Parameter Area
0x0007c000 NAND Diag "DIAG" "NANDDIAG.BIN"
2. 00080000-000e0000
0x000e0000 Zimage 2 "KERNEL2" "ZIMAGE.BIN+INITRD.BIN"
3. 00220000-0035c000
4. 00360000-00680000
0x00220000 Zimage 1 "KERNEL1" "ZIMAGE.BIN+INITRD.GZ"
5. 000e0000-0021c000
6. 07000000-03100000 (i. e. FSRO)
0x00360000 Initrd 2 "FLSYS2" "INITFS.BIN"
7. 03200000-08000000 (i. e. FSRW)
0x00700000 "ROFLSYS?" "PARAMINF.BI"
8. 00060000-0006c000
NAND MTD2 RO JFFS2 file system "root" "FSRO"
address 0x00700000, size 0x02b00000

NAND MTD3 RW JFFS2 file system "home" "FSRW"
address 0x03200000, size 0x04e00000

--
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: ARM bootloaders (Zaurus) and CMDLINE

[Andrea Adami]

> If you look at Sharp system, you will find /sbin/writerominfo. I didn't
> I didn't find source code for it, but I guess that it reads NAND config data and

writerominfo.c and other sources:
http://ftp.surfnet.nl/pub/os/Linux/distr/pdaxrom/src/survive-1.1.0.tar.bz2

It seems it fixes /proc/deviceinfo/product

### Check model ###
/sbin/writerominfo
MODEL=`cat /proc/deviceinfo/product`

Regards

Andrea

Re: ARM bootloaders (Zaurus) and CMDLINE

[Andrea Adami]

> Note: current OE update.sh does not flash correct checksum after
>flashing the kernel

We are going OT but I add here another couple of links...this thread
is summing up all Zaurus 'peculiarities':

http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm
-> Wal Wiki
- -> http://digit.que.ne.jp/visit/index.cgi?59414d41 (checksums?)

Regards

Andrea