[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [microblaze-uclinux] Bug with binfmt_flat.c ??? - Really a da ta cache problem

To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: RE: [microblaze-uclinux] Bug with binfmt_flat.c ??? - Really a da ta cache problem
From: "Kapp, Steve" <SKapp@xxxxxxxxxxx>
Date: Mon, 28 Nov 2005 12:07:23 -0500
Reply-to: microblaze-uclinux@xxxxxxxxxxxxxx
Sender: owner-microblaze-uclinux@xxxxxxxxxxxxxx
It turned out to be a problem with the data cache in the Microblaze (core
version 4.0). The instruction cache works just fine - but with the data
cache enabled (by the uClinux machine specific startup code), processes
could not be reliably loaded into memory for execution. 

I understand that under earlier versions of the Microblaze core (3.0?),
this worked just fine. For expediency sake, we disabled the startup code
that turns the data cache on. We left startup code in place that turns on
the instruction cache.

   Steve
 

-----Original Message-----
From: Kapp, Steve [mailto:SKapp@xxxxxxxxxxx] 
Sent: Tuesday, November 01, 2005 7:37 PM
To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: RE: [microblaze-uclinux] Bug with binfmt_flat.c ??? (was Problem
with booting on a new board)

I am building everything under a Fedora 4 installation (albeit running in
VMWare). 

The mb-flthdr utility works just fine, whether or not I have enabled ZFLAT
support in the configuration - it reads/reports on both compressed and
uncompressed user applications. BTW, loading the init process fails in both
cases.

The make output for the init process is shown below.

make[2]: Entering directory `/root/uClinux-dist/user/init'
ucfront-gcc mb-gcc  -Os -g -fomit-frame-pointer -fno-common -fno-builtin -
Wall   -msoft-float -mno-xl-soft-mul -mxl-barrel-shift -mno-xl-soft-div  -
DEMBED -Dlinux -D__linux__ -Dunix -D__uClinux__ -DCONSOLE_BAUD_RATE=115200
-c -o simpleinit.o simpleinit.c
ucfront-gcc mb-gcc  -Wl,-elf2flt -o init simpleinit.o -lcrypt 
cp init simpleinit
ucfront-gcc mb-gcc  -Os -g -fomit-frame-pointer -fno-common -fno-builtin -
Wall   -msoft-float -mno-xl-soft-mul -mxl-barrel-shift -mno-xl-soft-div  -
DEMBED -Dlinux -D__linux__ -Dunix -D__uClinux__ -DCONSOLE_BAUD_RATE=115200
-c -o expand.o expand.c
ucfront-gcc mb-gcc  -Wl,-elf2flt -o expand expand.o 
make[2]: Leaving directory `/root/uClinux-dist/user/init'

I have attached a tgz file to this email containing both the "sh" and the
"init" processes.

Thanks,

   Steve



-----Original Message-----
From: John Williams [mailto:jwilliams@xxxxxxxxxxxxxx] 
Sent: Tuesday, November 01, 2005 5:48 PM
To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: Re: [microblaze-uclinux] Bug with binfmt_flat.c ??? (was Problem
with booting on a new boa rd)

Hi Steve,

I don't believe there are any issues in the binfmt_flat support for
MicroBlaze - that stuff has been stable for ages.  I could be wrong, but
I don't think that's your problem.

Are you building your uClinux apps under Windows/Cygwin, by any chance?
There was a DOS-ism afflicting the elf2flt utility a while back.

Another thing to check, in your uClinux build, cd to romfs/bin, and run
the mb-flthdr utility over the offending application binary.  Does it
all look OK?

Finally, feel free to email your init or sh binary to the list, I'll try
running it here (just tell us what CPU options you've got enabled,
mul/div/shift etc).

Cheers,

John


Kapp, Steve wrote:

> 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:* Kapp, Steve [mailto:SKapp@xxxxxxxxxxx]
> *Sent:* Friday, October 28, 2005 3:43 PM
> *To:* microblaze-uclinux@xxxxxxxxxxxxxx
> *Subject:* RE: [microblaze-uclinux] Problem with booting on a new board
> 
>  
> 
> 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 Swansea University Computer Society NET3.039
> 
> 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-----
> From: John Williams [mailto:jwilliams@xxxxxxxxxxxxxx]
> Sent: Thursday, October 27, 2005 6:50 PM
> To: microblaze-uclinux@xxxxxxxxxxxxxx
> Subject: Re: [microblaze-uclinux] Problem with booting on a new board
> 
>  
> 
> Hi Steve,
> 
>  
> 
> Kapp, Steve wrote:
> 
>  
> 
>>    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
> 
> microblaze-uclinux@xxxxxxxxxxxxxx
> 
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> 
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 


-- 
Dr John Williams, Research Fellow,
Embedded Systems Group / Reconfigurable Computing
School of ITEE, The University of Queensland, Brisbane, Australia
(p) +61 7 33652185  (f) +61 7 33654999 (m) +61 403969243
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-
uclinux/


___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
Prev by Date: [microblaze-uclinux] last line in the console
Next by Date: Re: [microblaze-uclinux] EthernetLite driver
Previous by thread: [microblaze-uclinux] last line in the console
Next by thread: [microblaze-uclinux] Performance with EMAC core
Index(es):
- Date
- Thread