I downloaded Armbian 24.2.1 Jammy CLI (Armbian_24.2.1_Orangepizeroplus_jammy_current_6.6.16.img.xz) for the Orange Pi Zero Plus and it's not booting. Boot log below:

U-Boot SPL 2024.01-armbian (Feb 09 2024 - 19:21:37 +0000)
DRAM: 512 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.9(debug):armbian
NOTICE:  BL31: Built : 19:20:27, Feb  9 2024
NOTICE:  BL31: Detected Allwinner H5 SoC (1718)
NOTICE:  BL31: Found U-Boot DTB at 0x20a4ef0, model: Xunlong Orange Pi Zero Plus
INFO:    ARM GICv2 driver initialized
INFO:    Configuring SPC Controller
NOTICE:  PMIC: Assuming H5 reference regulator design
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: cortex_a53: CPU workaround for 1530924 was applied
SCP/INF: Crust v0.6.10000
INFO:    PSCI: Suspend is available via SCPI
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9


U-Boot 2024.01-armbian (Feb 09 2024 - 19:21:37 +0000) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: Xunlong Orange Pi Zero Plus
DRAM:  512 MiB
Core:  67 devices, 20 uclasses, devicetree: separate
WDT:   Not starting watchdog@1c20ca0
MMC:   mmc@1c0f000: 0, mmc@1c10000: 1
Loading Environment from FAT... MMC: no card present
** Bad device specification mmc 0 **
In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Net:   eth0: ethernet@1c30000
MMC: no card present
** Bad device specification mmc 0 **
Couldn't find partition mmc 0
MMC: no card present
** Bad device specification mmc 0 **
Couldn't find partition mmc 0
starting USB...
Bus usb@1c1a000: sun4i_usb_phy phy@1c19400: External vbus detected, not enabling our own vbus
USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
MMC: no card present

Device 0: unknown device
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-02-01-a6-4a-c9-69
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/00000000
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/0000000
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/000000
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/00000
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/0000
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/000
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/00
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/0
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/default-arm-sunxi-sunxi
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/default-arm-sunxi
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/default-arm
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Retrieving file: pxelinux.cfg/default
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Config file not found
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
=> %                                                                             

The screen is connected through spi1 using the ST7789v chip of the LCD. I have successfully configured the screen when the kernel is loaded.

I already have used systemd to display a splashscreen however I find it slow to display something. It display something only after ~12 sec. I could probably reduce that time a bit by loading the service earlier but it would never start in 5 sec.

I have tried unsuccessfully to activate CONFIG_VIDEO_LCD_MODE (VIDEO_LCD_MODE) in u-boot which allow to configure an LCD. It seems that it is not allowed because it depends on !MACH_SUNXI_H3_H5.

How can I configure the output to the LCD via the SPI 1 ?

It seems that u-boot doesn't take in charge spi as a video output. I can see LCD, HDMI, DVI, VGA,... but no SPI. Is it possible to configure the SPI as LCD? Or to send framebuffer to the SPI to display the splashscreen?

Activate the spi-jedec-nor overlay in /boot/armbianEnv.txt :

overlays=spi-jedec-nor
param_spinor_spi_bus=0

Then, after reboot, "cat /proc/mtd" should produce something like this :

dev:    size   erasesize  name
mtd0: 00200000 00001000 "spi0.0"
Here is where it fails - I just get the heading, with no mtd0: 00200000 00001000 "spi0.0".

Should I be using a different param_spinor_spi_bus?

I assume that once that works, the following will work?

apt-get install mtd-utils
 

cat /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/sunxi-spl.bin /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/u-boot.itb > /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/u-boot-sunxi-with-spl.bin

flashcp /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/u-boot-sunxi-with-spl.bin /dev/mtd0

>>>>>>>>

I wired a GPIO Pin to GND. Upon the cmd: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> the program exits immediately with 1 event, although there was never a rising edge due to the fix wire to GND. Is this a feature or a bug, and is it reproducible?

<

Not a feature and not reproducible for me on a Raspberry Pi4 with the setup you describe, so probably a bug specific to your hardware platform, whatever that may be. If it is 100% reproduceable for you, and assuming it is an initialisation issue so you only get the one spurious event, how about using -n2 as a workaround ? Cheers, Kent.

>

It appears 2b reproduceable 100% on my OrangePi zero+ (Allwinner H5) and using -n2 does the trick, but isn't gpiod not supposed to work on all commercial HW platforms and related kernels, rather then only on RPI??

<

gpiod will work on any platform with a supporting kernel. How well depends on the underlying hardware and driver. The RPi4 was merely a counter-example demonstrating that your issue is not universal, using hardware I happen to have readily available. Cheers, Kent.

>

So if I understand you right, gpiod works on sort of a logical level, while the HW dependend part depends of the kernel driver implementation of the specific HW?

<

libgpiod is a userspace library and tools to access GPIO lines via the Linux GPIO character device. The actual interfacing to the hardware is performed by the kernel and appropriate drivers for your hardware. As your problem does not exhibit on other hardware, the root cause of your problem probably lies in the driver for your hardware, not in libgpiod nor the gpiolib subsystem of the kernel. But you would need to debug it further to be sure. Cheers, Kent.

* Event should be more correct than Interrupt.

I made some trial to understand if it is reproduceable, but I have difficulties defining, when it happens. After RESET there is no spurious event. The spurious event appears to happen, when the line was moved:

RESET, gpiomon -r -n1 -Bpull-up 1 6   => No event,  -> pull line up /down, => event (as expected),  gpiomon -r -n1 -Bpull-up 1 6 => false event

There might be an issue w/ pending interrupts, when the line is bouncing when pulled up/down. The 2nd gpiodmon cmd might catch one of the pending interrupts. (Just an idea). This would hint to an initialisation problem, that pending line states are not preempted, before the int is attached.

If I just let the line go up (by pull-up) and leave it "1", I get continuous false events on every gpiomon... cmd, just like "level interrupts"

Kent Gibson and I performed checks independently on our RPIs and we both can confirm that the problem does no occur on the RPI: Linux raspberrypi 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux

armbian-monitor-U.txt

'shutdown -r now' shuts down, won't reboot within 20 minutes. Have to power cycle.

reboot worked initially.

I installed a few bits and firefox. Not sure what triggered it. In other reports I read kernel upgrades.

Could it do a lengthy fsck during boot? 64 GB SD-card/file system.

Would some (red or green) LED shine? It's all dark.