[OpenWrt-Devel] Xilinx Zynq zedboard integration

Thu Mar 12 18:43:11 EDT 2015

Hey!! How long!!!

I have narrowed down the problem to the kernel, as it doesn't even do an
early_printk. I compiled manually the kernel from Xilinx's latest tag, and
substituted it in the SD (leaving the rest of openwrt generated files: fs,
uboot and FSBL), and managed to print some traces till crashing. Therefore,
the problem is the uImage.

John updated kernels a while ago, and I thought that as Xilinx is
submitting patches upstream, maybe there was already enough support
upstream (in one of the latest releases) to avoid a patch. I tested that
but didn't get it working, so I will at the end really need to dissect the
latest Xilinx diff to know the problem.

I haven't been in the kernel world for a long time (and never been good
really) so I will need my time to be able to cleanly divide the patches.
Also, I had thought about the other method, disabling openwrt patches to
find out the problem, but at the end the Xilinx diffs would be needed.

The Xilinx code basically focuses on it's main architectures. Microblaze,
PowerPC and arm now. I could be leaving the microblaze / powerPC out of the
quiz, but I would still need to know what is failing. They have some
driver, as the icap one, and some support for their devices.

If you wish to, I can upload the latest relevant diff I can obtain to
github and we can iterate over it.

On Thu, Mar 12, 2015 at 11:00 PM Roman Yeryomin <leroi.lists at gmail.com>
wrote:

> Hi!
>
> Sorry I was not replying. Was busy changing my day job.
>
> So... your board is configured to use some rsa boot, what is probably
> is some signed image. And u-boot environment is real mess :)
> I suggest you to try configuring to use regular nandboot. AFAIK, you
> can just type nandboot (or whichever storage you use) in u-boot
> console, not changing the environment.
>
> Regards,
> Roman
>
> On 22 January 2015 at 02:55, Javier Domingo Cansino <javierdo1 at gmail.com>
> wrote:
> > Ok, I have narrowed the problem to something with the compilation of the
> > kernel. I think it's more an incompatibility between xilinx and linux
> > patches, because the kernel fails to boot even if build by hand from the
> > build_dir.
> >
> > I will try to split the patch in more digestible parts, and see if I
> catch
> > the error... Or maybe disable the openwrt patches and see where they can
> be
> > colliding.
> >
> > On Wed, Jan 21, 2015 at 1:24 AM, Javier Domingo Cansino
> > <javierdo1 at gmail.com> wrote:
> >>
> >> After hitting against this wall for a lot, I found a bug in my few lines
> >> of code, I was creating the uImage file from vmlinux instead of from
> >> zImage[1].
> >>
> >> I am still doing something wrong, because substituting the uImage
> >> generated from buildroot in the SD card (and leaving the rest of the
> files),
> >> makes at least the kernel boot, although crashes in sec 0.000000, at
> least
> >> prints booting.
> >>
> >> I have discovered that after "Starting kernel ..." there should be a
> >> "Uncompressing Linux... done, booting the kernel." line. So I am still
> doing
> >> something wrong on the uImage generation, and I don't know what.
> >>
> >> Moreover, I have compiled the uImage like the following, and it get's to
> >> the kernel panic at least:
> >> make -j9 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=arm  CROSS_COMPILE="
> >> /home/javier/proyectos/master/master-sce/buildroot/output/
> host/usr/bin/arm-buildroot-linux-uclibcgnueabi-"
> >> LOADADDR="0x8000" uImage
> >>
> >> If you could tell me which should be the Image/BuildKernel part, I would
> >> be really appreciate it.
> >>
> >> target/linux/zynq/image/Makefile
> >> ===
> >>
> >> include $(TOPDIR)/rules.mk
> >> include $(INCLUDE_DIR)/image.mk
> >>
> >> define Build/Compile
> >>      $(call Build/Compile/Default, zynq_zed.dtb)
> >> endef
> >>
> >> define Image/BuildKernel/Initramfs
> >>      (cd $(TARGET_DIR); \
> >>       find . | cpio -o -H newc | gzip -9 >$(KDIR)/zedboard-rootfs.cpio.gz
> )
> >>      mkimage -A arm -T ramdisk -C none -d $(KDIR)/zedboard-rootfs.cpio.gz
> \
> >>       $(BIN_DIR)/zedboard-uramdisk.image.gz
> >> endef
> >>
> >> define Image/BuildKernel
> >>      mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 \
> >>              -n 'ARM OpenWrt Linux-$(LINUX_VERSION)' \
> >>              -d $(LINUX_DIR)/arch/arm/boot/zImage
> $(BIN_DIR)/zedboard-uImage
> >> endef
> >>
> >> define Image/Prepare
> >>      $(LINUX_DIR)/scripts/dtc/dtc -O dtb \
> >>       $(LINUX_DIR)/arch/arm/boot/dts/zynq-zed.dts >
> $(BIN_DIR)/zedboard.dtb
> >> endef
> >>
> >> $(eval $(call BuildImage))
> >>
> >> ===
> >>
> >> [1] Bug I should have found a lot of time ago:
> >> https://github.com/txomon/openwrt/commit/5e882bc2f14580f62a6ad78ddc5703
> 3d207261f9
> >>
> >> Cheers
> >>
> >> On Sun, Jun 29, 2014 at 1:35 PM, Javier Domingo Cansino
> >> <javierdo1 at gmail.com> wrote:
> >>>
> >>> I have manually executed the boot sequence in the uboot, and the result
> >>> is that it fails on the command bootm loados. Any idea on how to debug
> what
> >>> can be wrong?
> >>>
> >>> Cheers and I will keep searching,
> >>>
> >>> Javier Domingo Cansino
> >>>
> >>> zynq-uboot> fatload mmc 0 0x3000000 uImage
> >>> reading uImage
> >>> 4582152 bytes read in 405 ms (10.8 MiB/s)
> >>> zynq-uboot> fatload mmc 0 0x2A00000 devicetree.dtb
> >>> reading devicetree.dtb
> >>> 2739 bytes read in 15 ms (177.7 KiB/s)
> >>> zynq-uboot> fatload mmc 0 0x2000000 uramdisk.image.gz
> >>> reading uramdisk.image.gz
> >>> 796339 bytes read in 87 ms (8.7 MiB/s)
> >>> zynq-uboot> help bootm
> >>> bootm - boot application image from memory
> >>>
> >>> Usage:
> >>> bootm [addr [arg ...]]
> >>>     - boot application image stored in memory
> >>>         passing arguments 'arg ...'; when booting a Linux kernel,
> >>>         'arg' can be the address of an initrd image
> >>>         When booting a Linux kernel which requires a flat device-tree
> >>>         a third argument is required which is the address of the
> >>>         device-tree blob. To boot that kernel without an initrd image,
> >>>         use a '-' for the second argument. If you do not pass a third
> >>>         a bd_info struct will be passed instead
> >>>
> >>> For the new multi component uImage format (FIT) addresses
> >>>         must be extened to include component or configuration unit
> name:
> >>>         addr:<subimg_uname> - direct component image specification
> >>>         addr#<conf_uname>   - configuration specification
> >>>         Use iminfo command to get the list of existing component
> >>>         images and configurations.
> >>>
> >>> Sub-commands to do part of the bootm sequence.  The sub-commands must
> be
> >>> issued in the order below (it's ok to not issue all sub-commands):
> >>>         start [addr [arg ...]]
> >>>         loados  - load OS image
> >>>         ramdisk - relocate initrd, set env initrd_start/initrd_end
> >>>         fdt     - relocate flat device tree
> >>>         cmdline - OS specific command line processing/setup
> >>>         bdt     - OS specific bd_t processing
> >>>         prep    - OS specific prep before relocation or go
> >>>         go      - start OS
> >>> zynq-uboot> bootm start 0x3000000 0x2000000 0x2A00000
> >>> ## Booting kernel from Legacy Image at 03000000 ...
> >>>    Image Name:   ARM OpenWrt Linux-3.13.7
> >>>    Image Type:   ARM Linux Kernel Image (uncompressed)
> >>>    Data Size:    4582088 Bytes = 4.4 MiB
> >>>    Load Address: 80000000
> >>>    Entry Point:  80000000
> >>>    Verifying Checksum ... OK
> >>> ## Loading init Ramdisk from Legacy Image at 02000000 ...
> >>>    Image Name:
> >>>    Image Type:   ARM Linux RAMDisk Image (uncompressed)
> >>>    Data Size:    796275 Bytes = 777.6 KiB
> >>>    Load Address: 00000000
> >>>    Entry Point:  00000000
> >>>    Verifying Checksum ... OK
> >>> ## Flattened Device Tree blob at 02a00000
> >>>    Booting using the fdt blob at 0x2a00000
> >>> zynq-uboot> bootm loados
> >>>    Loading Kernel Image ...
> >>
> >>
> >>
> >>
> >> --
> >> Javier Domingo Cansino
> >
> >
> >
> >
> > --
> > Javier Domingo Cansino
> >
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150312/320503a2/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel