Re: Siemens SX551

AFAIK it's not possible to do anything directly through the serial port. The bootloader boots straight away in the OS, without a way to intercept. And the OS doesn't seem to have a serial interface either.

CS? Computer Sciences? Do you have the possibility to decode mips machine code? As you can read in this thread the bootloader doesn't accept just any image, it checks for some(?) features, but I don't know which. I was able to get the kernel booting (partly) by gluing the first 4k of a firmware image in front of it, and exchanging the first 4 bytes by a jump.
But when I tried to do the same with a kernel with lzma extractor, it was rejected. I have a bootloader dump (read using JTAG), but I can't decode it.

Re: Siemens SX551

CS is indeed computer science. I do not know much of assembly, let alone machine code of MIPS.
Perhaps other products using the same CPU can tell us more about it?
Googling for "ar7300 boot" yielded these results:
http://www.zoobab.com/philips-sna6600

German links below:
http://www.webnmail.de/sx553wlandsl/
http://ar7-firmware.berlios.de/wiki/Hauptseite (it mentions a different siemens model, maybe there are similarities?)

I'm Dutch, but am taught a little German. I wonder where you are from?

Re: Siemens SX551

Hello all. I read all posts in this thread and my question is: will be there a OpenWrt firmware for se555? And I can just flash it? I see you make progress keep up the good work.

Re: Siemens SX551

@Lekensteyn: Yes, I've seen that sites, and especially ar7-firmware.berlios.de is very useful. It has given me the firmware packer I'm using. All the routers on that site are using the same bootloader as the SX551, but Siemens has changed it a little. AFAIK the SX551 is the only box using a Broad Net bootloader with LZMA decompression. Of course that is no problem, but apparently they also added some sanity checks to the decompressed code. According to http://ar7-firmware.berlios.de/doc/loader.html.en the bootloader should extract the firmware to 0x94000000 and just start it from there. But my finding are that the code needs a special header. I have sifted the OpenWRT patches which were used to boot the SX541, but it doesn't seem to do anything with the header.

@sipe: Don't know. The SE555 uses encrypted firmware, I think, and I don't know if it's bootloader will accept a plain zipped kernel.

Re: Siemens SX551

The PFS filesystem (?) was easy to reverse engineer. I've put some files on http://lekensteyn.nl/files/pfs/. You likely want to download the Makefile, pfs.c, pfs.h, pfstool.c and run make to generate the pfstool binary.

Now, there is a second part after the PFS in the lzma archive, any idea how to use it?

Re: Siemens SX551

At the next 4k boundary a 2nd lzma compressed block is available. (The remaining space in the PFS block is filled with FF, with a CRC and some stuff in the end.

The second lzma contains 'the binary'. This is decompressed to 0x94000000 and started. Here can you see the disassembly of the first few bytes.

Unfortunately I don't know how it is started. I thought the bootloader would simply jump to 0x94000000, but I'm starting to doubt.
I got a Linux kernel running partly, by taking the first 4k of the firmware binary, and gluing the kernel behind. Then I exchanged the first 4 bytes by a 'jump to kernel entry'.
The worked partly, but using the same trick to load a zImage (a lzma compressed kernel with a decompressing piggyback) is just ignored. (The lzma is decompressed to 0x94000000, and then the bootloader menu appears without error messages.)
Maybe the bootloader jumps to another address, and did my Linux kernel run by accident. And maybe does the bootloader menu popup by some invalid opcode trap.

I have been thinking about creating a binary like this:

load 1 to some register
jump to report
load 2 to some register
jump to report
load 3 to some register
jump to report
...
report:
print register value

By creating 2 of this binaries it should be possible to find out the entry point (one with the jumps at the even blocks, and one at the odd's. Unfortunately I don't know how to do the print.

Re: Siemens SX551

The information on the second part is very useful, I've now made findlzma (and xbin) for extracting the tools. Usage:

$ make findlzma
$ ./xbin file.bin part
part00000000.lzma
254976+0 records in
254976+0 records out
254976 bytes (255 kB) copied, 0.165663 s, 1.5 MB/s
part0003E400.lzma
1229834+0 records in
1229834+0 records out
1229834 bytes (1.2 MB) copied, 0.770311 s, 1.6 MB/s
$ unlzma part00000000.lzma
$ unlzma part0003E400.lzma
$ ./parttool xv -C webroot part00000000.lzma

Note: slow speed is due to block size of 1 byte.

Now I've to look at the binary.

Re: Siemens SX551

<offtopic>

I've now made findlzma

Have a look at binwalk.
</offtopic>

Re: Siemens SX551

Yea, I've seen that and tried it as well, but was not satisfied of it. I'm trying to disassemble the second lzma-compressed binary, but I'm not sure if I'm doing it well.
Following the tutorial, I managed to create a dump, but I don't know if it the instructions makes sense. Is the kernel that they retrieve from flash the same as the firmware image?

The SX551 firmware was retrieved from http://files.uberfail.nl/sx551-experia-upgrade.bin

Re: Siemens SX551

Partially disassembled

94000000:       40026000        mfc0    v0,c0_sr        ; move from ControlReg0 into v0
94000004:       3c010040        lui     at,0x40         ; AssemblerTemporary  0x40 0000
94000008:       00411024        and     v0,v0,at        ; v0 := v0 & at
9400000c:       40826000        mtc0    v0,c0_sr        ; move v0 to c0_sr
94000010:       3c049446        lui     a0,0x9446       ; a0 := 0x9446 0000
94000014:       2484ddf0        addiu   a0,a0,-8720     ; a0 := 0x9445 ddf0
94000018:       3c0595ad        lui     a1,0x95ad       ; a1 := 0x95ad 0000
9400001c:       24a54168        addiu   a1,a1,16744     ; a1 := 0x95ad 4168
94000020:       00a42823        subu    a1,a1,a0        : a1 := 0x0167 6378

94000024:       ac800000        sw      zero,0(a0)      ; *a0 := 0              ; 0x9445 ddf0
94000028:       ac800004        sw      zero,4(a0)      ; *(a0 + 4) := 0        ; 0x9445 ddf4
9400002c:       24a5fff0        addiu   a1,a1,-16       ; decrement a1 by 0x10
94000030:       ac800008        sw      zero,8(a0)      ; *(a0 + 8) := 0        ; 0x9445 dde8
94000034:       ac80000c        sw      zero,12(a0)     ; *(a0 + 0xc) := 0      ; 0x9445 ddec
94000038:       1ca0fffa        bgtz    a1,0x94000024   ; branch on greater than zero (true)
                                                        ; on termination: [0x8..0x1676378] = 0 and a0 = 0

9400003c:       24840010        addiu   a0,a0,16        ; a0 := 0x10
94000040:       3c1c9446        lui     gp,0x9446       ; gp := 0x9446 0000
94000044:       279c0060        addiu   gp,gp,96        ; gp := 0x9446 0096
94000048:       3c0895ad        lui     t0,0x95ad       ; t0 := 0x95ad 0000
9400004c:       25084168        addiu   t0,t0,16744     ; t0 := 0x95ad 4168
94000050:       3c090002        lui     t1,0x2          ; t1 := 0x0002 0000
94000054:       0109e820        add     sp,t0,t1        ; sp := 0x95af 4168
94000058:       2408fff0        li      t0,-16          ; t0 := 0xffff fff0
9400005c:       03a8e824        and     sp,sp,t0        ; sp := 0x95af 4160
94000060:       27a80010        addiu   t0,sp,16        ; t0 := 0x95af 4170
94000064:       3c099446        lui     t1,0x9446       ; t1 := 0x9446 0000
94000068:       2529e03c        addiu   t1,t1,-8132     ; t1 := 0x0944 403c
9400006c:       ad280000        sw      t0,0(t1)        ; *t1 := 0x95af 4170
94000070:       0d0017e8        jal     0x94005fa0      ; jump and link
94000074:       00000000        nop
94000078:       1000ffff        b       0x94000078      ; burn cpu

36 (edited by Mijzelf 2012-03-28 10:18:26)

Re: Siemens SX551

I disagree on this:

94000024:       ac800000        sw      zero,0(a0)      ; *a0 := 0              ; 0x9445 ddf0
94000028:       ac800004        sw      zero,4(a0)      ; *(a0 + 4) := 0        ; 0x9445 ddf4
9400002c:       24a5fff0        addiu   a1,a1,-16       ; decrement a1 by 0x10
94000030:       ac800008        sw      zero,8(a0)      ; *(a0 + 8) := 0        ; 0x9445 dde8
94000034:       ac80000c        sw      zero,12(a0)     ; *(a0 + 0xc) := 0      ; 0x9445 ddec
94000038:       1ca0fffa        bgtz    a1,0x94000024   ; branch on greater than zero (true)
                                                        ; on termination: [0x8..0x1676378] = 0 and a0 = 0

9400003c:       24840010        addiu   a0,a0,16        ; a0 := 0x10

According to this manual, the code in the 'delay slot' is executed before branching to the target address. I *think* that means that the code on 0x9400003C is part of the loop, which gives the loop more sense to me.
0x01676378 bytes of memory starting on 0x9445DDF0 is cleared. On exit the value of a0 is 0x95AD4168 (maybe 0x10 less, don't know if 0x9400003C is executed on loop exit), and a1 is 0.

*If* that is true, then 0x94000000 is not the entrypoint of the firmware. The 'web data' is extracted to 0x94f30000, which is cleared here. So it must have been moved already.

Re: Siemens SX551

Yup, I discovered that yesterday as well. Can you have a look at http://pastebin.com/Qpzw0Prm? (I'm running trunk now as requested in #openwrt-devel)

Re: Siemens SX551

I suppose you are referring to the fact that the address of the build in commandline is printed out wrong?

I suppose it's supplied in this line:

94275188:       2606ff20        addiu   a2,s0,-224      ; 0x9428ff20 "console=ttyS0,115200

(BTW, strange that arguments are loaded in registers, instead of pushed on stack.)
But I don't see where s0 gets it's value. According to the comments it should have been 0x94290000, but according to the print-out it was 1.
When s0 is altered as a side effect of one of the earlier opcodes, I suppose the compiler has to be told to use another MIPS dialect.

Is this running on your SX551? Did you find the entrypoint? If not, it could be that the bootloader jumps in after the point where s0 is set. (Unless a more complete assembly listing shows s0 to be set after some other print.)

39 (edited by Lekensteyn 2012-03-28 14:52:30)

Re: Siemens SX551

The pastebin is retrieved from my sx551 serial, so yes it runs.

It seems that the stack is used for local variables, arguments seems to be [url=http://logos.cs.uic.edu/366/notes/mips%20quick%20tutorial.htmpassed to registers in MIPS[/url]. Only the HI and LO registers are supposed to be changed, the others are general purpose registers that should not be changed.

The beginning of the function:

94275108:       27bdffc0        addiu   sp,sp,-64
9427510c:       afbf003c        sw      ra,60(sp)
94275110:       afb30024        sw      s3,36(sp)
94275114:       afb20020        sw      s2,32(sp)
94275118:       00809821        move    s3,a0
9427511c:       afb1001c        sw      s1,28(sp)
94275120:       afb00018        sw      s0,24(sp)
94275124:       afbe0038        sw      s8,56(sp)
94275128:       afb70034        sw      s7,52(sp)
9427512c:       afb60030        sw      s6,48(sp)
94275130:       afb5002c        sw      s5,44(sp)
94275134:       0d0a12f3        jal     0x94284bcc
94275138:       afb40028        sw      s4,40(sp)
9427513c:       0d09ccf5        jal     0x942733d4 ; prom_init may alter s0? (due to branch delay)
94275140:       3c109429        lui     s0,0x9429 ; <-------------------------------------------------- s0 := 0x9429 0000
94275144:       0d09d8c8        jal     0x94276320 ; setup_early_printk may alter s0?
94275148:       3c119429        lui     s1,0x9429
9427514c:       0d0a16e9        jal     0x94285ba4 ; cpu_report may alter s0?
94275150:       3c129429        lui     s2,0x9429
94275154:       0d09cdc5        jal     0x94273714 ; plat_mem_setup may alter s0?
94275158:       00000000        nop

; pr_info("Determined physical RAM map:\n");
9427515c:       3c049423        lui     a0,0x9423
94275160:       0d0860f5        jal     0x942183d4
94275164:       2484021c        addiu   a0,a0,540

; print_memory_map();
94275168:       0d09d3ad        jal     0x94274eb4      ; print_memory_map
9427516c:       00000000        nop

; pr_info("After print_memory_map\n");
94275170:       3c049423        lui     a0,0x9423
94275174:       0d0860f5        jal     0x942183d4      ; printk
94275178:       24840240        addiu   a0,a0,576       ; "<6>After print_memory_map\n"

; pr_info("boot_command_line %p builtin_cmdline %p COMMAND_LINE_SIZE %zu\n", boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
9427517c:       3c049423        lui     a0,0x9423
94275180:       2484025c        addiu   a0,a0,604       ; "<6>boot_command_line %p builtin_cmdline %p COMMAND_LINE_SIZE %zu\n"
94275184:       2625cca8        addiu   a1,s1,-13144    ; 0x9428cca8 allocated memory for use
94275188:       2606ff20        addiu   a2,s0,-224      ; 0x9428ff20 "console=ttyS0,115200 console=ttyS1,115200"
9427518c:       0d0860f5        jal     0x942183d4      ; printk
94275190:       24071000        li      a3,4096         ; 4096

The "... may alter s0" functions needs to be checked. (objdump the object files, e.g. printk.o, or analyze the vmlinux file)

I needed to make the next changes to addresses:

was 94100000, becomes:
build_dir/linux-ar7/linux-2.6.37.6/arch/mips/ar7/Platform:6:load-$(CONFIG_AR7)              += 0xffffffff94000000

--- target/linux/ar7/image/Makefile     (revision 31088)
+++ target/linux/ar7/image/Makefile     (working copy)
@@ -10,10 +10,10 @@
 DROP_SECTIONS:=.reginfo .mdebug .comment .note .pdr .options .MIPS.options
 OBJCOPY_SREC:=$(TARGET_CROSS)objcopy -S -O srec $(addprefix --remove-section=,$(DROP_SECTIONS))
 
-LOADADDR:=0x94600000
+LOADADDR:=0x94000000
 KERNEL_ENTRY:=0x94100000
 RAMSTART:=0x94000000
-RAMSIZE:=0x00100000
+RAMSIZE:=0x02000000

KERNEL_ENTRY is used in lzma2eva (and possibly other places, but not in vmlinux at least). I think that 0x94000000 (at which the code is uncompressed) is the entry point.

Re: Siemens SX551

Is the log on pastebin your complete bootlog? Mine gives some extra lines. But you added extra prints. So maybe there is some watchdog doing nasty?

I think that 0x94000000 (at which the code is uncompressed) is the entry point.

For vmlinux, yes. (When I remember well, it starts with

nop
j kernel_entry

)But does the bootloader jump to 0x94000000? Your disassembly of the firmware says no, because the 'web data' is zeroed.

94275140:       3c109429        lui     s0,0x9429 ; <-------------------------------------------------- s0 := 0x9429 0000
94275144:       0d09d8c8        jal     0x94276320 ; setup_early_printk may alter s0?
94275148:       3c119429        lui     s1,0x9429
9427514c:       0d0a16e9        jal     0x94285ba4 ; cpu_report may alter s0?
94275150:       3c129429        lui     s2,0x9429
94275154:       0d09cdc5        jal     0x94273714 ; plat_mem_setup may alter s0?

s0-s2 are all initialized on the same value. This is C code, I suppose? Makes me wonder about the optimizer.

41 (edited by Lekensteyn 2012-03-28 18:27:56)

Re: Siemens SX551

The functions are looked up in System.map and it seems to match the C code (with macros expanded ofc). Recall: lui loads the immediate shifted 16 bytes to the right with zero fill. s0-s2 are likely used later for an address (addiu s#,N with # 0-2 and # a negative/positive integer). Since the instruction after a jump instruction is always executed before the branch instruction itself, there must be some instruction after it. s0 is overwritten many times, but it looks like s1 is superfluous with s2. Perhaps it's sharing the load fairly to avoid wear (?).

About the disassembly of the original sx551 firmware, I've guessed some more:

94000000:       40026000        mfc0    v0,c0_sr        ; v0 := Coprocessor0_StatusRegister
94000004:       3c010040        lui     at,0x40         ; AssemblerTemporary := 0x40 0000
94000008:       00411024        and     v0,v0,at        ; v0 := v0 & at ; BEV
9400000c:       40826000        mtc0    v0,c0_sr        ; c0_sr := v0   ; location of exception vector = bootstrap

Am I correct to assume that 0x9000 0000 (virtual) is mapped to 0x0000 0000 (physical) or is it different for this CPU? (from page 61 of http://www.it.uu.se/edu/course/homepage … ogMan.pdf)

Checking the functions (done on the intermediate object code, not the vmlinux image):
0x94276320 setup_early_printk
- does not modify s[012] itself
- may call early_console_write which saves s1 on the stack on function entry and ensures that on function exit, the value is restored

0x94285ba4 cpu_report
- does not modify s[12] itself, s0 is modified and restored
- calls printk

0x94273714 plat_mem_setup
- see arch/mips/ar7/setup.c
- ioremap? hmm? the code is too large, I did not bother looking deep into the C code
- s[012] is not modified by the function itself
- get_system_type does not use s[012] either
- ...
- again, printk is called

pretty annoying debugging. Now I'll look into print *sigh*. I'm assuming that s1 is not wrongly modified, but have yet to prove it.

42 (edited by Lekensteyn 2012-03-29 17:11:46)

Re: Siemens SX551

OMG! It's working more!

[    0.000000] Linux version 2.6.37.6 (peter@penguin) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #12 Tue Mar 27 23:09:00 CEST 2012
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00018448 (MIPS 4KEc)
[    0.000000] TI AR7 (TNETD7300), ID: 0x0005, Revision: 0x26
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 02000000 @ 14000000 (usable)
[    0.000000] end of print_memory_map
[    0.000000] After print_memory_map
[    0.000000] boot_command_line 9428cca8 builtin_cmdline 9428ff20 COMMAND_LINE_SIZE 4096
[    0.000000] builtin_cmdline[0] = c
[    0.000000] before first strlcat
[    0.000000] Before second strlcat
[    0.000000] Before strlcpy
[    0.000000]  console=ttyS0,115200 console=ttyS1,115200
[    0.000000] Before boot_command_line strlcpy
[    0.000000] Before setting *cmdline_p
[    0.000000] before bootmem_init
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] before device_tree_init
[    0.000000] before sparse_init
[    0.000000] before plat_swiotlb_setup
[    0.000000] before paging_init
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal   0x00014000 -> 0x00016000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0: 0x00014000 -> 0x00016000
[    0.000000] arch_mem_init leaving
[    0.000000] end of setup_arch

I've replaced the nop after print_memory_map with "lui s0,0x9429" (well, to be precise, it's "printf '\x29\x94\x10\x3c'" (little endian smile). A function is misbehaving and improperly restoring the s0 register. Perhaps printk? Now, it's far too late and I should have been off to bed a while ago, so see ya later:)

If you're interested, when replacing the instruction passing 4096 as argument to printk with "addiu a3,sp,0", the result is 0x9425de40 (converted from integer)

Re: Siemens SX551

Wow! You've been doing loads of work!

About the disassembly of the original sx551 firmware, I've guessed some more:
<snipped code>
Am I correct to assume that 0x9000 0000 (virtual) is mapped to 0x0000 0000 (physical) or is it different for this CPU?

I don't see the connection between the disassembly and this question?

Checking the functions (done on the intermediate object code, not the vmlinux image):

Woudn't it be easier to a some prints of s1, to see where it changes? Although I must admit that I wouldn't know how to print a register value. I suppose it should be done in the intermediate code, but that isn't actually used, AFAIK. Maybe exchanging the .c file by a .S file?

44 (edited by Lekensteyn 2012-03-30 16:09:51)

Re: Siemens SX551

I replied to your comment on invalid interpretation of the assembly, it's not really related and does not useful information I think. The question is separate.

I isolated the problem to setup_early_printk, swapping lui s2 and s0 -> it still worked. But swapping lui s0 and s1:

[    0.000000] boot_command_line ffffccb8 builtin_cmdline 9428ff20 COMMAND_LINE_SIZE 4096

Investigating...

To overwrite instructions at a specific address, I use:

printf '\x3c\x11\x94\x29' | /tmp/rev|dd of=/tmp/vmlinux conv=notrunc bs=1 count=4 seek=$((0x275140))

/tmp/rev is a program that simply outputs the input in reverse order, I use it for convenience.

[s]I've verified that the stack address is not changed before and after calling setup_early_printk (0x9425de40).[/s]
Doh, both stack addresses were retrieved after setup_early_printk. The stack address DOES change! It's 0x68 more
after calling setup_early_printk. I now managed to get back in start_kernel by adding 0x68 to the sp before the next jump. Verified by seeing the printk after setup_arch(&command_line) is executed and then execution hangs in there (well, I haven't add any more printk()s before printk of the "Kernel command line".

Uh.. right now I'm very confused. printk() before and after setup_early_printk do not report a modified SP... I'm sure that that s1 is modified by either:

- printk (under some circuimstances?)
- ...

compiler bug?

45 (edited by Lekensteyn 2012-03-30 22:47:39)

Re: Siemens SX551

Look smile

===========================================================
 TI ADSL AR7300 Loader 0.71.4 build Oct 18 2005 11:13:40
                 Broad Net Technology, INC.
===========================================================
MXIC MX29LV160B bottom boot 16-bit mode found

Copying boot params.....DONE

Flash Checking  Passed.

Unzipping  web at 0x94f30000 ... [LZMA] done
Unzipping code at 0x94000000 ... [LZMA] done[    0.000000] Linux version 2.6.37.6 (peter@penguin) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #23 Sat Mar 31 00:11:52 CEST 2012
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00018448 (MIPS 4KEc)
[    0.000000] TI AR7 (TNETD7300), ID: 0x0005, Revision: 0x26
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 02000000 @ 14000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal   0x00014000 -> 0x00016000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0: 0x00014000 -> 0x00016000
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
[    0.000000] Kernel command line:  console=ttyS0,115200 console=ttyS1,115200
[    0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[    0.000000] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes
[    0.000000] Memory: 29684k/32768k available (2168k kernel code, 3084k reserved, 329k data, 152k init, 0k highmem)
[    0.000000] NR_IRQS:256
[    0.000000] Calibrating delay loop... 149.50 BogoMIPS (lpj=747520)
[    0.210000] pid_max: default: 32768 minimum: 301
[    0.210000] Mount-cache hash table entries: 512
[    0.230000] NET: Registered protocol family 16
[    0.260000] bio: create slab <bio-0> at 0
[    0.270000] Switching to clocksource MIPS
[    0.290000] NET: Registered protocol family 2
[    0.300000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.310000] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[    0.310000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.320000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.330000] TCP reno registered
[    0.330000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.340000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.340000] NET: Registered protocol family 1
[    0.420000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.430000] JFFS2 version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.440000] msgmni has been set to 57
[    0.440000] io scheduler noop registered
[    0.450000] io scheduler deadline registered (default)
[    0.460000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.470000] serial8250: ttyS0 at MMIO 0x8610e00 (irq = 15) is a TI-AR7
[    0.000000] Linux version 2.6.37.6 (peter@penguin) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #23 Sat Mar 31 00:11:52 CEST 2012
[    0.000000] Linux version 2.6.37.6 (peter@penguin) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #23 Sat Mar 31 00:11:52 CEST 2012
[    0.000000] bootconsole [early0] enabled
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00018448 (MIPS 4KEc)
[    0.000000] CPU revision is: 00018448 (MIPS 4KEc)
[    0.000000] TI AR7 (TNETD7300), ID: 0x0005, Revision: 0x26
[    0.000000] TI AR7 (TNETD7300), ID: 0x0005, Revision: 0x26
[    0.000000] Determined physical RAM map:
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 02000000 @ 14000000 (usable)
[    0.000000]  memory: 02000000 @ 14000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Zone PFN ranges:
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal   0x00014000 -> 0x00016000
[    0.000000]   Normal   0x00014000 -> 0x00016000
[    0.000000] Movable zone start PFN for each node
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0: 0x00014000 -> 0x00016000
[    0.000000]     0: 0x00014000 -> 0x00016000
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
[    0.000000] Kernel command line:  console=ttyS0,115200 console=ttyS1,115200
[    0.000000] Kernel command line:  console=ttyS0,115200 console=ttyS1,115200
[    0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
[    0.000000] PID hash table entries: 128 (order: -3, 512 bytes)
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[    0.000000] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
[    0.000000] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes
[    0.000000] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes
[    0.000000] Memory: 29684k/32768k available (2168k kernel code, 3084k reserved, 329k data, 152k init, 0k highmem)
[    0.000000] Memory: 29684k/32768k available (2168k kernel code, 3084k reserved, 329k data, 152k init, 0k highmem)
[    0.000000] NR_IRQS:256
[    0.000000] NR_IRQS:256
[    0.000000] Calibrating delay loop... 149.50 BogoMIPS (lpj=747520)
[    0.000000] Calibrating delay loop... 149.50 BogoMIPS (lpj=747520)
[    0.210000] pid_max: default: 32768 minimum: 301
[    0.210000] pid_max: default: 32768 minimum: 301
[    0.210000] Mount-cache hash table entries: 512
[    0.210000] Mount-cache hash table entries: 512
[    0.230000] NET: Registered protocol family 16
[    0.230000] NET: Registered protocol family 16
[    0.260000] bio: create slab <bio-0> at 0
[    0.260000] bio: create slab <bio-0> at 0
[    0.270000] Switching to clocksource MIPS
[    0.270000] Switching to clocksource MIPS
[    0.290000] NET: Registered protocol family 2
[    0.290000] NET: Registered protocol family 2
[    0.300000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.300000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.310000] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[    0.310000] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[    0.310000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.310000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.320000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.320000] TCP: Hash tables configured (established 1024 bind 1024)
[    0.330000] TCP reno registered
[    0.330000] TCP reno registered
[    0.330000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.330000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.340000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.340000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.340000] NET: Registered protocol family 1
[    0.340000] NET: Registered protocol family 1
[    0.420000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.420000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.430000] JFFS2 version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.430000] JFFS2 version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.440000] msgmni has been set to 57
[    0.440000] msgmni has been set to 57
[    0.440000] io scheduler noop registered
[    0.440000] io scheduler noop registered
[    0.450000] io scheduler deadline registered (default)
[    0.450000] io scheduler deadline registered (default)
[    0.460000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.460000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.470000] serial8250: ttyS0 at MMIO 0x8610e00 (irq = 15) is a TI-AR7
[    0.470000] serial8250: ttyS0 at MMIO 0x8610e00 (irq = 15) is a TI-AR7
[    0.970000] console [ttyS0] enabled
[    0.970000] console [ttyS0] enabled
[    0.980000] serial8250: ttyS1 at MMIO 0x8610f00 (irq = 16) is a TI-AR7
[    0.980000] serial8250: ttyS1 at MMIO 0x8610f00 (irq = 16) is a TI-AR7
[    1.010000] physmap platform flash device: 00800000 at 10000000
[    1.010000] physmap platform flash device: 00800000 at 10000000
[    1.020000] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x0000c2 Chip ID 0x002249
[    1.020000] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x0000c2 Chip ID 0x002249
[    1.040000] Amd/Fujitsu Extended Query Table at 0x0040
[    1.040000] Amd/Fujitsu Extended Query Table at 0x0040
[    1.050000]   Amd/Fujitsu Extended Query version 1.0.
[    1.050000]   Amd/Fujitsu Extended Query version 1.0.
[    1.060000] number of CFI chips: 1
[    1.060000] number of CFI chips: 1
[    1.070000] cmdlinepart partition parsing not available
[    1.070000] cmdlinepart partition parsing not available
[    1.080000] RedBoot partition parsing not available
[    1.080000] RedBoot partition parsing not available
[    1.090000] Unknown magic: 4f5464ca
[    1.090000] Unknown magic: 4f5464ca
[    1.100000] 4 ar7part partitions found on MTD device physmap-flash.0
[    1.100000] 4 ar7part partitions found on MTD device physmap-flash.0
[    1.110000] Creating 4 MTD partitions on "physmap-flash.0":
[    1.110000] Creating 4 MTD partitions on "physmap-flash.0":
[    1.130000] 0x000000000000-0x000000010000 : "loader"
[    1.130000] 0x000000000000-0x000000010000 : "loader"
[    1.140000] 0x0000001f0000-0x000000200000 : "config"
[    1.140000] 0x0000001f0000-0x000000200000 : "config"
[    1.160000] 0x0000000b0000-0x0000001f0000 : "linux"
[    1.160000] 0x0000000b0000-0x0000001f0000 : "linux"
[    1.180000] 0x0000000e0000-0x0000001f0000 : "rootfs"
[    1.180000] 0x0000000e0000-0x0000001f0000 : "rootfs"
[    1.200000] mtd: partition "rootfs" set to be root filesystem
[    1.200000] mtd: partition "rootfs" set to be root filesystem
[    1.210000] split_squashfs: no squashfs found in "physmap-flash.0"
[    1.210000] split_squashfs: no squashfs found in "physmap-flash.0"
[    1.240000] Fixed MDIO Bus: probed
[    1.240000] Fixed MDIO Bus: probed
[    1.240000] CPU 0 Unable to handle kernel paging request at virtual address 0000000c, epc == 94000db4, ra == 942172bc
[    1.240000] CPU 0 Unable to handle kernel paging request at virtual address 0000000c, epc == 94000db4, ra == 942172bc
[    1.260000] Oops[#1]:
[    1.260000] Oops[#1]:
[    1.260000] Cpu 0
[    1.260000] Cpu 0
[    1.260000] $ 0   :[    1.260000] $ 0   : 00000000 00000000 10008400 10008400 00000000 00000000 00000007 00000007

[    1.260000] $ 4   :[    1.260000] $ 4   : 0000001a 0000001a 00000001 00000001 08611f00 08611f00 942a9e68 942a9e68

[    1.260000] $ 8   :[    1.260000] $ 8   : 00000000 00000000 94122c70 94122c70 00000000 00000000 00000000 00000000

[    1.260000] $12   :[    1.260000] $12   : 00000008 00000008 00000008 00000008 00000020 00000020 0000001e 0000001e

[    1.260000] $16   :[    1.260000] $16   : 958dc600 958dc600 942b0000 942b0000 94290000 94290000 942171f8 942171f8

[    1.260000] $20   :[    1.260000] $20   : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

[    1.260000] $24   :[    1.260000] $24   : 00000010 00000010 9414a900 9414a900                                    

[    1.260000] $28   :[    1.260000] $28   : 95816000 95816000 95817e98 95817e98 00000000 00000000 942172bc 942172bc

[    1.260000] Hi    : ff65e69c
[    1.260000] Hi    : ff65e69c
[    1.260000] Lo    : 19216de2
[    1.260000] Lo    : 19216de2
[    1.260000] epc   : 94000db4 0x94000db4
[    1.260000] epc   : 94000db4 0x94000db4
[    1.260000]     Not tainted
[    1.260000]     Not tainted
[    1.260000] ra    : 942172bc 0x942172bc
[    1.260000] ra    : 942172bc 0x942172bc
[    1.260000] Status: 10008403    [    1.260000] Status: 10008403    KERNEL KERNEL EXL EXL IE IE 

[    1.260000] Cause : 10800008
[    1.260000] Cause : 10800008
[    1.260000] BadVA : 0000000c
[    1.260000] BadVA : 0000000c
[    1.260000] PrId  : 00018448 (MIPS 4KEc)
[    1.260000] PrId  : 00018448 (MIPS 4KEc)
[    1.260000] Modules linked in:[    1.260000] Modules linked in:

[    1.260000] Process swapper (pid: 1, threadinfo=95816000, task=958148a8, tls=00000000)
[    1.260000] Process swapper (pid: 1, threadinfo=95816000, task=958148a8, tls=00000000)
[    1.260000] Stack :[    1.260000] Stack : 94295c8c 94295c8c 94290000 94290000 94290000 94290000 94280f8c 94280f8c 94295c8c 94295c8c 94290000 94290000 94290000 94290000 94000100 94000100

[    1.260000]        [    1.260000]         00003937 00003937 00000000 00000000 94260000 94260000 00000000 00000000 00000100 00000100 94270000 94270000 00000000 00000000 940501c8 940501c8

[    1.260000]        [    1.260000]         94295498 94295498 94295c8c 94295c8c 94295c2c 94295c2c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 94271a18 94271a18

[    1.260000]        [    1.260000]         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 94003270 94003270

[    1.260000]        [    1.260000]         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

[    1.260000]        [    1.260000]         ... ...

[    1.260000] Call Trace:[    1.260000] Call Trace:[<94280f8c>] 0x94280f8c
[<94280f8c>] 0x94280f8c
[    1.260000] [<94000100>] 0x94000100
[    1.260000] [<94000100>] 0x94000100
[    1.260000] [<940501c8>] 0x940501c8
[    1.260000] [<940501c8>] 0x940501c8
[    1.260000] [<94271a18>] 0x94271a18
[    1.260000] [<94271a18>] 0x94271a18
[    1.260000] [<94003270>] 0x94003270
[    1.260000] [<94003270>] 0x94003270
[    1.260000] [<94271944>] 0x94271944
[    1.260000] [<94271944>] 0x94271944
[    1.260000] [<94003260>] 0x94003260
[    1.260000] [<94003260>] 0x94003260
[    1.260000] 
[    1.260000] 
[    1.260000] 
[    1.260000] 
[    1.260000] Code:[    1.260000] Code: 00001021  00001021  3c029426  3c029426  8c420660  8c420660 <8c43000c><8c43000c> 00852004  00852004  00042027  00042027  00832024  00832024  ac44000c  ac44000c  00001021  00001021 

[    1.260000] Disabling lock debugging due to kernel taint
[    1.260000] Disabling lock debugging due to kernel taint
[    1.630000] Kernel panic - not syncing: Attempted to kill init!
[    1.630000] Kernel panic - not syncing: Attempted to kill init!
[    1.640000] Rebooting in 3 seconds..[    1.640000] Rebooting in 3 seconds..

At least I now know where the error is. I disabled the prom_init() call (in assembly, commenting in C likely works as well). neither printk nor setup_early_printk were responsible for the error. I saw it a bit late... delayed execution foo again. I wish I saw this three days ago.

Edit: not sure why lines are printed twice, perhaps because I pass two console= options, or something is uninitialized?

Re: Siemens SX551

Uh.. right now I'm very confused. printk() before and after setup_early_printk do not report a modified SP

I had a look at setup_early_printk, and it does exactly what the name says. It provides 2 functions, one for reading the console, and one for writing. So I wonder how it is possible to printk anything before the functions are provided?

Look

I do. And I'm impressed!
Did you make a mistake in copy/pasting, or does the kernel actually reboot after [    0.470000] serial8250: ttyS0 at MMIO 0x8610e00 (irq = 15) is a TI-AR7?
Is this reproducable?

At least I now know where the error is. I disabled the prom_init() call <snip> not sure why lines are printed twice, perhaps because I pass two console= options, or something is uninitialized?

The lines are doubled after the 'reboot'. So maybe it's because setup_early_printk is called twice, providing 2 output functions?

void __init prom_init(void)
{
        ar7_init_cmdline(fw_arg0, (char **)fw_arg1);
        ar7_init_env((struct env_var *)fw_arg2);
        console_config();
}

ar7_init_cmdline reads the commandline as provided in fw_arg0 and fw_arg1 (as int argc, char **argv), and catenate it to one single command line. console_config() parses the line, and if no 'console=' is found, it adds one (console=ttyS0,38400n8).
ar7_init_env reads  the environment as provided by either the psp or the adam2 bootloader.
I wonder where fw_arg0-2 came from. I suppose they are to be provided by the bootloader, which will not be the case. So maybe parsing this values kills s0?

It might be a good idea to change the code to

void __init prom_init(void)
{
    strcat(prom_getcmdline(), "console=ttyS0,115200n8" );
}

(BTW, the code is in build_dir/linux-ar7/linux-2.6.---/arch/mips/ar7/prom.c)

[    1.200000] mtd: partition "rootfs" set to be root filesystem<snip>
[    1.630000] Kernel panic - not syncing: Attempted to kill init!

It just can't find it's rootfs?

My plan was to provide an initramfs which can mount an usbstick, and switch_root, or use kexec to load a more extensive kernel from usbstick.
Unfortunately the PCI bus doesn't show up in your bootlog, so the USB is not available. I don't see a trace of VLYNQ, so maybe it's just disabled in your kernel?

47 (edited by Lekensteyn 2012-03-31 15:03:59)

Re: Siemens SX551

I've removed the console=ttyS1,115200 option, did some random changes (in an attempt to strip the kernel and add support or USB), properly disabled the use of loading from the fw_argX in prom_init (arch/mips/ar7/prom.c):

        if (0) {
                ar7_init_cmdline(fw_arg0, (char **)fw_arg1);
                ar7_init_env((struct env_var *)fw_arg2);
                console_config();
        }

kernel .config on 2.6.37.6 (from openwrt trunk): http://pastebin.com/VPZdQNmC

New boot log looks promising, the next goal is to get a filesystem mounted: http://pastebin.com/hL3GwweX

In summary:

- change LOADADDR in build_dir/linux-ar7/linux-2.6.37.6/arch/mips/ar7/Platform from 0x94600000 to 0x94000000 and RAMSIZE from 0x00100000 to 0x02000000
- disable loading from fw_argX by adding it in an if(0){...}, commenting was not enough as the compiler then complains about unused functions
- set command line "console=ttyS0,115200"
- compile & flash & play!

Todo:

- find out why reading the fw_arg values fails (possibly because the bootloader does not initialize those?)
- find the right configuration to allow for mounting an external USB

Re: Siemens SX551

New boot log looks promising

Indeed. Did you see that this line is doubled:

[    0.470000] console [ttyS0] enabled, bootconsole disabled
[    0.470000] console [ttyS0] enabled, bootconsole disabled

I think one is provided by bootconsole (as provided by setup_early_printk) and the other by the 'real' console.

vlynq works (or at least is initialized). Good. Unfortunately the PCI bus is not detected. (Does vlynq support device probing?)

in an attempt to strip the kernel

I think you can safely remove mtd support, squashfs and jffs2.

- find out why reading the fw_arg values fails (possibly because the bootloader does not initialize those?)

I think it's save to assume they are never set, and contain random values.
Actually they are filled in linux/arch/mips/kernel/head.S:

        PTR_LA          t0, __bss_start         # clear .bss
        LONG_S          zero, (t0)
        PTR_LA          t1, __bss_stop - LONGSIZE
1:
        PTR_ADDIU       t0, LONGSIZE
        LONG_S          zero, (t0)
        bne             t0, t1, 1b

        LONG_S          a0, fw_arg0             # firmware arguments
        LONG_S          a1, fw_arg1
        LONG_S          a2, fw_arg2
        LONG_S          a3, fw_arg3

So they contain the contents of a0...3 on entry of the kernel code. This might be random data, as this bootloader is not supposed to start a Linux kernel.

Re: Siemens SX551

Ah, indeed, and there is another console output that we *could* use (for spamming the console big_smile)

[    0.460000] serial8250: ttyS0 at MMIO 0x8610e00 (irq = 15) is a TI-AR7
[    0.470000] console [ttyS0] enabled, bootconsole disabled
[    0.470000] console [ttyS0] enabled, bootconsole disabled
[    0.480000] serial8250: ttyS1 at MMIO 0x8610f00 (irq = 16) is a TI-AR7

I saw could not find the following file in my tree:
https://dev.openwrt.org/browser/trunk/target/linux/ar7/files/arch/mips/ar7/vlynq-pci.c?rev=9086

12:48:34 < Lekensteyn> [..] what is the status of PCI support on the AR7...?
[..]
12:57:30 < KanjiMonster> Lekensteyn: afaik AR7 does not have PCI, just something looking similar (this vlync stuff)

I've already disabled jffs2; not sure about mtd and squashfs. Wouldn't it be nice if we could put a squashfs on the flash?

Re: Siemens SX551

afaik AR7 does not have PCI, just something looking similar (this vlync stuff)

He's right. The AR7 doesn't have PCI, yet I'm sure this box has. A first indication is the mini-PCI slot. (Duh!). But I've read in the forums that there are other AR7 devices with mini-PCI like slots, which doesn't accept mini-PCI cards. So that *might* be a bad inidication. The second indication is the VT6212 chip, providing the USB 2.0 port(s). This is a PCI host controller. The third indication is the bootlog of the original firmware:

Enumerating PCI device 5
 PCI: Slot=0, ID=TI VLYNQ2PCI , Index=0, MemBase=0x00000000, Int=00
 PCI: Slot=1, ID=Atheros AR5212 , Index=0, MemBase=0x40000000, Int=00
 PCI: Slot=2, ID=VIA VT6212 , Index=0, MemBase=0x60000000, Int=00
 PCI: Slot=3, ID=VIA VT6212 , Index=1, MemBase=0x60000020, Int=00
 PCI: Slot=4, Vendor:DeviceID=0x1106:0x3104, Index=0, MemBase=0x40010000, Int=00
 PCI: Slot=5, --- No device present ---

So I'm sure there must be a vlynq to pci bridge on board.

Wouldn't it be nice if we could put a squashfs on the flash?

Maybe. But where? When you look at the flash layout, there is not much room. Unless you are exchanging the bootloader you cannot touch partition 0-2. (Well, you *might* take 1 and 2, but then you cannot restore from bad flash anymore.) Partition 3 can be used, I think. It contains the user settings of the firmware. That's 128k.
Partition 4 can be used, but needs to have a valid LZMA header, to be accepted by the bootloader, and a valid footer, to be accepted by the flasher. Don't know the blocksize of the flash, but I suppose this means that maybe 240k remains. Partition 5 cannot be used. Partition 6 contains the bootloader settings. That's not even 512 bytes, but it's taking a whole 64k block. Maybe it's possible to use the last 60k.
That gives 128 + 240 + 60k, in 3 chunks. Given that we need an USB mass storage device anyway (2MB flash isn't enough for enabling ADSL and WLAN), it's not worth the hassle. (Unless it turns out that we cannot squeeze the kernel + USB mounting system in 1.4MB. But my experiments were hopeful. A kernel + usb_ehci + usb_storage + ext3 + initramfs + busybox + uclib was compressed only 1.2MB. And I didn't squeeze the kernel, yet)