[meta-xilinx] Ethetnet kernel driver depends on U-boot

[andrey]

Hi Sipke,

We were removing features from U-Boot to fit into 192K of the OCM, testing our altrenative to FSBL  boot code generator and network did not work in Linux. We removed network support, these lines:
#define CONFIG_ZYNQ_GEM0
#define CONFIG_ZYNQ_GEM_PHY_ADDR0 0

After that we tried to do the same using fsbl generated by Xilinx tools, u-boot.bin built from u-boot-xlnx(master_next) with the configuration for Microzed we made by modifying Zedboard configs (we could not find the u-boot source for the Microzed). The rest of the files we just took from the image provided for Microzed board. This combination worked for us before, but when we removed the same two configuration parameters, network in Linux stopped working too. Michal Simek already emailed me that there may be still some unintended dependencies of the kernel drivers on the state of the hardware after u-boot (and fsbl). We did not look deeper, just added these two lines back (eating up some of the valuable space in 192KB OCM) and our alternative boot flow worked as well, network in Linux was operational.

Details of our approach are described in README.md of the http://sourceforge.net/p/elphel/ezynq , basically  we are generating register write pairs in RBL header and additional code (including optional debug) called in arch_cpu_init() that allows u-boot to run in OCM, loaded directly by RBL without FSBL. In the future this code can be used in SPL mode if somebody needs more of the u-boot functionality, but it is sufficient to boot Linux already. This program uses many of the CONFIG_* parameters, but they are split into several files - DDR datasheet parameters, Zynq datasheet parameters and the rest (MIO interfaces, clocks, ...) are in the board-specific parameters. The RBL header (later concatenated with u-boot.bin) and C-file to be compiled with u-boot are generated by Python program using /include/autoconf.mk to read the configuration data.

Andrey



---- On Tue, 15 Oct 2013 13:57:08 -0700 Sipke Vriend<sipke.vriend at xilinx.com> wrote ---- 


Hi Andrey, 
 
Xilinx common Linux boot flow is fsbl, u-boot, kernel, so I guess you 
might be seeing a side-effect of reliance on that order. 
If you can pin point in more detail what you have done, or if you 
find a patch to address the issue, you may be could send it or ask on 
git at xilinx.com. 
 
Regards 
Sipke 
 
>From: meta-xilinx-bounces at yoctoproject.org 
>[mailto:meta-xilinx-bounces at yoctoproject.org] On Behalf Of andrey 
>Sent: Saturday, 12 October 2013 7:16 AM 
>To: meta-xilinx at yoctoproject.org 
>Subject: [meta-xilinx] Ethetnet kernel driver depends on U-boot 
> 
>While troubleshooting FSBL-less booting (network did not work initially) 
>we noticed that when we re-enabled network support in U-boot (we 
>removed it to save room in 192KB OCM) - problem was gone and network 
 >in Linux works now. Is the kernel driver really supposed to depend on 
some U-boot initialization of the hardware (why?) or is this just a bug? 
> 
>Andrey 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20131015/eddbcd9a/attachment.html>