Hi Christian,
On 04/03/13 21:07, Christian Gieseler wrote:
i just wanted to give some feedback about this, so that other people don´t
run in the same issue.
The initial checksum gets corrupted because of variables from m532x.c are
placed in the area where romfs is placed before it is mounted/copied to the
final position.
The two commands
sys_clk_khz = clock_pll(0, 0);
sys_clk_mhz = sys_clk_khz/1000;
overwrite the romfs contents. Commenting the stuff out solves the romfs
problem. You find these variables only in m532x.c and I don´t see what they
are good for. They also don´t exist for other coldfire platforms.
They are in the sources for quite a while now and we did not have the
problem with earlier kernels. Has something changed in the compiling/linking
process, so that addresses have moved?
Well, not so long ago I changed the linker scripts to make them more
like the general m68k scripts. That we we can use the linux common
linker script definitions (which greatly simplifies maintenance).
Not sure if this may have caused this.
Anyway, if all that early clock and pll code is not needed I would
like to remove it. I have never liked how that is so different to
startup than all the other ColdFire parts. I think this code originally
came from Freescale. I don't have a 532x board, so I have never been
able to change to much of that code and test it.
What sort of board do you have? Is it the Freescale 5329EVB or your
own design?
Regards
Greg
Hi Christian,
On 24/01/13 00:12, Christian Gieseler wrote:
Or is the checksum
tested on a wrong value because I misconfigured an address.
Does someone have a hint how to solve this or where to look for a
solution?
The bootmessages are attached for reference.
Can you send the entire boot sequence?
I want to see all the load segment addresses that are earlier in the
boot
output.
Ok, this didn't have the information I was looking for after all :-(
Can you send the output of:
m68k-linux-objdump --headers vmlinux
Not sure what your toolchain prefix is, but substitute in place of
m68k-linux-objdump for whatever the Code Sourcery name is.
m68k-uclinux-objdump --headers vmlinux
vmlinux: file format elf32-m68k
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 001c9f70 40020000 40020000 00002000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata 00026640 401ea000 401ea000 001cc000 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 __ksymtab 000045d8 40210640 40210640 001f2640 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 __ksymtab_gpl 00002318 40214c18 40214c18 001f6c18 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 __kcrctab 000022ec 40216f30 40216f30 001f8f30 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 __kcrctab_gpl 0000118c 4021921c 4021921c 001fb21c 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 __ksymtab_strings 0000dfea 4021a3a8 4021a3a8 001fc3a8 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 __param 00000330 40228394 40228394 0020a394 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 __modver 0000193c 402286c4 402286c4 0020a6c4 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .data 0001de40 4022a000 4022a000 0020c000 2**4
CONTENTS, ALLOC, LOAD, DATA
10 .init.text 0000d57c 40248000 40248000 0022a000 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .init.data 00004a84 4025557c 4025557c 0023757c 2**2
CONTENTS, ALLOC, LOAD, DATA
12 .bss 0000f24c 4025a000 4025a000 0023c000 2**4
ALLOC
13 .comment 00000030 00000000 00000000 0023c000 2**0
CONTENTS, READONLY
Ok, that looks good too. The romfs start address from you console boot
log:
uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000
matches up with the end of the bss segment. Which is what I would expect.
I would suggest putting some printk trace around the ROMS checksum error
that dumps out what the memory contents of that first romfs block is.
Compare that with your original and see exactly what has changed. Is it just
a few bytes off, or has the whole thing been corrupted in some way?
Regards
Greg
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
