[U-Boot] Weird issues with u-boot on Microblaze
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 . ", 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.
# # (C) Copyright 2007-2008 Michal Simek # # Michal SIMEK monstr@monstr.eu # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License as # published by the Free Software Foundation; either version 2 of # the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # # CAUTION: This file is automatically generated by libgen. # Version: Xilinx EDK 10.1.03 EDK_K_SP3.6 # Generate by U-BOOT v4.00.c # Project description at http://www.monstr.eu/uboot/ #
PLATFORM_CPPFLAGS += -mxl-pattern-compare PLATFORM_CPPFLAGS += -mxl-barrel-shift PLATFORM_CPPFLAGS += -mno-xl-soft-div PLATFORM_CPPFLAGS += -mxl-soft-mul PLATFORM_CPPFLAGS += -mcpu=v7.10.d
TEXT_BASE = 0x9ffc0000
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 . ", 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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 . ", 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@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.
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 . ", 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@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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@lists.denx.de/msg04518.html http://fixunix.com/vxworks/48336-how-solve-error-relocation-truncated-fit-r_...
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.
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@lists.denx.de/msg04518.html
it was around ppc
http://fixunix.com/vxworks/48336-how-solve-error-relocation-truncated-fit-r_...
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?
From C code is everything ok - from asm code - you can use absolute and relative addresses.
I also imagine that perhaps the CompactFlash issues originated from the incorrect clock rate.
yes, It could be hw issue.
Regards, Michal
Thanks again for the help.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (2)
-
Dana Goyette -
Michal Simek