[uClinux-dev] ROMFS: bad initial checksum

Christian,

I am not at all an expert on your level, so I am taking a guess: it seems strange to me that the first MTD partition is RAM, not ROM (flash?).

Post by Christian Gieseler
0x000000000000-0x00000019c000 : "ROMfs"

Can this be the "ROMFS" that (of course) has the wrong checksum?

Post by Christian Gieseler
ROMFS: bad initial checksum on dev romfs.

Does this mean that your kernel command line has an improper parameter for one of the MTD partitions, i.e., the one in RAM?

My apologies if this is off base.

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

Post by Christian Gieseler
Hi all,
I am migrating our coldfire 5329 board to linux 3.6.
I am stuck now with mounting of romfs having a bad initial checksum of the
first 512 bytes. The system hangs after this message.
Even if the functions in fs/romfs/inode.c have moved a bit from 2.6.25 to
super.c and friends from what I can see the routines to
calculate the checksum are basically the same. Genromfs (0.5.1) on the host
has not changed. Has the new Kernel any configuration option
that has to be changed to generate a proper romfs.img? 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.
Thank you for your help.
Regards
Christian
snip
---------
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 23
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver
ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART
console [ttyS0] enabled
ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART
ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART
uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000
uclinux[mtd]: set ROMfs to be root filesystem
0x000000000000-0x00000019c000 : "ROMfs"
el5329 flash device: 1000000 at 0
el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
0x000001 Chip ID 0x002101
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
0x000000000000-0x000000020000 : "vectors"
0x000000020000-0x000000060000 : "parameters"
0x000000060000-0x000000100000 : "bootloader"
0x000000100000-0x000000700000 : "image"
0x000000700000-0x000001000000 : "user_data"
libphy: fec_enet_mii_bus: probed
TCP: cubic registered
NET: Registered protocol family 17
ROMFS: bad initial checksum on dev romfs.
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

Christian Gieseler

2013-01-23 10:53:00 UTC

Hi Larry,

maybe it sounds a bit confusing but from what I know this is usual to have a
romfs in RAM. Romfs does not necessarily mean that it is located in a ROM or
Flash Device. It is just a very compact filesystem.

Post by Larry Baker
Christian,
I am not at all an expert on your level, so I am taking a guess: it seems

strange to me that the first MTD partition is RAM, not ROM (flash?).

Post by Larry Baker

Post by Christian Gieseler
0x000000000000-0x00000019c000 : "ROMfs"

Can this be the "ROMFS" that (of course) has the wrong checksum?

Post by Christian Gieseler
ROMFS: bad initial checksum on dev romfs.

Does this mean that your kernel command line has an improper parameter for

one of the MTD partitions, i.e., the one in RAM?
My Kernel command line looks like this: "Kernel command line:
rootfstype=romfs console=tty1 console=ttyS0,115200"

This is the same parameter like I used it with the old kernel.

Post by Larry Baker
My apologies if this is off base.

Thanks for your reply.
Regards
Christian

Greg Ungerer

2013-01-23 12:16:48 UTC

Hi Christian,

Post by Christian Gieseler
I am migrating our coldfire 5329 board to linux 3.6.
I am stuck now with mounting of romfs having a bad initial checksum of the
first 512 bytes. The system hangs after this message.
Even if the functions in fs/romfs/inode.c have moved a bit from 2.6.25 to
super.c and friends from what I can see the routines to
calculate the checksum are basically the same. Genromfs (0.5.1) on the host
has not changed. Has the new Kernel any configuration option
that has to be changed to generate a proper romfs.img?

No, nothing has changed in this area. I have run 3.6 kernels on
ColdFire boards using romfs setups the same as every kernel before.

Post by Christian Gieseler
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.

How do you load the kernel and romfs into RAM?
Are you positive that the romfs is entirely loaded at the address you
think it should be?

Regards
Greg

Post by Christian Gieseler
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 23
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver
ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART
console [ttyS0] enabled
ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART
ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART
uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000
uclinux[mtd]: set ROMfs to be root filesystem
0x000000000000-0x00000019c000 : "ROMfs"
el5329 flash device: 1000000 at 0
el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
0x000001 Chip ID 0x002101
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
0x000000000000-0x000000020000 : "vectors"
0x000000020000-0x000000060000 : "parameters"
0x000000060000-0x000000100000 : "bootloader"
0x000000100000-0x000000700000 : "image"
0x000000700000-0x000001000000 : "user_data"
libphy: fec_enet_mii_bus: probed
TCP: cubic registered
NET: Registered protocol family 17
ROMFS: bad initial checksum on dev romfs.
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

Christian Gieseler

2013-01-23 13:25:18 UTC

Hi Greg,

-----Original Message-----
From: Greg Ungerer [mailto:gregungerer at westnet.com.au]
Sent: Wednesday, January 23, 2013 1:17 PM
To: uClinux development list
Cc: Christian Gieseler
Subject: Re: [uClinux-dev] ROMFS: bad initial checksum
Hi Christian,

Post by Christian Gieseler
I am migrating our coldfire 5329 board to linux 3.6.
I am stuck now with mounting of romfs having a bad initial checksum of
the first 512 bytes. The system hangs after this message.
Even if the functions in fs/romfs/inode.c have moved a bit from 2.6.25
to super.c and friends from what I can see the routines to calculate
the checksum are basically the same. Genromfs (0.5.1) on the host has
not changed. Has the new Kernel any configuration option that has to
be changed to generate a proper romfs.img?

No, nothing has changed in this area. I have run 3.6 kernels on ColdFire

boards using romfs setups the same as every kernel before.
Are there critical configuration options that I should check another time?

Can you send the entire boot sequence?
I want to see all the load segment addresses that are earlier in the boot

output.

Linux version 3.6.0-uc0 (christian at cglinux) (gcc version 4.6.1 (Sourcery
CodeBench Lite 2011.09-23) ) #154 PREEMPT Wed Jan 23 14:04:49 CET 2013

uClinux/COLDFIRE(m532x)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 2024
Kernel command line: rootfstype=romfs console=tty1 console=ttyS0,115200
PID hash table entries: 2048 (order: 0, 8192 bytes)
Dentry cache hash table entries: 2048 (order: 0, 8192 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Memory available: 11992k/16256k RAM, (1831k kernel code, 508k data)
NR_IRQS:256
Calibrating delay loop... 154.62 BogoMIPS (lpj=77312)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource tmr
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 8192 bytes)
TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
TCP: Hash tables configured (established 1024 bind 2048)
TCP: reno registered
UDP hash table entries: 512 (order: 0, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 23
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver
ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART
console [ttyS0] enabled
ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART
ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART
uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on "RAM":
0x000000000000-0x00000019c000 : "ROMfs"
el5329 flash device: 1000000 at 0
el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer
ID
0x000001 Chip ID 0x002101
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
Creating 5 MTD partitions on " el5329 flash":
0x000000000000-0x000000020000 : "vectors"
0x000000020000-0x000000060000 : "parameters"
0x000000060000-0x000000100000 : "bootloader"
0x000000100000-0x000000700000 : "image"
0x000000700000-0x000001000000 : "user_data"
libphy: fec_enet_mii_bus: probed
TCP: cubic registered
NET: Registered protocol family 17
ROMFS: bad initial checksum on dev romfs.

How do you load the kernel and romfs into RAM?

I use dbug as bootloader and copy image.bin via tftp and then execute from
ram:

Power-on Reset

ColdFire MCF532x
Firmware v4a.1a.1b.0100_1616 (Built on Nov 5 2009 15:47:58)
Copyright 2005 Freescale Semiconductor, Inc.
Enter 'help' for help.

dBUG> dn
Downloading Image 'image.bin' from 192.168.10.254
TFTP transfer completed
Read 3228676 bytes (6307 blocks)
dBUG> go 0x40020000

Are you positive that the romfs is entirely loaded at the address you think

it should be?
Yes I think the romfs is entirely loaded, but I am not sure about the
address. I thought this is calculated in the vendor Makefile
Is that right?

genromfs -v -V "ROMdisk" -f $(ROMFSIMG) -d $(ROMFSDIR)
$(CROSS)objcopy -O binary $(ROOTDIR)/$(LINUXDIR)/linux \
$(IMAGEDIR)/linux.bin
cat $(IMAGEDIR)/linux.bin $(ROMFSIMG) > $(IMAGE)
$(ROOTDIR)/tools/cksum -b -o 2 $(IMAGE) >> $(IMAGE)
[ -n "$(NO_BUILD_INTO_TFTPBOOT)" ] || cp $(IMAGE) /var/lib/tftpboot
[ -n "$(NO_BUILD_INTO_TFTPBOOT)" ] || cp $(ROMFSIMG)
/var/lib/tftpboot
BSS=`$(CROSS)objdump --headers $(ROOTDIR)/$(LINUXDIR)/linux | \
grep .bss` ; \
ADDR=`set -- $${BSS} ; echo 0x$${4}` ; \
$(CROSS)objcopy --add-section=.romfs=$(ROMFSIMG) \
--adjust-section-vma=.romfs=$${ADDR} --no-adjust-warnings \
--set-section-flags=.romfs=alloc,load,data \
$(ROOTDIR)/$(LINUXDIR)/linux $(ELFIMAGE) 2> /dev/null

Regards
Greg

Thanks for your help.
Regards
Christian

Greg Ungerer

2013-01-23 13:43:37 UTC

Hi Christian,

Post by Christian Gieseler
I am migrating our coldfire 5329 board to linux 3.6.
I am stuck now with mounting of romfs having a bad initial checksum of
the first 512 bytes. The system hangs after this message.
Even if the functions in fs/romfs/inode.c have moved a bit from 2.6.25
to super.c and friends from what I can see the routines to calculate
the checksum are basically the same. Genromfs (0.5.1) on the host has
not changed. Has the new Kernel any configuration option that has to
be changed to generate a proper romfs.img?

No, nothing has changed in this area. I have run 3.6 kernels on ColdFire

boards using romfs setups the same as every kernel before.
Are there critical configuration options that I should check another time?

No, none really. Nothing has changed with regard to config options
you need set either.

Post by Christian Gieseler
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?

Post by Christian Gieseler
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.

Post by Greg Ungerer
Linux version 3.6.0-uc0 (christian at cglinux) (gcc version 4.6.1 (Sourcery
CodeBench Lite 2011.09-23) ) #154 PREEMPT Wed Jan 23 14:04:49 CET 2013
uClinux/COLDFIRE(m532x)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 2024
Kernel command line: rootfstype=romfs console=tty1 console=ttyS0,115200
PID hash table entries: 2048 (order: 0, 8192 bytes)
Dentry cache hash table entries: 2048 (order: 0, 8192 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Memory available: 11992k/16256k RAM, (1831k kernel code, 508k data)
NR_IRQS:256
Calibrating delay loop... 154.62 BogoMIPS (lpj=77312)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource tmr
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 8192 bytes)
TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
TCP: Hash tables configured (established 1024 bind 2048)
TCP: reno registered
UDP hash table entries: 512 (order: 0, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 23
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver
ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART
console [ttyS0] enabled
ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART
ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART
uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000
uclinux[mtd]: set ROMfs to be root filesystem
0x000000000000-0x00000019c000 : "ROMfs"
el5329 flash device: 1000000 at 0
el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
0x000001 Chip ID 0x002101
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
0x000000000000-0x000000020000 : "vectors"
0x000000020000-0x000000060000 : "parameters"
0x000000060000-0x000000100000 : "bootloader"
0x000000100000-0x000000700000 : "image"
0x000000700000-0x000001000000 : "user_data"
libphy: fec_enet_mii_bus: probed
TCP: cubic registered
NET: Registered protocol family 17
ROMFS: bad initial checksum on dev romfs.

How do you load the kernel and romfs into RAM?

I use dbug as bootloader and copy image.bin via tftp and then execute from
Power-on Reset
ColdFire MCF532x
Firmware v4a.1a.1b.0100_1616 (Built on Nov 5 2009 15:47:58)
Copyright 2005 Freescale Semiconductor, Inc.
Enter 'help' for help.
dBUG> dn
Downloading Image 'image.bin' from 192.168.10.254
TFTP transfer completed
Read 3228676 bytes (6307 blocks)
dBUG> go 0x40020000

Ok, good, that is pretty standard stuff then.

Are you positive that the romfs is entirely loaded at the address you think

it should be?
Yes I think the romfs is entirely loaded, but I am not sure about the
address. I thought this is calculated in the vendor Makefile
Is that right?
genromfs -v -V "ROMdisk" -f $(ROMFSIMG) -d $(ROMFSDIR)
$(CROSS)objcopy -O binary $(ROOTDIR)/$(LINUXDIR)/linux \
$(IMAGEDIR)/linux.bin
cat $(IMAGEDIR)/linux.bin $(ROMFSIMG) > $(IMAGE)
$(ROOTDIR)/tools/cksum -b -o 2 $(IMAGE) >> $(IMAGE)
[ -n "$(NO_BUILD_INTO_TFTPBOOT)" ] || cp $(IMAGE) /var/lib/tftpboot
[ -n "$(NO_BUILD_INTO_TFTPBOOT)" ] || cp $(ROMFSIMG)
/var/lib/tftpboot
BSS=`$(CROSS)objdump --headers $(ROOTDIR)/$(LINUXDIR)/linux | \
grep .bss` ; \
ADDR=`set -- $${BSS} ; echo 0x$${4}` ; \
$(CROSS)objcopy --add-section=.romfs=$(ROMFSIMG) \
--adjust-section-vma=.romfs=$${ADDR} --no-adjust-warnings \
--set-section-flags=.romfs=alloc,load,data \
$(ROOTDIR)/$(LINUXDIR)/linux $(ELFIMAGE) 2> /dev/null

That looks good. I don't see any problem here.

Regards
Greg

Christian Gieseler

2013-01-23 14:12:00 UTC

Hi Greg,

you find the objdump below.

Regards
Christian

Post by Christian Gieseler
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?

Post by Christian Gieseler
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

Greg Ungerer

2013-01-24 06:56:23 UTC

Hi Christian,

Post by Christian Gieseler
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?

Post by Christian Gieseler
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
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
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

Christian Gieseler

2013-03-04 11:07:12 UTC

Hi Greg,

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?

Regards
Christian

Hi Christian,

Post by Christian Gieseler
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?

Post by Christian Gieseler
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 :-(
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
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

Greg Ungerer

2013-03-05 11:54:39 UTC

Hi Christian,

Post by Christian Gieseler
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

Post by Christian Gieseler
Hi Christian,

Post by Christian Gieseler
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?

Post by Christian Gieseler
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, that looks good too. The romfs start address from you console boot
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

Christian Gieseler

2013-03-05 14:58:35 UTC

Hi Greg,

-----Original Message-----
From: Greg Ungerer [mailto:gregungerer at westnet.com.au]
Sent: Tuesday, March 05, 2013 12:55 PM
To: Christian Gieseler
Cc: 'uClinux development list'
Subject: Re: [uClinux-dev] ROMFS: bad initial checksum
Hi Christian,

Post by Christian Gieseler
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.

Post by Christian Gieseler
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?

The board is derived from the Sentec COBRA5329 Board.

Regards
Greg

Regards
Christian

Christian Gieseler

2013-01-23 14:00:12 UTC

Hi Greg

No, nothing has changed in this area. I have run 3.6 kernels on ColdFire

boards using romfs setups the same as every kernel before.

Can you tell me one example in the 20121024 release that you have
successfully running so that I can maybe have a look at the config.

Regards
Christian

Greg Ungerer

2013-01-24 00:05:44 UTC

Hi Christian,