10-04-2018 11:42 PM - edited 10-05-2018 05:10 AM
My name is Senna and I am working on a zc702 dev kit.
You're probably tired of reading "Kernel hangs ..." but I've read a lot of posts about it but i couldn't really find the solution for my situation.
The problem now is when i add my applications the the rootfs then it gets stuck. Also when i when i deselect my apps and actually apply a patch to the kernel it also doesnt go past starting kernel..
I have modified xilinx_emacps.c and fixed_phy.c since my board does not have a physical ethernet switch. Then i went and looked in the forums on how to modify the kernel source so i did that. I made a patch file named: 0001-ethernet.patch and put this in the linux-xlnx_%append.bb file under the src files. It compiles and builds but then after i have programmed system.dtb image.ub and BOOT.BIN to the SPI flash memory and i boot it it hangs.
First of all it is really slow? I need to say that also. It takes alot of time to load from flash and i cant remember it taking so long before, but that may be irrelevant.
As i said i wasn't lazy and just posted i actually tried reading the other posts and solutions but i did not find my correct answer. (Or maybe i just overlooked it, in that case im sorry for asking this problem once again :p)
Thanks in advance.
U-Boot 2017.01 (Oct 05 2018 - 06:14:15 +0000) Board: Xilinx Zynq DRAM: ECC disabled 1 GiB MMC: sdhci_transfer_data: Error detected in status(0x208000)! sdhci@e0101000: 0 (eMMC) SF: Detected n25q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id PHY is not detected GEM PHY init failed No ethernet found. U-BOOT for ets-prg Hit any key to stop autoboot: 0 Zynq> sf probe SF: Detected n25q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB Zynq> sf write 0x1000000 0x0 0x500000 device 0 offset 0x0, size 0x500000 SF: 5242880 bytes @ 0x0 Written: OK Zynq> sf write 0x2000000 0x520000 0x50000 device 0 offset 0x520000, size 0x50000 SF: 327680 bytes @ 0x520000 Written: OK Zynq> sf write 0x3000000 0x570000 0x1500000 device 0 offset 0x570000, size 0x1500000 SF: 22020096 bytes @ 0x570000 Written: OK Zynq> boot SF: Detected n25q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB device 0 offset 0x570000, size 0x1500000 SF: 22020096 bytes @ 0x570000 Read: OK ## Loading kernel from FIT Image at 01000000 ... Using 'conf@1' configuration Verifying Hash Integrity ... OK Trying 'kernel@0' kernel subimage Description: Linux Kernel Type: Kernel Image Compression: uncompressed Data Start: 0x010000d4 Data Size: 1992312 Bytes = 1.9 MiB Architecture: ARM OS: Linux Load Address: 0x00008000 Entry Point: 0x00008000 Hash algo: sha1 Hash value: 9e2f32b439080613643ba1347c97a2a00c2c1967 Verifying Hash Integrity ... sha1+ OK ## Loading ramdisk from FIT Image at 01000000 ... Using 'conf@1' configuration Trying 'ramdisk@0' ramdisk subimage Description: ramdisk Type: RAMDisk Image Compression: uncompressed Data Start: 0x011e9eac Data Size: 8524797 Bytes = 8.1 MiB Architecture: ARM OS: Linux Load Address: unavailable Entry Point: unavailable Hash algo: sha1 Hash value: c776313e41b22ba85ebaec5ee0b222a1aaade165 Verifying Hash Integrity ... sha1+ OK ## Loading fdt from FIT Image at 01000000 ... Using 'conf@1' configuration Trying 'fdt@0' fdt subimage Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x011e6840 Data Size: 13753 Bytes = 13.4 KiB Architecture: ARM Hash algo: sha1 Hash value: 8dd3b6d44998f9d3689ec732e7f96e84e7adf973 Verifying Hash Integrity ... sha1+ OK Booting using the fdt blob at 0x11e6840 ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id mdio_register: non unique device name 'eth0' Loading Kernel Image ... OK Loading Ramdisk to 077de000, end 07fff3fd ... OK Loading Device Tree to 077d7000, end 077dd5b8 ... OK Starting kernel ...
10-05-2018 01:23 AM
I had the same a couple of days ago. I found it useful to enable the early debug prints of the kernel, then you'll see more of what is going on.
petalinux-config -c kernel
Kernel hacking -> [*] Kernel low-level debugging functions -> Xilinx zynq Uart1
Kernel hacking -> [*] Early printk
In my case it had something to do with U boot placing the dtb files high up in memory while linux could not reach this. Therefore I decreased the memory in the uboot dtb files.
I'm not sure if this is an accepted way of doing things, but I got through while booting
10-05-2018 01:57 AM
Thank you for your response. The strange thing is that I had a working version on GIT. After seeing that the kernel got stuck I simply started from that GIT commit again. But now that version also hangs at starting kernel....
I'm completly lost...
10-05-2018 02:04 AM
10-05-2018 02:53 AM