Hi Christian,
On 01/23/2013 11:25 PM, Christian Gieseler wrote:
>> -----Original Message-----
>> From: Greg Ungerer [mailto:gregunge...@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,
>>
>> On 01/23/2013 06:45 PM, Christian Gieseler wrote:
>>> 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.
>>> 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.
> Linux version 3.6.0-uc0 (christian@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, g...@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
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
_______________________________________________
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
