search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.79k stars 494 forks source link

ROCK Pi S | UART0 does not show any output and login prompt #5972

Closed Keridos closed 1 year ago

Keridos commented 1 year ago

Creating a bug report/issue

Required Information

Steps to reproduce

  1. Flash this image on SD Card: https://dietpi.com/downloads/images/DietPi_ROCKPiS-ARMv8-Bullseye.7z
  2. Insert it and try to boot

Expected behaviour

Actual behaviour

Extra details

MichaIng commented 1 year ago

Thanks for reporting. This is bad. Have you tested a different SD card?

Hmm might be also a specific hardware revision being generally affected: https://forum.armbian.com/topic/24345-unbootable-images-only-old-image-i-am-using-seems-to-work/

If a different SD card does not make a difference, eMMC could be tested. And since there were some updates in the meantime, the new images after DietPi v8.12 release could be tested.

MichaIng commented 1 year ago

I just triggered a new build: https://github.com/MichaIng/DietPi/actions/runs/3675747049 Will have latest kernel and bootloader. One finished (in 30 Minutes or so), you can download it from here: https://dietpi.com/downloads/images/testing/

Keridos commented 1 year ago

Thanks for the quick reply. Tested it, still no blue light flashing or activity with it. Will again attempt to retrieve some sort of serial output from it.

No serial output from DietPi, the original radxa image shows the kernel boot messages per serial. Log can be seen here: https://gist.github.com/Keridos/1a2f51bd57b60b251204a9a8ee5da88e

It seems as if the dietpi image has something on it that makes it fail even before uboot is started.

I also investigated the images. The offical radxa image has a fat16 boot partition while dietpi only has the one ext4 partition with all files on it. Maybe the bootloader of the rock pi S cannot directly boot from ext4?

agoldcheidt commented 1 year ago

Hi @Keridos, I've just installed and run DietPi v8.11.2 under my Rock Pi S v12 without an issue. I've similar specs like yours but I have a RPI power supply (2,1A). I believe the power supply on your end may be causing the issue. If you have another one and try it.

Keridos commented 1 year ago

Hi @Keridos, I've just installed and run DietPi v8.11.2 under my Rock Pi S v12 without an issue. I've similar specs like yours but I have a RPI power supply (2,1A). I believe the power supply on your end may be causing the issue. If you have another one and try it.

I tested it with 5 different power supplys / computers as usb power source, 2 Rock Pi S and 2 SD cards. also the vanilla radxa image works properly. Does your Rock Pi S have the extra SD NAND by any chance? Mine do have that and that might also be a cause of that issue.

agoldcheidt commented 1 year ago

Does your Rock Pi S have the extra SD NAND by any chance?

No, mine doesn't have SD NAND. I remember a configuration of the "MASKROM button" in ARMBIAN Rock Pi S website. It may give you a lead.

Keridos commented 1 year ago

Additional Info: Arbmian bullseye seems to have the same problem. If you use that image as a base it may be an upstream issue.

MichaIng commented 1 year ago

We can try to find the last working build of the Armbian bootloader and set this on hold on the image.

Could both of you share the hardware revision info of your ROCK Pi S, likely printed onto the PCB?

Keridos commented 1 year ago

We can try to find the last working build of the Armbian bootloader and set this on hold on the image.

Could both of you share the hardware revision info of your ROCK Pi S, likely printed onto the PCB?

Update: It seems Kernel 4.4 images seem to work, but Kernel 5.7+ Images do not work. Note I only did a binary search from armbian archive to see this so it might not be entirely correct.

Latest working image:Armbian_20.08.1_Rockpi-s_buster_legacy_4.4.228_minimal.img.xz First non working image: Armbian_20.08_Rockpi-s_buster_current_5.7.15_minimal.img.xz

Update 2: I also wrote a comment in this thread you linked (might still need to be approved though):

Hmm might be also a specific hardware revision being generally affected: https://forum.armbian.com/topic/24345-unbootable-images-only-old-image-i-am-using-seems-to-work/

My three Rock Pi S are: Rock Pi S v1.2 2019001U

image

agoldcheidt commented 1 year ago

We can try to find the last working build of the Armbian bootloader and set this on hold on the image.

Could both of you share the hardware revision info of your ROCK Pi S, likely printed onto the PCB?

Hi there, my board says: Rock Pi S v1.2 20190910

image

MichaIng commented 1 year ago

Update 2: I also wrote a comment in this thread you linked (might still need to be approved though):

Try to avoid cross-references on Armbian forum, they do not like us to forward bug reports or our users to their forum, regardless whether it is related to DietPi specifics or not. So don't expect a friendly response.

So in your case it's no mainline kernel image working, but legacy vendor kernel image only, i.e. not related to a recent change. Both of you have v1.2 20190910. @StephanStS you have v1.3 If I remember right? However, revision doesn't seen to be the issue either. Left is onboard storage. Might there be some OS or at least bootloader stored on it which is used with priority instead of the intended U-Boot shipped with our image? @Keridos have you tried to hit the MASKROM button while powering on?

Keridos commented 1 year ago

Yes have tried booting with the maskrom button pressed. Did not work on either of my Rock pi S On Wed, Jan 4, 2023 at 05:10, MichaIng @.***> wrote:

Update 2: I also wrote a comment in this thread you linked (might still need to be approved though):

StephanStS commented 1 year ago

@StephanStS you have v1.3 If I remember right?

Yes, I have 2 of them with v1.3.

MichaIng commented 1 year ago

Last idea I have is to format the onboard NAND or flash the DietPi image to onboard NAND.

Marsu31 commented 1 year ago

Hi,

Same problem with RockPi S v13. Below the console output. The boot process freezes at step kernel starting.

dietpi-serial-console-output.txt

For information, the latest Armbian image is working fine (Armbian 22.11 Bullseye, Kernel 6.0.y, Size: 412Mb, Release date: Dec 23, 2022).

Next step I will try to put Armbian on NAND and run dietpi-installer...

Regards

MichaIng commented 1 year ago 
ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0)
   Loading Device Tree to 000000001d441000, end 000000001d451165 ... OK

How much RAM does your ROCK Pi S have? Same question to everyone with boot issues. If I see it correctly, it writes the device tree up to closely 500 MiB, which cannot work with 256 MiB RAM. Also with 512 MiB it is at least close. Looks like we need to adjust the RAM addresses in our /boot/boot.cmd. I'll check whether Armbian did the same for their recent images.

Marsu31 commented 1 year ago 
ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0)
   Loading Device Tree to 000000001d441000, end 000000001d451165 ... OK

How much RAM does your ROCK Pi S have? Same question to everyone with boot issues. If I see it correctly, it writes the device tree up to closely 500 MiB, which cannot work with 256 MiB RAM. Also with 512 MiB it is at least close. Looks like we need to adjust the RAM addresses in our /boot/boot.cmd. I'll check whether Armbian did the same for their recent images.

512MB This error is also present with Armbian image. So, I don't think this is the problem.

MichaIng commented 1 year ago

Okay, still might be an issue. But you're right, it even says ... OK. Not sure what the error says exactly then.

Armbian's image uses the "edge" kernel, while we use the "current" kernel. Since "edge" means very frequent updates and even less tested builds, I'm not keen to ship this with our image, but instead leave it solving itself once the branches rotate so that "edge" becomes "current". But I can build an "edge" kernel based image just to assure this really is the only issue.

Marsu31 commented 1 year ago

I give you the output for Armbian image. I quickly compared the 2 outputs but I don't understand the signification of the differences... armbian-serial-console-output.txt

Marsu31 commented 1 year ago

Okay, still might be an issue. But you're right, it even says ... OK. Not sure what the error says exactly then.

Armbian's image uses the "edge" kernel, while we use the "current" kernel. Since "edge" means very frequent updates and even less tested builds, I'm not keen to ship this with our image, but instead leave it solving itself once the branches rotate so that "edge" becomes "current". But I can build an "edge" kernel based image just to assure this really is the only issue.

I can be your beta tester if you need one :wink:

MichaIng commented 1 year ago

Looks like "edge" U-Boot is actually an older U-Boot: 2022.04 vs 2022.07 😄. Everything else is exactly the same, with the little difference that Armbian tries to load some device tree overlays by default, which seems to fail, and loading the fixup.scr file fails as well. Can you check on the Armbian image:

cat /boot/armbianEnv.txt

However, all not boot-relevant.

Marsu31 commented 1 year ago

[...] Can you check on the Armbian image:

cat /boot/armbianEnv.txt
verbosity=1
extraargs=swiotlb=1024
overlay_prefix=rk3308
fdtfile=rockchip/rk3308-rock-pi-s.dtb
rootdev=UUID=042ab219-dbd2-40b0-b9f5-b88bf10b12f3
rootfstype=ext4
console=serial
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
MichaIng commented 1 year ago

Ah I was wrong: The fixup is called if applying overlays does not fail. In your case its only called if applying overlays succeed (hence it must be attempted). Still not relevant for the actual issue 😄.

Btw, still trying to figure out why it works in Stephan's case but not in yours. You have a V1.3 PCB version with onboard NAND as well, right?

MichaIng commented 1 year ago

Build is in progress: https://github.com/MichaIng/DietPi/actions/runs/3979803789 Will be available here in ~30 minutes: https://dietpi.com/downloads/images/testing/

Marsu31 commented 1 year ago

Ah I was wrong: The fixup is called if applying overlays does not fail. In your case its only called if applying overlays succeed (hence it must be attempted). Still not relevant for the actual issue smile.

Btw, still trying to figure out why it works in Stephan's case but not in yours. You have a V1.3 PCB version with onboard NAND as well, right?

Yes, v1.3 and 8GB NAND

Marsu31 commented 1 year ago

Build is in progress: https://github.com/MichaIng/DietPi/actions/runs/3979803789 Will be available here in ~30 minutes: https://dietpi.com/downloads/images/testing/

It doesn't seem better :cry: dietpi-testing-01-serial-console-output.txt

MichaIng commented 1 year ago

What the hack, the bootloader and kernel are now exactly the same. I need to carefully compare the boot configs then.

One thing I was recognising, but not sure what it is:

MichaIng commented 1 year ago

I have guess: We simply use the wrong serial console device for passing boot output, so the image does actually boot, but you just don't see it as fast as the kernel is loaded. Please try to replace ttyS2 with ttyS0 in /boot/dietpiEnv.txt.

Marsu31 commented 1 year ago

I have guess: We simply use the wrong serial console device for passing boot output, so the image does actually boot, but you just don't see it as fast as the kernel is loaded. Please try to replace ttyS2 with ttyS0 in /boot/dietpiEnv.txt.

Nice job :wink:, with the testing image :

Starting kernel ...

[    0.000000] OF: fdt: Reserved memory: failed to reserve memory for node 'drm-logo@00000000': base 0x0000000000000000, size 0 MiB
[    0.058659] thermal_sys: Failed to find 'trips' node
[    1.809530] mmc0: error -110 whilst initialising SD card
[    1.981706] mmc0: error -110 whilst initialising SD card
[    2.165331] mmc0: error -110 whilst initialising SD card
[    2.367726] mmc0: error -110 whilst initialising SD card
[    2.847658] rk_gmac-dwmac ff4e0000.ethernet: Can not read property: tx_delay.
[    2.848341] rk_gmac-dwmac ff4e0000.ethernet: set tx_delay to 0x30
[    2.849565] rk_gmac-dwmac ff4e0000.ethernet: Can not read property: rx_delay.
[    2.850290] rk_gmac-dwmac ff4e0000.ethernet: set rx_delay to 0x10

Debian GNU/Linux 11 DietPi ttyS0

DietPi login:

I will give a try to a NAND installation now. Thank you :clap:

MichaIng commented 1 year ago

Debian GNU/Linux 11 DietPi ttyS0

DietPi login:

Great, that was easy 😄.

I will give a try to a NAND installation now.

I'm currently doing the same here. Nasty that this cannot be done form the ROCK Pi S itself when booted from SD card. Flashing the bootloader worked well, flashing our image currently takes ages. No progress shown by rkdeveloptool, so not sure whether it's stuck 🤔.

Fixed this along with disabling the obsolete TTY1, used only if a screen is attached, while this is a headless device. I also enabled device tree overlay prefix for the "edge" kernel, while it is not in use for the "current" kernel yet. There current generic rockchip64 overlays do not work anyway, the edge kernel does adds 3 for old kernel versions (don't ask me why they are shipped with a new kernel package...) and one which allows lower voltage and higher clock rates for V1.3 PCB version, quite nice: https://github.com/MichaIng/DietPi/commit/09f2546

MichaIng commented 1 year ago

Worked well now to write stuff to NAND. I think I broke it last attempt by attaching the serial console, in preparation for testing the ttyS0 vs ttyS2 topic 😄. However, it does not boot.

Btw, the nand-sata-install tool is now called armbian-install: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/armbian-install

Interestingly there obviously was a way to flash the NAND right from an SD card booted system, but this doesn't seem to work anymore: https://forum.radxa.com/t/boot-of-3rd-part-image-from-sd-nand/3665/10?u=michaing

Marsu31 commented 1 year ago

I can't write to NAND. I'm unable to get maskrom mode anymore. :sob:

MichaIng commented 1 year ago

How is that? Remove the SD card, keep the maskrom button pressed, hit reset button (or attach power), release the maskrom button after ~2 seconds. lsusb then shows the maskrom device.

Strange thing that Radxa has Windows mentioned in their docs, but no instructions or a download for the rkdeveloptool. I have a Windows binary from FriendlyELEC, which detects the ROCK Pi S as well, but is unable to flash anything, or I fail to understand how it works 😄.

Marsu31 commented 1 year ago

How is that? Remove the SD card, keep the maskrom button pressed, hit reset button (or attach power), release the maskrom button after ~2 seconds. lsusb then shows the maskrom device.

I did that many times... It doesn't work. Nothing with lsusb nor with rkdeveloptool ld. It is as if the maskrom button does nothing.

Strange thing that Radxa has Windows mentioned in their docs, but no instructions or a download for the rkdeveloptool. I have a Windows binary from FriendlyELEC, which detects the ROCK Pi S as well, but is unable to flash anything, or I fail to understand how it works smile.

I compile it from the source. Need to edit one file to avoid make errot : https://github.com/rockchip-linux/rkdeveloptool/issues/80#issuecomment-1399570435.

MichaIng commented 1 year ago

It is as if the maskrom button does nothing.

Hum, that is bad. Hopefully no hardware issue. Try it as well on another host system to check whether any USB device is showing up. E.g. Windows recognises it as well. If this is the case, it is the host system's issue, not the ROCK Pi S.

And also check kernel messages:

dmesg | tail -10

It shows when a USB device is detected, attached/detached, has issues, etc. See my orgy here:

[  873.874368] usb 1-2: new high-speed USB device number 25 using xhci_hcd
[  874.059894] usb 1-2: New USB device found, idVendor=2207, idProduct=330e, bcdDevice= 1.00
[  874.059910] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  906.706894] usb 1-2: USB disconnect, device number 25
[  907.926518] usb 1-2: new high-speed USB device number 26 using xhci_hcd
[  908.186434] usb 1-2: New USB device found, idVendor=2207, idProduct=330e, bcdDevice= 1.00
[  908.186459] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  908.186473] usb 1-2: Product: USB-MSC
[  908.186483] usb 1-2: Manufacturer: RockChip
[  908.186493] usb 1-2: SerialNumber: rockchip
[  946.474135] usb 1-3: new high-speed USB device number 27 using xhci_hcd
[  946.660925] usb 1-3: New USB device found, idVendor=2207, idProduct=330e, bcdDevice= 1.00
[  946.660949] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  946.674567] usb 1-2: USB disconnect, device number 26
[  970.226499] usb 1-3: USB disconnect, device number 27
[  976.330192] usb 1-1: USB disconnect, device number 24
[  988.870459] usb 1-1: new high-speed USB device number 28 using xhci_hcd
[  989.059323] usb 1-1: New USB device found, idVendor=2207, idProduct=330e, bcdDevice= 1.00
[  989.059332] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1030.279107] usb 1-1: USB disconnect, device number 28
[ 5762.526355] loop: module loaded
[ 5762.527384] loop0: detected capacity change from 0 to 1421152
[ 5774.596315] EXT4-fs (loop0p1): mounted filesystem with ordered data mode. Quota mode: none.
[ 6695.558184] EXT4-fs (loop0p1): unmounting filesystem.
[ 8827.329631] usb 1-1: new high-speed USB device number 29 using xhci_hcd
[ 8827.518961] usb 1-1: New USB device found, idVendor=2207, idProduct=330e, bcdDevice= 1.00
[ 8827.518984] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 8865.592164] usb 1-1: USB disconnect, device number 29
MichaIng commented 1 year ago

Very strange. In my case, as long as the ROCK Pi S is attached to my PC, it is like it stays in maskrom mode, even when not hitting the button, so the opposite way round. However, also powering it via regular PSU does not work. Tested with edge kernel/bootloader as well, the same Armbian uses for their image. The green LED keeps lid, hence it does not really start a kernel.

Testing with Radxa Debian image now. Probably my device has no NAND and rkdeveltool somehow successfully connects and writes to nowhere 😄.

Marsu31 commented 1 year ago

I tried under Windows, same symptoms. I fear the hardware issue. ~May be the Radxa could help me : https://forum.radxa.com/t/maskrom-doesnt-work-anymore/14279~ edit: message deleted from the radxa forum

Keridos commented 1 year ago

Is the blue flickering LED which show when the board is supposed to be "active" flickering on your boards?

Marsu31 commented 1 year ago

Is the blue flickering LED which show when the board is supposed to be "active" flickering on your boards?

Only the green led is on.

Keridos commented 1 year ago

Is the blue flickering LED which show when the board is supposed to be "active" flickering on your boards?

Only the green led is on.

Interesting. I do not know what the blue led corresponds to. But for me it correlated to "the rock pi s was able to connect to my ethernet".

/edit: got my Rock Pi S v1.2 w/o NAND and trying the new testing image on it now.

MichaIng commented 1 year ago

The green LED shows only the power state, the blue LED is start blinking on system activity once the kernel has been loaded. So yes, if blue LED is blinking, it basically booted successfully.

I think my ROCK Pi S has no NAND. @StephanStS probably you can verify.

rkdeveltool

Flash Size: 0MB. Just strange that it connects at all and while it fails to flash on Windows with "Prepare IDB Fail", it succeeds in Linux, writing the whole image in a minute or so with percentage counting up. Pretty strange if would do that without any actual flash present 😄.

Keridos commented 1 year ago

rkdeveloptool seems to be stuck when downloading the bootloader on my machine.

You can see if there is flash on the board though, if there is a smaller square chip (8x8mm approx) next to the usb port.

/source: I have Rock Pi S with and without NAND flash.

MichaIng commented 1 year ago

It looks like this (not original photo): https://znoxx.me/2020/01/30/rockpi-s/rockpi1.jpg

SoC, RAM and WiFi. I checked illustration and photos online and the only difference I could see is missing WiFi, or additional 4-pin header beside the Ethernet port exposed.

Or is it at the bottom side? I didn't take it off the case yet.

Marsu31 commented 1 year ago

I have to apologize. My brain was tired. It needed the nightly reset to found the answer. I tried to activate maskrom with usb/ttl cable instead of usb/usb. I'm very confused. You can delete my noise on this thread. :confounded:

MichaIng commented 1 year ago

Ah okay, no problem 😄. Would be still interesting to know whether you are able to flash the image to NAND and boot from it. I'm still not 100% sure whether my board has a NAND chip (and I'm failing to flash it) or not 😅.

MichaIng commented 1 year ago

Another topic: I tested the "edge" kernel and it has quite some enhancements:

I cannot imagine that it takes long for next rotation of this kernel branches, but still considering to ship our images with "edge" until this is done. Its just nasty that users then need to change back to "current" manually after the rotation, to be back on a less experimental version. We can do this on DietPi update as well, but it's always a little risk and move back and forth. What do you think?

Marsu31 commented 1 year ago

Ah okay, no problem smile. Would be still interesting to know whether you are able to flash the image to NAND and boot from it. I'm still not 100% sure whether my board has a NAND chip (and I'm failing to flash it) or not sweat_smile.

Here is the NAND :wink: Under USB port, on the other face of course.

I'm waiting for the 8.14 release which will ship your changes (mainly ttyS2 => ttyS0). I don't know how to build myself the rockpis image from your dev branch. I have tried to edit the current image. I flashed it but I ran into a boot problem and fell in initramfs shell. :disappointed:

I cannot imagine that it takes long for next rotation of this kernel branches, but still considering to ship our images with "edge" until this is done. Its just nasty that users then need to change back to "current" manually after the rotation, to be back on a less experimental version. We can do this on DietPi update as well, but it's always a little risk and move back and forth. What do you think?

For my part I'm not in a hurry :stuck_out_tongue_winking_eye: and these improvements can wait. I use DietPi for its lightness, this is my priority. If I wanted a more up-to-date distri I would tune it by myself.

MichaIng commented 1 year ago

I'm waiting for the 8.14 release which will ship your changes (mainly ttyS2 => ttyS0).

I uploaded images with these changes already. Just download from our website. Only the "current" => "dev" kernel switch is not implied, but that one is applied here: https://dietpi.com/downloads/images/testing/

Marsu31 commented 1 year ago

I thought it was the version before changing the tty... I didn't look at the upload time. I flashed it and it works very fine. :clap:

MichaIng commented 1 year ago

Okay great. I'll mark this issue as closed then. PR for switching to "edge" kernel is still up. I'll let it sink in and decide in a few days.