Problems generating the SD card for led-blinker project

[jmonfer]

Hi Pavel, I want to thank you for your great work, it is very useful. In this moment, I’m trying to generate the SD card debian image following the steps that you indicate at led-blinker project web page: 1- make NAME=led_blinker all 2- sudo sh scripts/image.sh scripts/debian.sh red-pitaya-debian-8.11-armhf.img 1024 3- I copy the img file to windows os. Then, using Win32 Disk Imager the SD card is generated.

The Linux virtual machine that I’m using has been created following your instructions.

A minor modification has been done in the Makefile. The line 48 “LINUX_TAR = tmp/linux-$(LINUX_TAG).tar.xz” now is “LINUX_TAR = tmp/linux-$(LINUX_TAG).tar.gz “. Also, in debian.sh file, at several apt-get command calls, the “—allow-unauthenticated” attribute has been added. My last file modification is in debian.sh line 183 where I put my redpitaya fixed eth0 IP address.

When I start the system, the serial console it’s working but the system suffers a kernel panic. I have no experience with operating systems and for these reason I’m not capable of detecting my problem. Your advice regarding this problem will very helpful.

Thank you.

The last serial console lines are:

Starting init: /etc/init exists but couldn't execute it (error -13)
/bin/sh: 0: Can't open earlyprintk
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.101-xilinx #1
Hardware name: Xilinx Zynq Platform
[<c010e3e8>] (unwind_backtrace) from [<c010a624>] (show_stack+0x10/0x14)
[<c010a624>] (show_stack) from [<c0636008>] (dump_stack+0x80/0xa0)
[<c0636008>] (dump_stack) from [<c010d2bc>] (handle_IPI+0xd8/0x174)
[<c010d2bc>] (handle_IPI) from [<c0101420>] (gic_handle_irq+0x84/0x90)
[<c0101420>] (gic_handle_irq) from [<c010b04c>] (__irq_svc+0x6c/0xa8)
Exception stack(0xdc45bf50 to 0xdc45bf98)
bf40:                                     00000000 00000000 1c2d9000 00000000
bf60: dcc1e200 c0a313d0 dcc1e200 00000000 58df76b4 5942dc30 00000000 00000000
bf80: fffffff5 dc45bfa0 c04d1a6c c04d1a94 600f0013 ffffffff
[<c010b04c>] (__irq_svc) from [<c04d1a94>] (cpuidle_enter_state+0xf8/0x1d4)
[<c04d1a94>] (cpuidle_enter_state) from [<c0149264>] (do_idle+0x148/0x1a8)
[<c0149264>] (do_idle) from [<c01493fc>] (cpu_startup_entry+0x18/0x1c)
[<c01493fc>] (cpu_startup_entry) from [<001016cc>] (0x1016cc)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

random: fast init done

[pavel-demin]

Thanks for testing the debian.sh script. I've just tried to reproduce the problem with unmodified version of my scripts. The script runs without any error and the resulting image boots without kernel panic.

[pavel-demin]

I've just uploaded the updated SD card image to dropbox and updated the link in the LED blinker notes.

Here is a direct link to the updated SD card image:

https://www.dropbox.com/sh/5fy49wae6xwxa8a/AADw_EUXcVdXL1TZOj0qV_9qa/red-pitaya-debian-9.9-armhf-20190509.zip?dl=1

[jmonfer]

Thank you Pavel for your efforts and help. This morning I’ve tried your last img file and works perfect. Then, I’ve been trying to follow again all the process using your original files from github. My new generated .img file is still not working. If I compare the boot using your image and my generated one, everything works equally until Starting init process (until "Freeing unused kernel memory: 1024K" ).

I want to generate my own .img file because, if it works, I will generate a new img file with modifications in the device tree.

My intention is to modify your devicetree.patch file line 92 where memory is reserved to “reg=<0x0 0x10000000>”. This is to leave the last DDR3 256Mbytes to be shared with the programmable logic through hp0 and hp1 ports using DMA blocks. At the moment, my problem is generating your img file with your original files. I attach my console output when I run your script: sudo sh scripts/image.sh scripts/debian.sh red-pitaya-debian-9.9-armhf.img 1024

debian_script_output.txt

But, sincerely, I don’t know if the problem is there or in the step before (make NAME=led_blinker all). If you have any idea where the problem could be, it will be very helpful to continue searching for a solution. Thank you again

[pavel-demin]

Thanks for the log file. The following error message doesn't look good:

W: Failure while installing base packages.  This will be re-attempted up to five times.
W: See //debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/init_1.48_armhf.deb is at fault)

Looks like the init_1.48_armhf.deb can't be installed. That's why the Linux kernel can't start the init process and panics.

I've just checked the version of the debootstrap package installed on my Debian 8 machine. Looks like I had to install a more up-to-date version from the jessie-backports repository. I think that it can be done with the following commands:

wget http://archive.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.89~bpo8+1_all.deb
dpkg -i debootstrap_1.0.89~bpo8+1_all.deb

[pavel-demin]

My intention is to modify your devicetree.patch file line 92 where memory is reserved to “reg=<0x0 0x10000000>”. This is to leave the last DDR3 256Mbytes to be shared with the programmable logic through hp0 and hp1 ports using DMA blocks.

I think that zynq-red-pitaya.dts should also be modified. This file is used by u-boot. So, it should be modified before building u-boot.

It's also possible to just rebuild devicetree.dtb and boot.bin and copy them to a pre-built SD card image. The commands to rebuild devicetree.dtb, u-boot and boot.bin are

rm -rf devicetree.dtb tmp/led_blinker.tree 
make devicetree.dtb

rm -rf boot.bin tmp/u-boot.elf tmp/u-boot-xlnx-xilinx-v2018.3  
make boot.bin

[jmonfer]

Now everything is working. .img file is generated perfectly, and redpitaya linux boots without any problems.

Also, I’ve generated the device tree and u-boot performing the modifications as you recommend me. Everything worked as expected, the logic has written 256Mbytes on DDR3 of known values using a simple verilog designed module and the linux appears to read the values without any problem.

Thank you again for your advice. It has been very helpful