|
Folks, I am seeing a problem that I
can only characterize as a bug with binfmt_flat.c. I am getting corrupted reloc
offsets when decompressing the “init” process in load_flat_file(). Again the
particular setup is a separate boot loader (running in the Microblaze’s BRAM) is
copying the entire Linux image + ROM FS (image.bin) from a FLASH device into
SRAM at address 0x80000000. The boot loader then jumps to 0x80000000 and the
uClinux kernel starts. The uClinux image is linked against this 0x80000000 address.
The kernel boots up to the point of trying to start the init process. load_flat_file()
fails in a call to calc_reloc() when it is determined that the reloc value is
some crazy number, such as 0xb0000000, which is obviously a bad offset. I have
double-checked that the init process is correctly compiled. Anybody have a similar
experience? I am stuck and looking for any and all pointers… Regards, Steve From: Thanks John - that worked. Now onto our next problem. We are having problems loading user applications like init
and sh. The particular error is “BINFMT_FLAT: reloc outside program…” (see below).
We have just updated with *all*
the latest code from the CVS repository. Our particular setup is that we are
(from within our custom bootloader) copying a flat binary image from FLASH to
SRAM and jumping to this image. The SRAM sits at address 0x80000000 and that is
where the image is linked against. Regards, Steve Testing sram... Testing flash...() Writing MAC address... Copying to sram... Jumping to 0x00... Linux version 2.4.31-uc0 (root@vanteon-10-10-55-142) (gcc
version 3.4.1 ( Xilinx EDK 8.1 Build EDK_I.15 290805 )) #42 Fri Oct 28
10:32:29 EDT 2005 On node 0 totalpages: 1024 zone(0): 1024 pages. zone(1): 0 pages. zone(2): 0 pagesªD<6>CPU: MICROBLAZE Kernel command line: Console: xmbserial on UARTLite We have 1 cpu's, and are at local_irq_count=0,
local_bh_count=0 Calibrating delay loop... Past first loop... Past second
loop... 32.76 BogoMIPS Memory: 4MB = 4MB total Memory: 1572KB available (894K code, 1577K data, 44K init) Dentry cache hash table entries: 512 (order: 0, 4096 bytes) Inode cache hash table entries: 512 (order: 0, 4096 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 1024 (order: 0, 4096 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Initializing RT netlink socket Microblaze UARTlite serial driver version 1.00 ttyS0 at 0xfe002000 (irq = 2) is a Microblaze UARTlite Starting kswapd xgpio #0 at 0xFE004000 mapped to 0xFE004000 xgpio #1 at 0xFE007000 mapped to 0xFE007000 Xilinx GPIO registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024
blocksize eth0: using sgDMA mode. eth0: No PHY detected. Assuming a PHY at address 0. eth0: Xilinx EMAC #0 at 0xFE008000 mapped to 0xFE008000,
irq=1 eth0: id 2.0h; block id 7, type 1 uclinux[mtd]: RAM probe address=0x80112e8 size=0x18000 uclinux[mtd]: root filesystem index=0 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 12 buckets, Kbytes TCP: Hash tables configured (established 12 bind 102) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (romfs filesystem) readonly. Freeing init memory: 44K BINFMT_FLAT: reloc outside program 0xec3936c (0 -
0x9ad/0x7e¼), killing init! BINFMT_FLAT: reloc outside program 0xec3936c (0 -
0x9ad/0x7e¼), killing init! BINFMT_FLAT: reloc outside program 0xe`Ð936c (0 -
0x9ad/0x7e¼), killing init! BINFMT_FLAT: reloc outside program 0xec3936c (0 -
0x9ad/0x7e¼), killing init! BINFMT_FLAT: reloc outside program 0xe0c30000 (0 -
0xd144/0xb560), killing sh! BINFMT_FLAT: reloc outside program 0xe0`Ð00œ3 (0 -
0xd144/0xb560), killing sh! Kernel panic: No init found. Try passing init= option to
kernel. -----Original Message----- Hi Steve, > We are attempting to bring up a new board design
using uClinux and > Microblaze. We have made some fair progress but are now stuck with
a BUG > in the kernel at slab.c. We’d provide the exact line but the
printk > function seems to have lost the ability to print integers as well
(we > never touched it!) This BUG seems to rear its ugly head in the > kmem_cache_create() function where it checks if “in_interrupt()”
is > true, which it happens to be. Further tracing has determined that > in_interrupt() is true because the local_bh_count is non-zero. > > Does anybody have a pointer for us? We have
included the limited > output from the kernel as well as the MSS file. Grab the most recent mb-gcc package from my website, do a "make
clean" then try rebuilding. I think this will fix your problem. http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/Toolchain/linux_binaries.html Cheers, John ___________________________ microblaze-uclinux mailing list Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/ |