[U-Boot] Weird issues with u-boot on Microblaze

[U-Boot] Weird issues with u-boot on Microblaze

[Dana Goyette]

I've been trying to bring up a vanilla kernel on an XUPV5-LX110T board, 
and have been having all sorts of odd issues with U-Boot.  For example, 
if I try to enable FIT image support (as noted on 
http://www.monstr.eu/wiki/doku.php?id=uboot:uboot ), I get 
CONFIG_BOOTMAPSZ undefined.  I've also had to edit image.h to get the 
thing to compile.

image.c: In function ?boot_get_fdt?:

image.c:1510: error: ?bootm_headers_t? has no member named ?fit_hdr_fdt?

image.c:1511: error: ?bootm_headers_t? has no member named ?fit_uname_fdt?

image.c:1512: error: ?bootm_headers_t? has no member named ?fit_noffset_fdt?

the fix:  edit image.h (line 221):
#if defined(CONFIG_OF_LIBFDT) /* WAS: CONFIG_PPC */

If I fix that and try to load a FIT image with a kernel and device-tree, 
the bootm command completely ignores the device tree; unfortunately, I 
don't have a log of this on hand, because now even image loading has 
broken somehow.  For example, fatls ace 0 gives "   131074   \x02.\x02 ", and 
attempting DHCP boot results in a spew of "ARP Retry count exceeded; 
starting again" -- retry count exceeded, despite it never having tried 
even once?

I've attached a log of the console output under both conditions, as well 
as the config.mk and xparameters.h under microblaze_generic; for some 
reason, the given U-Boot BSP assumes 100MHz, despite the board using 
125MHz.  Does anyone have advice for getting u-boot to work on this board?

Thanks in advance for any help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot.log
Type: text/x-log
Size: 3326 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090819/20625d47/attachment.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config.mk
Url: http://lists.denx.de/pipermail/u-boot/attachments/20090819/20625d47/attachment.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xparameters.h
Type: text/x-chdr
Size: 2333 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090819/20625d47/attachment.h 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: microblaze-generic.h
Type: text/x-chdr
Size: 9385 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090819/20625d47/attachment-0001.h 

[U-Boot] Weird issues with u-boot on Microblaze

[Michal Simek]

Hi,

> I've been trying to bring up a vanilla kernel on an XUPV5-LX110T board,
> and have been having all sorts of odd issues with U-Boot.  For example,
> if I try to enable FIT image support (as noted on
> http://www.monstr.eu/wiki/doku.php?id=uboot:uboot ), I get
> CONFIG_BOOTMAPSZ undefined.  I've also had to edit image.h to get the
> thing to compile.
> 
> image.c: In function ?boot_get_fdt?:
> 
> image.c:1510: error: ?bootm_headers_t? has no member named ?fit_hdr_fdt?
> 
> image.c:1511: error: ?bootm_headers_t? has no member named ?fit_uname_fdt?
> 
> image.c:1512: error: ?bootm_headers_t? has no member named
> ?fit_noffset_fdt?
> 
> the fix:  edit image.h (line 221):
> #if defined(CONFIG_OF_LIBFDT) /* WAS: CONFIG_PPC */


FIT support is not in mainline u-boot. Only in my testing repository.

> 
> If I fix that and try to load a FIT image with a kernel and device-tree,
> the bootm command completely ignores the device tree; unfortunately,

Yes the same thing as with FIT. Not in mainline yet. Simple no time. But
I have patches in my tree and I want to send them to next merge open window.



> I
> don't have a log of this on hand, because now even image loading has
> broken somehow.  For example, fatls ace 0 gives "   131074   \x02.\x02 ", and
> attempting DHCP boot results in a spew of "ARP Retry count exceeded;
> starting again" -- retry count exceeded, despite it never having tried
> even once?

I'll test it.


> 
> I've attached a log of the console output under both conditions, as well
> as the config.mk and xparameters.h under microblaze_generic; for some
> reason, the given U-Boot BSP assumes 100MHz, despite the board using
> 125MHz.  Does anyone have advice for getting u-boot to work on this board?
> 

I have fix for u-boot bsp which fix it. The same issue is for uart16550.

I am going to update my git repo at http://git.monstr.eu/git/gitweb.cgi
There will be updated u-boot bsp too.

Thanks,
Michal


> Thanks in advance for any help.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

[U-Boot] Weird issues with u-boot on Microblaze

[Dana Goyette]

Michal Simek wrote:
> Hi,
> 
> 
> 
> FIT support is not in mainline u-boot. Only in my testing repository.
> 
>> If I fix that and try to load a FIT image with a kernel and device-tree,
>> the bootm command completely ignores the device tree; unfortunately,
> 
> Yes the same thing as with FIT. Not in mainline yet. Simple no time. But
> I have patches in my tree and I want to send them to next merge open window.
> 
> 
> 
>> I
>> don't have a log of this on hand, because now even image loading has
>> broken somehow.  For example, fatls ace 0 gives "   131074   \x02.\x02 ", and
>> attempting DHCP boot results in a spew of "ARP Retry count exceeded;
>> starting again" -- retry count exceeded, despite it never having tried
>> even once?
> 
> I'll test it.
> 
> 
>> I've attached a log of the console output under both conditions, as well
>> as the config.mk and xparameters.h under microblaze_generic; for some
>> reason, the given U-Boot BSP assumes 100MHz, despite the board using
>> 125MHz.  Does anyone have advice for getting u-boot to work on this board?
>>
> 
> I have fix for u-boot bsp which fix it. The same issue is for uart16550.
> 
> I am going to update my git repo at http://git.monstr.eu/git/gitweb.cgi
> There will be updated u-boot bsp too.
> 
> Thanks,
> Michal
> 
> 
>> Thanks in advance for any help.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

Thanks for the help!  I cloned your u-boot-microblaze repository, and 
the same fit_hdr_t issues applied; now I'm also working out other 
various issues.  If it would help, I can attach (or send) my project 
file or files, and even an image of the CompactFlash card I am using -- 
it's a 1GB card, with a 100MB fat16 and the rest in ext2.  Oddly enough, 
ext2ls just plain returns silently.

u-boot-microblaze/drivers/mtd/cfi_flash.c:2088: undefined reference to 
`monitor_flash_len'

I've also noticed that the "top" BSP looks in the Xilinx install path 
and the project path, but not the EDK user repository.

Thanks again for the help.

[U-Boot] Weird issues with u-boot on Microblaze

[Michal Simek]

Dana Goyette wrote:
> Michal Simek wrote:
>> Hi,
>>
>>
>>
>> FIT support is not in mainline u-boot. Only in my testing repository.
>>
>>> If I fix that and try to load a FIT image with a kernel and device-tree,
>>> the bootm command completely ignores the device tree; unfortunately,
>> Yes the same thing as with FIT. Not in mainline yet. Simple no time. But
>> I have patches in my tree and I want to send them to next merge open window.
>>
>>
>>
>>> I
>>> don't have a log of this on hand, because now even image loading has
>>> broken somehow.  For example, fatls ace 0 gives "   131074   \x02.\x02 ", and
>>> attempting DHCP boot results in a spew of "ARP Retry count exceeded;
>>> starting again" -- retry count exceeded, despite it never having tried
>>> even once?
>> I'll test it.
>>
>>
>>> I've attached a log of the console output under both conditions, as well
>>> as the config.mk and xparameters.h under microblaze_generic; for some
>>> reason, the given U-Boot BSP assumes 100MHz, despite the board using
>>> 125MHz.  Does anyone have advice for getting u-boot to work on this board?
>>>
>> I have fix for u-boot bsp which fix it. The same issue is for uart16550.
>>
>> I am going to update my git repo at http://git.monstr.eu/git/gitweb.cgi
>> There will be updated u-boot bsp too.
>>
>> Thanks,
>> Michal
>>
>>
>>> Thanks in advance for any help.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>
> 
> Thanks for the help!  I cloned your u-boot-microblaze repository, and 
> the same fit_hdr_t issues applied; now I'm also working out other 
> various issues. 

I have just updated that repo with my latest version. u-boot bsp is updated too. I tested fit some
month ago when was really new thing but I personally not add it to my workflow.
I am compiling generic platform with FIT support but not test it.


 If it would help, I can attach (or send) my project
> file or files, and even an image of the CompactFlash card I am using -- 
> it's a 1GB card, with a 100MB fat16 and the rest in ext2.  Oddly enough, 
> ext2ls just plain returns silently.

If you have edk project, I can take a look or try to generate files.
(If you want send it to me in private email and not to bother u-boot mailing list)
Sorry I don't have a 1GB CF and time to debug it just for fun. I had one project in past
with systemace and CF and I had no problem to list/use both partitions.


> 
> u-boot-microblaze/drivers/mtd/cfi_flash.c:2088: undefined reference to 
> `monitor_flash_len'

this code can't be compiled - you have bad setting. MONITOR_BASE is always on lower address then
FLASH address. Check that your ram on lower address than your flash - this is check by u-boot.bsp too.

> 
> I've also noticed that the "top" BSP looks in the Xilinx install path 
> and the project path, but not the EDK user repository.

top bsp looks at bsp folder in hardware project, then all ModuleSearchPath which
are in xmp files and then take a look to edk patch for standalone bsp.
EDK user repository are in xmp as ModuleSearchPatch and bsp there should be used.


Regards,
Michal



> 
> Thanks again for the help.
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

[U-Boot] Weird issues with u-boot on Microblaze

[Dana Goyette]

Michal Simek wrote:
> 
> this code can't be compiled - you have bad setting. MONITOR_BASE is always on lower address then
> FLASH address. Check that your ram on lower address than your flash - this is check by u-boot.bsp too.
> 
> 
> 
> Regards,
> Michal
> 
> 
> 
> 
> 

Thanks for that help, and thanks for updating your git repository.  I 
had previously forgotten about the "flash must be above RAM" limitation. 
I had forgotten, and had rebuilt the project without re-running the BSP, 
after making the mistake of doing "generate addresses".

I've now rebuild the project and BSP with RAM at 0x10000000 and Flash at 
0x20000000, but I'm now getting a linking error:

u-boot-microblaze/net/eth.c:202: relocation truncated to fit: 
R_MICROBLAZE_32_PCREL_LO against symbol `board_eth_init' defined in text 
section in 
board/xilinx/microblaze-generic/libmicroblaze-generic.a(microblaze-generic.o)

I've looked up the error, and about the closest thing I could find was 
this -- something about "longcall" attribute:

http://www.mail-archive.com/u-boot at lists.denx.de/msg04518.html
http://fixunix.com/vxworks/48336-how-solve-error-relocation-truncated-fit-r_arm_pc24.html

In Microblaze, do the absolute address values matter, or just the 
relative positioning?

I also imagine that perhaps the CompactFlash issues originated from the 
incorrect clock rate.

Thanks again for the help.

[U-Boot] Weird issues with u-boot on Microblaze

[Michal Simek]

Hi,

Dana Goyette wrote:
> Michal Simek wrote:
>> this code can't be compiled - you have bad setting. MONITOR_BASE is always on lower address then
>> FLASH address. Check that your ram on lower address than your flash - this is check by u-boot.bsp too.
>>
>>
>>
>> Regards,
>> Michal
>>
>>
>>
>>
>>
> 
> Thanks for that help, and thanks for updating your git repository.  I 
> had previously forgotten about the "flash must be above RAM" limitation. 
> I had forgotten, and had rebuilt the project without re-running the BSP, 
> after making the mistake of doing "generate addresses".
> 
> I've now rebuild the project and BSP with RAM at 0x10000000 and Flash at 
> 0x20000000, but I'm now getting a linking error:
> 
> u-boot-microblaze/net/eth.c:202: relocation truncated to fit: 
> R_MICROBLAZE_32_PCREL_LO against symbol `board_eth_init' defined in text 
> section in 
> board/xilinx/microblaze-generic/libmicroblaze-generic.a(microblaze-generic.o)

There is problem with weak symbols in toolchain. Simple solution is go to net/eth.c
and comment line with board_eth_init (weak is on the same line). Then you can build
u-boot without any problem.

> 
> I've looked up the error, and about the closest thing I could find was 
> this -- something about "longcall" attribute:

I really don't know - the problem is with toolchain and I think I sent this issue to Xilinx - they
should solve it or you can debug it and find out where the problem is.

> 
> http://www.mail-archive.com/u-boot at lists.denx.de/msg04518.html

it was around ppc

> http://fixunix.com/vxworks/48336-how-solve-error-relocation-truncated-fit-r_arm_pc24.html

Have you tried to compile u-boot with "-mlongcall" or "-mlong-call"?

> 
> In Microblaze, do the absolute address values matter, or just the 
> relative positioning?