David Pottage

  • Posts

    26
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

David Pottage's Achievements

  1. How do I firmware packages via armbian-config? I can't see that option in the curses menus. Where is it? Thanks.
  2. We have all seen the recent release announcement of Armbian 21.08 which now includes a beta release of Debian 11 (Bullseye). I have a RockPro64 (Rockchip 3399) that is currently running Debian 10 (Buster) that I would like to upgrade, so that it gets the latest packages from Debian and continues to receive security patches. I am tempted to just upgrade it by editing /etc/apt/sources.list and pulling the latest packages (the debian way), but I wondered if there is a safer way to perform the upgrade. Has anyone else upgraded a Debian based Armbain system that way. Are there any issues to watch out for? What customisations are there in Armbian besides the kernel? How easy would it be to apply those changes after the upgrade? Thanks.
  3. Thanks for that tip. It worked to boot my old 5.4.49 kernel. I then updated the symlinks in /boot to boot the new 5.8.6 kernel, and the boot failed as before. I had saved a copy of the original /boot directory (from the released 20.08 release), I did some more investigation and did a diff between the failing /boot directory and the copy I took. I noticed a difference in /boot/boot.cmd # diff boot/boot.cmd OLD_boot/boot.cmd 6c6 < setenv load_addr "0x9000000" --- > setenv load_addr "0x39000000" 10c10 < setenv verbosity "1" --- > setenv verbosity "7" 12d11 < setenv bootlogo "false" 15c14 < setenv earlycon "off" --- > setenv earlycon "on" 29c28,29 < if test "${bootlogo}" = "true"; then setenv consoleargs "bootsplash.bootfile=bootsplash.armbian ${consoleargs}"; fi --- > # if test "${earlycon}" = "on"; then setenv consoleargs "earlycon=uart,mmio,0xFF1A0000,1500000 ${consoleargs}"; fi > # 2: uart:16550A mmio:0xFF1A0000 irq:38 tx:51 rx:0 RTS|DTR Could the difference in load_addr be the cause of the problems? I have attached the boot log from the successful boots of each kernel. Sucessful kernel 5.8 Jupiter system boot from microSD.txt Sucessful kernel 5.4.49 Jupiter system boot from microSD.txt
  4. I tried booting from my SD card and it did not work. I started with booting the old 5.4.49 kernel, but even that failed. The first time, I reformatted my SD card with an empty ext4 filesystem, and used rsync to copy everything from the eMMC card root file system. When I attempted to boot the 5.4.49 kernel from it, it failed and could not find the root filesystem. I then thought that there might be some magic in the way the files where laid out, so I used GParted to make a binary copy of the eMMC card root file system to the SD card. When that booted, it went into a bootloop with "Synchronous Abort" handler, esr 0x02000000 messages. I have since looked at the logs from GParted, and noticed that it used e2image instead of dd to copy the partion. Could that command have left out something important? Are there any boot blocks or clever bits of file system layout that are used to boot the RockPro64? It looks like a simple copy does not create something bootable I have attached the serial port output from both boot attempts. Boot reset loop.txt Verbose 9 Boot from uSD failed no root FS 5.4.49 kernel.txt
  5. It could. At this point it is unfortunately a mystery to me what the real cause of this issue is. In that case I will give it a try on Sunday evening, and post the results. I will be away until then.
  6. Do you think that the eMMC initialisation could be the source of the problem? If so, then would copying my existing setup to an SD card, and booting from that solve the problem?
  7. OK, I have connected both the SD card and the eMMC, and have booted twice. First from eMMC with the 5.4 kernel, then interupting the boot and using your commands to boot 20.08 from the SD card. The 20.08 image from the SD card had a kernel panic I have attached both boot logs. Verbose 9 Boot to serial kernel panic 5.7.15 with uSD plugged in.txt Verbose 9 Boot to serial good 5.4.49 kernel with uSD plugged in.txt
  8. OK, I can do that. To clarify, I have a system setup to boot from an eMMC. That system runs my home sever, has a fair amount of stuff installed and uses an nvme SSD for most of it's storage. That system boots fine on a 5.4 series kernel, but fails using the upgraded 5.7 or 5.8 series kernels I have downloaded the latest 20.08 release and written it to an SD card. That image has a 5.7 kernel and boots just fine, but it does not have all the software installed, or know anything about the nvme drive.
  9. I have an nvme SSD installed in the PCIe slot. The board boots from an eMMC card.
  10. I tried booting my board using the uInitrd-5.7.15-rockchip64 file from the 20.08 image instead of the generated version that was created when my 5.7.15 kernel got installed. The boot still got stuck in the same way. This suggests that the problem is with the other stuff in my filesystem, rather than the kernel that got supplied in the 5.7.15 kernel package.
  11. Forgot to add the commands to extract the uImage archive tail -c+65 < uInitrd-5.7.15-rockchip64 | gunzip > decomp_uInitrd-5.7.15 mkdir extracted_uInitrd-5.7.15 cd extracted_uInitrd-5.7.15/ cpio -idv < ../decomp_uInitrd-5.7.15
  12. Could there be an issue with the /boot/uInitrd-5.7.15-rockchip64 file? The version in the 20.08 release is 13262336 bytes, but the one that got installed when I upgraded my old system to the 5.7.15 kernel is 15359382 bytes. I know that this is a compressed ram disk image of some sort, so the contents could be the same, but the size difference is suspicious. I have not yet worked out how to list the contents of either file, my google fu is failing at present. Edit: I have worked out how to extract the uInitrd file. The contents are different, but it looks like the file gets generated by a script when the kernel is upgraded as most of the differences are files from my system that have been incorporated into the archive. For example my system has an nvme SSD in the PCIe slot, that is divided into a number of disks using LVM2, so my generated uInitrd file has the contents of /etc/lvm, presumably so the kernel knows how to mount those volumes during boot. The attached screenshot of my diff tool shows the other different files, including some kernel related stuff that could be a source of problems. (Vanilla 20.08 on the left, broken system on the right) Does that help? Should I upload the uInitrd file ?
  13. Sorry. I have edited the offending post to add the missing attachments.
  14. OK, I changed I did that. Still no more output. Using the 5.4.49 kernel, I got lots more output, so the setting works, but it still looks like the 5.7 kernel is broken and fails very early in the startup process. Next I will try a diff between my 20.02.1 based system image (that won't boot a 5.7 kernel) and the new 20.08 based image that does. Any suggestions of where I should be looking ?
  15. Thanks, I will try that in a bit. In the meantime, I took the latest 20.08 image, and flashed it to a new SanDisk SD card, and it booted just fine (Boot log attached) I did a diff between this successful boot, and my unsuccessful boots from an upgraded system, and noticed two differences that could be significant. - Firstly, the unsuccessful boots where from an eMMC card rather than an SD card - Secondly, the build date of U-Boot differs (Feb 17 2020 vs Aug 17 2020) though both report the same version of 2017.09-armbian Could either of those issues be significant ? Edit: Added missing attachments Verbose 9 shutdown to serial good new 5.7.15 kernel from SD card.txt Verbose 9 Boot to serial GOOD new 5.7.15 kernel from SD card.txt