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