Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
AFAIR, Xilinx code is pretty clean and after you merge all their patches they are not so big/bad in the end. I did it for a custom board before but I doubt I could remember what code did cause problems and what didn't by just looking at it because it was few years ago. And things may have changed over the time too. If I would have the hw I think I could bake OpenWrt support for it in a week or so. Anybody feels like donating a zedboard? :) Regards, Roman On 13 March 2015 at 00:43, Javier Domingo Cansino javier...@gmail.com wrote: 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.li...@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 javier...@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 javier...@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.00, 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:
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
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 javier...@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 javier...@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.00, 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/5e882bc2f14580f62a6ad78ddc57033d207261f9 Cheers On Sun, Jun 29, 2014 at 1:35 PM, Javier Domingo Cansino javier...@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 0x300 uImage reading uImage 4582152 bytes read in 405 ms (10.8 MiB/s) zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb reading devicetree.dtb 2739 bytes read in 15 ms (177.7 KiB/s) zynq-uboot fatload mmc 0 0x200 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
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
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.li...@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 javier...@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 javier...@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.00, 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 javier...@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 0x300 uImage reading uImage 4582152 bytes read in 405 ms (10.8 MiB/s) zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb reading devicetree.dtb
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
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.00, 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/5e882bc2f14580f62a6ad78ddc57033d207261f9 Cheers On Sun, Jun 29, 2014 at 1:35 PM, Javier Domingo Cansino javier...@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 0x300 uImage reading uImage 4582152 bytes read in 405 ms (10.8 MiB/s) zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb reading devicetree.dtb 2739 bytes read in 15 ms (177.7 KiB/s) zynq-uboot fatload mmc 0 0x200 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 0x300 0x200 0x2A0 ## Booting kernel from Legacy Image at 0300 ... Image Name: ARM OpenWrt Linux-3.13.7 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4582088 Bytes = 4.4 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:796275 Bytes = 777.6 KiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 02a0 Booting using the fdt blob at 0x2a0 zynq-uboot bootm loados Loading Kernel Image ... -- Javier Domingo Cansino ___ openwrt-devel mailing list
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
I am still stuck on this. I think that the failing point here is the kernel image load, but the loading in the part of uboot. Javier Domingo Cansino ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
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 0x300 uImage reading uImage 4582152 bytes read in 405 ms (10.8 MiB/s) zynq-uboot fatload mmc 0 0x2A0 devicetree.dtb reading devicetree.dtb 2739 bytes read in 15 ms (177.7 KiB/s) zynq-uboot fatload mmc 0 0x200 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 0x300 0x200 0x2A0 ## Booting kernel from Legacy Image at 0300 ... Image Name: ARM OpenWrt Linux-3.13.7 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4582088 Bytes = 4.4 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:796275 Bytes = 777.6 KiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 02a0 Booting using the fdt blob at 0x2a0 zynq-uboot bootm loados Loading Kernel Image ... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
I have found that I was compiling u-boot with a wrong config. Anyway, I have advanced now till the next challenge. same output as before, but now: ## Flattened Device Tree blob at 02a0 Booting using the fdt blob at 0x2a0 Loading Kernel Image ... OK Loading Ramdisk to 1fa6d000, end 1fb2f649 ... OK Loading Device Tree to 1fa69000, end 1fa6cab2 ... OK Starting kernel ... So I suppose now there is really something wrong with the kernel. I have repeated the steps by hand, and now it stops printing after the Starting kernel ... line. I have enabled early_prinks, and all those things I have been said to. May it be due to the kernel not printing to the right device? Is there any way to check that? Javier Domingo Cansino ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Zynq zedboard integration
Hi, I have tried the buildroot build, and have its output. Still no idea on what I am doing wrong though... I think it's something with the way I have packaged the kernel, but still not coming up with the problem... --- My failing output In:serial Out: serial Err: serial Net: Gem.e000b000 Hit any key to stop autoboot: 0 Device: zynq_sdhci Manufacturer ID: 27 OEM: 5048 Name: SD04G Tran Speed: 5000 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 3.7 GiB Bus Width: 4-bit reading uEnv.txt ** Unable to read file uEnv.txt ** Copying Linux from SD to RAM... reading uImage 4582152 bytes read in 443 ms (9.9 MiB/s) reading devicetree.dtb 2739 bytes read in 15 ms (177.7 KiB/s) reading uramdisk.image.gz 796339 bytes read in 89 ms (8.5 MiB/s) ## Booting kernel from Legacy Image at 0300 ... Image Name: ARM OpenWrt Linux-3.13.7 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4582088 Bytes = 4.4 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:796275 Bytes = 777.6 KiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 02a0 Booting using the fdt blob at 0x2a0 Loading Kernel Image ... --- Buildroot working output Device: zynq_sdhci Manufacturer ID: 27 OEM: 5048 Name: SD04G Tran Speed: 5000 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 3.7 GiB Bus Width: 4-bit reading uEnv.txt ** Unable to read file uEnv.txt ** Copying Linux from SD to RAM... reading uImage 3593344 bytes read in 349 ms (9.8 MiB/s) reading devicetree.dtb 7400 bytes read in 16 ms (451.2 KiB/s) reading uramdisk.image.gz 937093 bytes read in 101 ms (8.8 MiB/s) ## Booting kernel from Legacy Image at 0300 ... Image Name: Linux-3.13.0-xilinx Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3593280 Bytes = 3.4 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:937029 Bytes = 915.1 KiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 02a0 Booting using the fdt blob at 0x2a0 Loading Kernel Image ... OK Loading Ramdisk to 1fa4a000, end 1fb2ec45 ... OK Loading Device Tree to 1fa45000, end 1fa49ce7 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.13.0-xilinx (javier@theoden) (gcc version 4.7.3 (Buildroot 2014.05-dirty) ) #1 SMP PREEMPT Sun Jun 1 15:28:49 CEST 2014 [0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Xilinx Zynq [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writealloc [0.00] PERCPU: Embedded 8 pages/cpu @c1037000 s10688 r8192 d13888 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyPS0,115200 root=/dev/ram rw earlyprintk [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 506264K/524288K available (4865K kernel code, 310K rwdata, 1708K rodata, 198K init, 5345K bss, 18024K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0673818 (6575 kB) [0.00] .init : 0xc0674000 - 0xc06a59c0 ( 199 kB) [0.00] .data : 0xc06a6000 - 0xc06f3ad0 ( 311 kB) [0.00].bss : 0xc06f3adc - 0xc0c2c1b0 (5346 kB) Javier Domingo Cansino ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
