[OS] Debian Bullseye (11) N2/N2L

[meveric]

before the update:

Code: Select all

root@odroid-bullseye64:/boot/dtbs/6.1.0-arm64# tree
.
├── amlogic
│   ├── meson64_odroidn2_plus.dtb
│   └── odroidn2
│       ├── fanspeed-full.dtbo
│       ├── hktft35.dtbo
│       ├── i2c0.dtbo
│       ├── i2c1.dtbo
│       ├── pps-gpio_p11.dtbo
│       ├── pps-gpio_p12.dtbo
│       ├── pwm_cd.dtbo
│       ├── pwm_ef.dtbo
│       ├── pwmfan-lowtemp.dtbo
│       ├── spi0.dtbo
│       ├── sx865x-i2c1.dtbo
│       ├── uart0.dtbo
│       ├── uart1.dtbo
│       ├── w1-gpio_p15.dtbo
│       └── w1-gpio_p22.dtbo
└── meson64_odroidn2_plus.dtb -> amlogic/meson64_odroidn2_plus.dtb

after the update:

Code: Select all

root@odroid-bullseye64:/boot/dtbs/6.1.0-arm64# tree
.
├── amlogic
│   ├── meson64_odroidn2_plus.dtb
│   └── odroidn2
│       ├── fanspeed-full.dtbo
│       ├── hktft35.dtbo
│       ├── i2c0.dtbo
│       ├── i2c1.dtbo
│       ├── pps-gpio_p11.dtbo
│       ├── pps-gpio_p12.dtbo
│       ├── pwm_cd.dtbo
│       ├── pwm_ef.dtbo
│       ├── pwmfan-lowtemp.dtbo
│       ├── spi0.dtbo
│       ├── sx865x-i2c1.dtbo
│       ├── uart0.dtbo
│       ├── uart1.dtbo
│       ├── w1-gpio_p15.dtbo
│       └── w1-gpio_p22.dtbo
├── meson64_odroidn2_plus.dtb -> amlogic/meson64_odroidn2_plus.dtb
└── overlays
    └── amlogic
        └── odroidn2
            ├── fanspeed-full.dtbo
            ├── hktft35.dtbo
            ├── i2c0.dtbo
            ├── i2c1.dtbo
            ├── pps-gpio_p11.dtbo
            ├── pps-gpio_p12.dtbo
            ├── pwm_cd.dtbo
            ├── pwm_ef.dtbo
            ├── pwmfan-lowtemp.dtbo
            ├── spi0.dtbo
            ├── sx865x-i2c1.dtbo
            ├── uart0.dtbo
            ├── uart1.dtbo
            ├── w1-gpio_p15.dtbo
            └── w1-gpio_p22.dtbo

checking i2c without overlay:

Code: Select all

root@odroid-bullseye64:~# ll /dev/i2c*
crw------- 1 root root 89, 2 Aug  7 15:25 /dev/i2c-2

checking i2c with overlay i2c0 i2c1:

Code: Select all

root@odroid-bullseye64:/boot/dtbs/6.1.0-arm64# ll /dev/i2c*
crw------- 1 root root 89, 0 Aug  7 15:25 /dev/i2c-0
crw------- 1 root root 89, 1 Aug  7 15:25 /dev/i2c-1
crw------- 1 root root 89, 2 Aug  7 15:25 /dev/i2c-2

loading i2c0 i2c1 and w1-gpio_p15 overlays

Code: Select all

root@odroid-bullseye64:~# cat /sys/kernel/debug/gpio 
gpiochip1: GPIOs 1948-1962, parent: platform/ff800000.sys-ctrl:pinctrl@14, aobus-banks:
 gpio-1950 (                    |enable              ) out lo 
 gpio-1956 (                    |regulator-tflash_vdd) out hi 
 gpio-1957 (                    |TF_IO               ) out hi 
 gpio-1958 (                    |pwm                 ) out lo 
 gpio-1959 (                    |n2:blue             ) out lo 

gpiochip0: GPIOs 1963-2047, parent: platform/ff634400.bus:pinctrl@40, periphs-banks:
 gpio-1978 (                    |PHY reset           ) out hi ACTIVE LOW
 gpio-1984 (                    |regulator-hub_5v    ) out hi 
 gpio-1985 (                    |regulator-usb_pwr_en) out lo 
 gpio-1987 (                    |regulator-vcc_5v    ) out hi 
 gpio-2000 (                    |reset               ) out hi ACTIVE LOW
 gpio-2010 (                    |cd                  ) in  lo ACTIVE LOW
 gpio-2012 (PIN_44              )
 gpio-2013 (PIN_46              )
 gpio-2014 (PIN_45              )
 gpio-2015 (PIN_47              )
 gpio-2016 (PIN_26              )
 gpio-2023 (PIN_42              )
 gpio-2024 (PIN_32              )
 gpio-2025 (PIN_7               )
 gpio-2026 (PIN_27              )
 gpio-2027 (PIN_28              )
 gpio-2028 (PIN_16              )
 gpio-2029 (PIN_18              )
 gpio-2030 (PIN_22              )
 gpio-2031 (PIN_11              )
 gpio-2032 (PIN_13              )
 gpio-2033 (PIN_33              )
 gpio-2034 (PIN_35              )
 gpio-2035 (PIN_15              |onewire             ) out hi 
 gpio-2036 (PIN_19              )
 gpio-2037 (PIN_21              )
 gpio-2038 (PIN_24              )
 gpio-2039 (PIN_23              )
 gpio-2040 (PIN_8               )
 gpio-2041 (PIN_10              )
 gpio-2042 (PIN_29              )
 gpio-2043 (PIN_31              )
 gpio-2044 (PIN_12              )
 gpio-2045 (PIN_3               )
 gpio-2046 (PIN_5               )
 gpio-2047 (PIN_36              )

so seems to work perfectly fine.
Most likely your "onewire.dtbo" file does not work or you have it in the wrong location (please note the path for the overlays changed)

[Moan]

Hmmm... Thank you for the outputs.

Something is really strange for me then.

in config.ini I have got:

Code: Select all

fk_overlays=i2c0 i2c1 w1-gpio_p15

Code: Select all

root@odroidn2:~# ll /dev/i2c*
crw-rw---- 1 root i2c 89, 2 Aug  7 15:25 /dev/i2c-2

Code: Select all

root@odroidn2:~# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 1948-1962, parent: platform/ff800000.sys-ctrl:pinctrl@14, aobus-banks:
 gpio-1950 (                    |enable              ) out lo
 gpio-1956 (                    |regulator-tflash_vdd) out hi
 gpio-1957 (                    |TF_IO               ) out lo
 gpio-1958 (                    |pwm                 ) out lo
 gpio-1959 (                    |n2:blue             ) out lo

gpiochip0: GPIOs 1963-2047, parent: platform/ff634400.bus:pinctrl@40, periphs-banks:
 gpio-1978 (                    |PHY reset           ) out lo ACTIVE LOW
 gpio-1984 (                    |regulator-hub_5v    ) out hi
 gpio-1985 (                    |regulator-usb_pwr_en) out lo
 gpio-1987 (                    |regulator-vcc_5v    ) out hi
 gpio-2000 (                    |reset               ) out hi ACTIVE LOW
 gpio-2010 (                    |cd                  ) in  hi ACTIVE LOW
 gpio-2012 (PIN_44              )
 gpio-2013 (PIN_46              )
 gpio-2014 (PIN_45              )
 gpio-2015 (PIN_47              )
 gpio-2016 (PIN_26              )
 gpio-2023 (PIN_42              )
 gpio-2024 (PIN_32              )
 gpio-2025 (PIN_7               )
 gpio-2026 (PIN_27              )
 gpio-2027 (PIN_28              )
 gpio-2028 (PIN_16              )
 gpio-2029 (PIN_18              )
 gpio-2030 (PIN_22              )
 gpio-2031 (PIN_11              )
 gpio-2032 (PIN_13              )
 gpio-2033 (PIN_33              )
 gpio-2034 (PIN_35              )
 gpio-2035 (PIN_15              )
 gpio-2036 (PIN_19              )
 gpio-2037 (PIN_21              )
 gpio-2038 (PIN_24              )
 gpio-2039 (PIN_23              )
 gpio-2040 (PIN_8               )
 gpio-2041 (PIN_10              )
 gpio-2042 (PIN_29              )
 gpio-2043 (PIN_31              )
 gpio-2044 (PIN_12              )
 gpio-2045 (PIN_3               )
 gpio-2046 (PIN_5               )
 gpio-2047 (PIN_36              )

Code: Select all

root@odroidn2:/boot/dtbs/6.1.0-arm64# tree
.
├── amlogic
│   ├── meson-g12b-odroid-n2-plus.dtb
│   ├── meson-g12b-odroid-n2.dtb
│   ├── meson-g12b-odroid-n2l.dtb
│   ├── meson-gxbb-odroidc2.dtb
│   ├── meson-sm1-odroid-c4.dtb
│   ├── meson-sm1-odroid-hc4.dtb
│   ├── meson64_odroidc2.dtb
│   ├── meson64_odroidc4.dtb
│   ├── meson64_odroidhc4.dtb
│   ├── meson64_odroidn2.dtb
│   ├── meson64_odroidn2_plus.dtb
│   ├── meson64_odroidn2l.dtb
│   └── overlays
│       ├── odroidc4
│       │   ├── display_vu7c.dtbo
│       │   ├── hifishield2.dtbo
│       │   ├── hktft32.dtbo
│       │   ├── hktft35.dtbo
│       │   ├── i2c0.dtbo
│       │   ├── i2c1.dtbo
│       │   ├── pcf8563.dtbo
│       │   ├── pps-gpio_p11.dtbo
│       │   ├── pps-gpio_p12.dtbo
│       │   ├── spi0.dtbo
│       │   ├── sx865x-i2c1.dtbo
│       │   ├── uart0.dtbo
│       │   ├── uart1.dtbo
│       │   ├── uart2.dtbo
│       │   ├── uart3.dtbo
│       │   ├── w1-gpio_p15.dtbo
│       │   └── w1-gpio_p22.dtbo
│       └── odroidn2
│           ├── fanspeed-full.dtbo
│           ├── hktft35.dtbo
│           ├── i2c0.dtbo
│           ├── i2c1.dtbo
│           ├── pps-gpio_p11.dtbo
│           ├── pps-gpio_p12.dtbo
│           ├── pwm_cd.dtbo
│           ├── pwm_ef.dtbo
│           ├── pwmfan-lowtemp.dtbo
│           ├── spi0.dtbo
│           ├── sx865x-i2c1.dtbo
│           ├── uart0.dtbo
│           ├── uart1.dtbo
│           ├── w1-gpio_p15.dtbo
│           └── w1-gpio_p22.dtbo
├── meson64_odroidn2.dtb -> amlogic/meson64_odroidn2.dtb
├── overlays
│   └── amlogic
│       └── odroidn2
│           ├── fanspeed-full.dtbo
│           ├── hktft35.dtbo
│           ├── i2c0.dtbo
│           ├── i2c1.dtbo
│           ├── pps-gpio_p11.dtbo
│           ├── pps-gpio_p12.dtbo
│           ├── pwm_cd.dtbo
│           ├── pwm_ef.dtbo
│           ├── pwmfan-lowtemp.dtbo
│           ├── spi0.dtbo
│           ├── sx865x-i2c1.dtbo
│           ├── uart0.dtbo
│           ├── uart1.dtbo
│           ├── w1-gpio_p15.dtbo
│           └── w1-gpio_p22.dtbo
├── rk3399-odroid-n1.dtb -> rockchip/rk3399-odroid-n1.dtb
└── rockchip
    ├── overlays
    │   ├── odroidm1
    │   │   ├── i2c0.dtbo
    │   │   ├── i2c1.dtbo
    │   │   ├── onewire.dtbo
    │   │   ├── pwm1.dtbo
    │   │   ├── pwm2.dtbo
    │   │   ├── pwm9.dtbo
    │   │   ├── spi0.dtbo
    │   │   ├── uart0-with-ctsrts.dtbo
    │   │   ├── uart0.dtbo
    │   │   └── uart1.dtbo
    │   ├── rockchip-dwc3-0-host.dtbo
    │   ├── rockchip-i2c7.dtbo
    │   ├── rockchip-i2c8.dtbo
    │   ├── rockchip-pcie-gen2.dtbo
    │   ├── rockchip-rk3328-opp-1.4ghz.dtbo
    │   ├── rockchip-rk3328-opp-1.5ghz.dtbo
    │   ├── rockchip-rk3399-opp-2ghz.dtbo
    │   ├── rockchip-spi-jedec-nor.dtbo
    │   ├── rockchip-spi-spidev.dtbo
    │   ├── rockchip-uart4.dtbo
    │   └── rockchip-w1-gpio.dtbo
    ├── rk3326-odroid-go2.dtb
    ├── rk3399-odroid-n1.dtb
    └── rk3568-odroid-m1.dtb

I have Odroid N2 (non Plus version). Maybe some issue with ${variant} testing in boot.scr?

I wonder if it's because I'm using SPI (petitboot) to start the OS? I would love to test it on the micro SD card, but my slot fully died

So in the SPI mode, it uses the old uboot from 2015 to start the OS on USB? Or it uses the newest uboot from that USB after the OS is selected in petitboot? Still strange.

I would very appreciate if somebody tested in a free while how it behaves when booting from USB. At least I would know if there's something wrong on my side, or just a bad side of booting from USB.

EDIT: My tree output seems to differ a bit?

[tobetter]

in config.ini I have got:

Code: Select all

fk_overlays=i2c0 i2c1 w1-gpio_p15

I doubt fk_overlays whether it works in boot script, probably overlays. Can you try?

[Moan]

in config.ini I have got:

Code: Select all

fk_overlays=i2c0 i2c1 w1-gpio_p15

I doubt fk_overlays whether it works in boot script, probably overlays. Can you try?

Yeah, I tried it before having the same "hope", but it's for sure used in the boot.scr: https://pastebin.com/raw/XuT4NRnb

Code: Select all

setenv load_overlays_cmd 'fdt addr ${fdt_addr_r}; for overlay in ${fk_overlays}; do run load_overlay_cmd; done'

And recommended by @meveric e.g. in this post.

[tobetter]

in config.ini I have got:

Code: Select all

fk_overlays=i2c0 i2c1 w1-gpio_p15

I doubt fk_overlays whether it works in boot script, probably overlays. Can you try?

Yeah, I tried it before having the same "hope", but it's for sure used in the boot.scr: https://pastebin.com/raw/XuT4NRnb

Code: Select all

setenv load_overlays_cmd 'fdt addr ${fdt_addr_r}; for overlay in ${fk_overlays}; do run load_overlay_cmd; done'

And recommended by @meveric e.g. in this post.

Ok, then I doubt the image is not compatible with Petitboot. Can you share your boot.scr as well as config.ini so I can check?

[Moan]

Ok, then I doubt the image is not compatible with Petitboot. Can you share your boot.scr as well as config.ini so I can check?

Sure, thank you for always helping me. Here it is: mega.nz.

On that day, this thing updated for me: /var/log/apt/history.log

Start-Date: 2023-01-12 01:15:47
Commandline: apt upgrade
Upgrade: setup-odroid:arm64 (0.0.1-77, 0.0.1-78)
End-Date: 2023-01-12 01:15:53

[tobetter]

@moan, I think I found a solution after some testing to support DTB with Petitboot and this is the change in the boot script.

The change is attached and this must be applied to /boot/boot.scr after booting through Petitboot, but please do back up the file before modifying such that you won't reinstall the OS. The change is attached,

Code: Select all

dd if=/boot/boot.scr of=boot.cmd bs=72 skip=1
patch -p1 < boot.cmd.txt
mkimage -T script -C none -A arm64 -d boot.cmd /boot/boot.scr
reboot

@meveric, please review the changes attached and it allows to load device tree overlay files via Petitboot. The problem is caused by unknown environment variables in boot.scr - "soc" / "board" / "fdtoverlay_addr_r", they are undefined environment variables in Hardkernel's stock U-Boot (v2015). Also the device tree path should be fixed to amlogic/overlays. Please share your thoughts.

[meveric]

The first part with checking for petitboot is fine, sadly the older u-boot do not provide any board identifier as more modern u-boot do, so setting the soc identifier for them is probably necessary.
I'm not a big fan of setting a fixed address setenv fdtoverlay_addr_r "0x01000000"
This is what should come from the u-boot as you can easily overwrite other memory registers like this.
Even the old u-boot for N2L for example provides most of these addresses ready to use:

Code: Select all

bootlogo_addr=0x1080000
cramfsaddr=0x20000000
dtb_mem_addr=0x1000000
fb_addr=0x3d800000
fdt_addr_r=0x1000000
kernel_addr_r=0x1080000
loadaddr=0x1080000
preloadaddr=0x4000000
pxefile_addr_r=0x1070000
ramdisk_addr_r=0x3080000

In worst case you should be able to re-use loadaddr/scriptaddr after loading the config file.

but I checked the upstream u-boot for N2 and C4 and the address matches so I guess it's fine to use this as a workaround.

As the board variable is currently only used in case of meson boards, this should be part of the part of the petitboot workaround.

The paths for the overlays are correct and should not be touched.
I use a script that copies the overlays from /usr/lib/linux-image-<kernel-version>/ to /boot/dtbs/<kernel-version>/overlays/ as I also do this for RockChip boards as well.

I will take over the changes to my boot script for arm64 boards.

[tobetter]

The first part with checking for petitboot is fine, sadly the older u-boot do not provide any board identifier as more modern u-boot do, so setting the soc identifier for them is probably necessary.
I'm not a big fan of setting a fixed address setenv fdtoverlay_addr_r "0x01000000"
This is what should come from the u-boot as you can easily overwrite other memory registers like this.
Even the old u-boot for N2L for example provides most of these addresses ready to use:

Code: Select all

bootlogo_addr=0x1080000
cramfsaddr=0x20000000
dtb_mem_addr=0x1000000
fb_addr=0x3d800000
fdt_addr_r=0x1000000
kernel_addr_r=0x1080000
loadaddr=0x1080000
preloadaddr=0x4000000
pxefile_addr_r=0x1070000
ramdisk_addr_r=0x3080000

In worst case you should be able to re-use loadaddr/scriptaddr after loading the config file.
but I checked the upstream u-boot for N2 and C4 and the address matches so I guess it's fine to use this as a workaround.

The value is from your U-Boot, so the address should be ok since Petitboot does not use the address value but use the symbol.

As the board variable is currently only used in case of meson boards, this should be part of the part of the petitboot workaround.

Agree, small complication is the value of "variant" but can be managed.

The paths for the overlays are correct and should not be touched.
I use a script that copies the overlays from /usr/lib/linux-image-<kernel-version>/ to /boot/dtbs/<kernel-version>/overlays/ as I also do this for RockChip boards as well.

I will take over the changes to my boot script for arm64 boards.

Petitboot itself does not matter whether it's amlogic/overlays or overlays/amlogic if a target file exists. I found the device tree file under dtbs/6.1.0-arm64/<amlogic|rockchip>/overlays in your Debian image Debian-Bullseye64-1.5-20221220-N2.img.

So I will see how the variables soc, board, fdtoverlay_addr_r can be managed in Petitboot but specifically the value of board should be odroid-${variant} if you agree.

Thank you for your feedback.

[Moan]

Thank you @tobetter.

It worked, but I had to change one thing:

boot.cmd_moan.txt

(1.23 KiB) Downloaded 7 times

Generally, it still needs to be the previous overlays path:

Code: Select all

-    if test "$board" = "odroid-n2"; then
-        setenv overlaypath "overlays/amlogic/odroidn2"
+    if test "${board}" = "odroid-n2"; then
+        setenv overlaypath "overlays/amlogic/odroidn2"

It's because @meveric has recently updated images to fix the issue, so it's not exactly the same as in un-apt-upgraded Debian-Bullseye64-1.5-20221220-N2.img. Without this change it still refused to load.

But yes, seems like I can now list i2c and onewire. The other part of the story is that neither weatherboard nor DS18B20 work, but I guess I can just try loading my old overlay for onewire, or see if the pin differs. Important part is that overlays loaded

[tobetter]

Thank you @tobetter.

It worked, but I had to change one thing:

boot.cmd_moan.txt

Generally, it still needs to be the previous overlays path:

Code: Select all

-    if test "$board" = "odroid-n2"; then
-        setenv overlaypath "overlays/amlogic/odroidn2"
+    if test "${board}" = "odroid-n2"; then
+        setenv overlaypath "overlays/amlogic/odroidn2"

Glad to know you fixed it.

It's because @meveric has recently updated images to fix the issue, so it's not exactly the same as in un-apt-upgraded Debian-Bullseye64-1.5-20221220-N2.img. Without this change it still refused to load.

Thank you, I think I misunderstand this so @mevric point me out not to change the path...so it's his decision. Anyway, if the path is correct, it will work.

But yes, seems like I can now list i2c and onewire. The other part of the story is that neither weatherboard nor DS18B20 work, but I guess I can just try loading my old overlay for onewire, or see if the pin differs. Important part is that overlays loaded

Good to know...please let us know how the device works for you.

[Moan]

Good to know...please let us know how the device works for you.

Everything works good

I use i2c2mqtt to read bme280 (Weather Board 2 data). I had to edit file: bme280.py and change:

Code: Select all

bus = smbus.SMBus(1)

to

Code: Select all

bus = smbus.SMBus(0)

For some reasons that tool doesn't support this as the command line argument, but doesn't really matter. I probably could also change some pin on board itself.
So at the end I'm using:

crontab -e:

Code: Select all

* * * * * /home/moan/moan_monitor_mqtt_sensor.sh &

Code: Select all

#!/bin/bash

script_name=$(basename -- "$0")

if pidof -x "$script_name" -o $$ >/dev/null;then
   echo "Already running in the background!"
   exit 0
fi

while :
do
	python3.9 /home/moan/i2c2mqtt/i2c2mqtt/i2c2mqtt.py -d bme280 -t moan/bme280
	sleep 20
done

For onewire, it was also super easy to fix. The onewire.dtbo file that I had to use on armbian used a different onewire PIN 19 (spi_a_mosi/GPIOX_8(#)).
For this one, I changed to PIN 15 (pwm_b/PWM_F/GPIOX_7(#)) and everything started working with default .dtbo files:

Code: Select all

fk_overlays=i2c0 i2c1 w1-gpio_p15

Also the recent kernel update to 6.1.6 seems to fix some other minor issues like shutdown now freeze. So at the moment I'm extremely happy with this image. Using USB with NVMe drive, newest Debian, newest kernel, Weather board works, onewire works. I even use the 2.5Gb/s Ethernet adapter and I get 2.3Gb/s writing / ~1.3 to 1.6Gb/s read speed from N2 as the NAS. Nothing else needed to be happy

[Moan]

Hmm... One more thing.

I am not able to use UAS for my external HDDs (WD Element / WD My Book).
The uas module is getting loaded on boot and everything, but connected USB disks are always Driver=usb-storage.

Even reconnecting them while the OS is running doesn't help.

Code: Select all

                |__ Port 1: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
                |__ Port 4: Dev 11, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
                |__ Port 2: Dev 14, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
                |__ Port 3: Dev 13, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

Code: Select all

# lsusb -v -d 1058:25ee | grep -i interface
can't get debug descriptor: Resource temporarily unavailable
    bNumInterfaces          1
    Interface Descriptor:
      bInterfaceNumber        0
can't get debug descriptor: Resource temporarily unavailable
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
    bNumInterfaces          1
    Interface Descriptor:
      bInterfaceNumber        0
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
    bNumInterfaces          1
    Interface Descriptor:
      bInterfaceNumber        0
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0

syslog:

Code: Select all

Jan 19 12:49:44 odroidn2 kernel: [ 4205.096863] usb 2-1.3.2.2: new SuperSpeed USB device number 14 using xhci-hcd
Jan 19 12:49:44 odroidn2 kernel: [ 4205.125926] usb 2-1.3.2.2: New USB device found, idVendor=1058, idProduct=25ee, bcdDevice=40.04
Jan 19 12:49:44 odroidn2 kernel: [ 4205.132635] usb 2-1.3.2.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Jan 19 12:49:44 odroidn2 kernel: [ 4205.140232] usb 2-1.3.2.2: Product: My Book 25EE
Jan 19 12:49:44 odroidn2 kernel: [ 4205.144799] usb 2-1.3.2.2: Manufacturer: Western Digital
Jan 19 12:49:44 odroidn2 kernel: [ 4205.150066] usb 2-1.3.2.2: SerialNumber: X
Jan 19 12:49:44 odroidn2 kernel: [ 4205.156910] usb-storage 2-1.3.2.2:1.0: USB Mass Storage device detected
Jan 19 12:49:44 odroidn2 kernel: [ 4205.163012] scsi host4: usb-storage 2-1.3.2.2:1.0
Jan 19 12:49:45 odroidn2 kernel: [ 4205.876727] .
Jan 19 12:49:45 odroidn2 kernel: [ 4206.197526] scsi 4:0:0:0: Direct-Access     WD       My Book 25EE     4004 PQ: 0 ANSI: 6
Jan 19 12:49:45 odroidn2 kernel: [ 4206.208486] sd 4:0:0:0: Attached scsi generic sg6 type 0
Jan 19 12:49:45 odroidn2 kernel: [ 4206.212169] sd 4:0:0:0: [sde] Spinning up disk...

Any idea what can I try to force load it?

[tobetter]

Hmm... One more thing.

I am not able to use UAS for my external HDDs (WD Element / WD My Book).
The uas module is getting loaded on boot and everything, but connected USB disks are always Driver=usb-storage.

I think it's because of this change.
viewtopic.php?p=363676#p363676

[Moan]

Hmm... One more thing.

I am not able to use UAS for my external HDDs (WD Element / WD My Book).
The uas module is getting loaded on boot and everything, but connected USB disks are always Driver=usb-storage.

I think it's because of this change.
viewtopic.php?p=363676#p363676

Thanks! These WD Disks have a different device ID than the ones I used in quirks. So they should still load with UAS? Or I need to add them in petitboot and change ":u" to something else?

EDIT:

I think these hard drives don't support UAS, and some sources on the Internet are misleading:

The lsusb -v command only shows:

Code: Select all

bInterfaceProtocol     80 Bulk-Only

and from what I read it should additionally be: "bInterfaceProtocol 98".

So at this point I think these drivers just won't work in uas. Would be nice if someone else who has WD My Book or WD Elements confirmed it.

[meveric]

@moan, I think I found a solution after some testing to support DTB with Petitboot and this is the change in the boot script.

The change is attached and this must be applied to /boot/boot.scr after booting through Petitboot, but please do back up the file before modifying such that you won't reinstall the OS. The change is attached,

Code: Select all

dd if=/boot/boot.scr of=boot.cmd bs=72 skip=1
patch -p1 < boot.cmd.txt
mkimage -T script -C none -A arm64 -d boot.cmd /boot/boot.scr
reboot

@meveric, please review the changes attached and it allows to load device tree overlay files via Petitboot. The problem is caused by unknown environment variables in boot.scr - "soc" / "board" / "fdtoverlay_addr_r", they are undefined environment variables in Hardkernel's stock U-Boot (v2015). Also the device tree path should be fixed to amlogic/overlays. Please share your thoughts.

So I reviewed the changes again and this is the current diff I have.

Code: Select all

@@ -38,6 +38,23 @@
   setenv maxcpus "maxcpus=${maxcpus}"
 fi
 
+# Workaround if no overlay address exists (should work for all boards)
+if test -z "${fdtoverlay_addr_r}"; then
+  setenv fdtoverlay_addr_r ${scriptaddr}
+fi
+
+# legacy u-boot workaround
+# old u-boot in petitboot may not provide board information, but still provides variants
+if test -z "${soc}"; then
+  if test "${variant}" = "n2" -o "${variant}" = "n2_plus" -o "${variant}" = "n2-plus"; then
+    setenv soc "meson"
+    setenv board "odroid-n2"
+  elif test "${variant}" = "c4" -o "${variant}" = "hc4"; then
+    setenv soc "meson"
+    setenv board "odroid-c4"
+  fi
+fi
+
 # different console for AmLogic devices
 if test "${soc}" = "meson"; then
   setenv console "ttyAML0,115200n8"
@@ -45,12 +62,12 @@
   # C4/N2 only
   if test -n "${variant}"; then
     echo "variant ${variant}"
-    if test "$variant" = "n2-plus"; then
+    if test "${variant}" = "n2-plus"; then
         setenv variant "n2_plus"
     fi
-    if test "$board" = "odroid-n2"; then
+    if test "${board}" = "odroid-n2"; then
         setenv overlaypath "overlays/amlogic/odroidn2"
-    else
+    elif test "${board}" = "odroid-c4"; then
         setenv overlaypath "overlays/amlogic/odroidc4"
     fi
     setenv fdtfile "amlogic/meson64_odroid${variant}.dtb"
@@ -60,12 +77,9 @@
 fi
 if test "${soc}" = "rk3399"; then
     setenv overlaypath "overlays"
-    if test -z "${fdtoverlay_addr_r}"; then
-        setenv fdtoverlay_addr_r ${scriptaddr}
-    fi
 fi

I got rid of if test -z "${petitboot,autoboot}"; then completely as this is a problem with the u-boot itself and not petitboot alone.
Also this statement was probably wrong to begin with and should have been if test -n "${petitboot,autoboot}"; then instead, else it would only have worked if petitboot,autoboot was not set, but it only is set in the old u-boot.
Rather than testing for petitboot, I went for testing if the soc environment is set or not and if not and it's one of the N2/C4 variants we set the values required accordingly.
This might even work correctly if someone prefers to use the old u-boot but the new image, even without using petitboot.

Code: Select all

if test -z "${board}"; then
  setenv board "odroid-${variant}"
fi

this was also incorrect as it would set the board to things like odroid-n2_plus or odroid-n2l or odroid-hc4 and I only want to know which board it is so I can choose which overlays are used.
Upstream Kernel declare all variants of the N2 board (N2, N2Plus, N2L) as a "odroid-n2" board which makes sense, same with the C4 variants.

I also opted to use:

Code: Select all

# Workaround if no overlay address exists (should work for all boards)
if test -z "${fdtoverlay_addr_r}"; then
  setenv fdtoverlay_addr_r ${scriptaddr}
fi

for now I'm not 100% sure if it will work, it should from all I know but I haven't tried it yet.

@tobetter
One thing that doesn't work for me though and this was always the problem with petitboot, is the selection of the dtb file.
It autofills the device-tree to "dtbs/<kernel-version>" and that's it. It completely ignores the fdtpath variables and/or fdtfile variables.
Which is quite annoying. Is there any variable that petitboot respects that I can use to define which dtb file to use?

[tobetter]

@moan, I think I found a solution after some testing to support DTB with Petitboot and this is the change in the boot script.

The change is attached and this must be applied to /boot/boot.scr after booting through Petitboot, but please do back up the file before modifying such that you won't reinstall the OS. The change is attached,

Code: Select all

dd if=/boot/boot.scr of=boot.cmd bs=72 skip=1
patch -p1 < boot.cmd.txt
mkimage -T script -C none -A arm64 -d boot.cmd /boot/boot.scr
reboot

@meveric, please review the changes attached and it allows to load device tree overlay files via Petitboot. The problem is caused by unknown environment variables in boot.scr - "soc" / "board" / "fdtoverlay_addr_r", they are undefined environment variables in Hardkernel's stock U-Boot (v2015). Also the device tree path should be fixed to amlogic/overlays. Please share your thoughts.

So I reviewed the changes again and this is the current diff I have.

Code: Select all

@@ -38,6 +38,23 @@
   setenv maxcpus "maxcpus=${maxcpus}"
 fi
 
+# Workaround if no overlay address exists (should work for all boards)
+if test -z "${fdtoverlay_addr_r}"; then
+  setenv fdtoverlay_addr_r ${scriptaddr}
+fi
+
+# legacy u-boot workaround
+# old u-boot in petitboot may not provide board information, but still provides variants
+if test -z "${soc}"; then
+  if test "${variant}" = "n2" -o "${variant}" = "n2_plus" -o "${variant}" = "n2-plus"; then
+    setenv soc "meson"
+    setenv board "odroid-n2"
+  elif test "${variant}" = "c4" -o "${variant}" = "hc4"; then
+    setenv soc "meson"
+    setenv board "odroid-c4"
+  fi
+fi
+
 # different console for AmLogic devices
 if test "${soc}" = "meson"; then
   setenv console "ttyAML0,115200n8"
@@ -45,12 +62,12 @@
   # C4/N2 only
   if test -n "${variant}"; then
     echo "variant ${variant}"
-    if test "$variant" = "n2-plus"; then
+    if test "${variant}" = "n2-plus"; then
         setenv variant "n2_plus"
     fi
-    if test "$board" = "odroid-n2"; then
+    if test "${board}" = "odroid-n2"; then
         setenv overlaypath "overlays/amlogic/odroidn2"
-    else
+    elif test "${board}" = "odroid-c4"; then
         setenv overlaypath "overlays/amlogic/odroidc4"
     fi
     setenv fdtfile "amlogic/meson64_odroid${variant}.dtb"
@@ -60,12 +77,9 @@
 fi
 if test "${soc}" = "rk3399"; then
     setenv overlaypath "overlays"
-    if test -z "${fdtoverlay_addr_r}"; then
-        setenv fdtoverlay_addr_r ${scriptaddr}
-    fi
 fi

I got rid of if test -z "${petitboot,autoboot}"; then completely as this is a problem with the u-boot itself and not petitboot alone.
Also this statement was probably wrong to begin with and should have been if test -n "${petitboot,autoboot}"; then instead, else it would only have worked if petitboot,autoboot was not set, but it only is set in the old u-boot.

You can ignore petiboot,autoboot for your image, it's added to test for @Moan in order to make your image to boot with current Petitboot.

Rather than testing for petitboot, I went for testing if the soc environment is set or not and if not and it's one of the N2/C4 variants we set the values required accordingly.
This might even work correctly if someone prefers to use the old u-boot but the new image, even without using petitboot.

soc is not with stock U-Boot so as long as its value is defined it will work.

Code: Select all

if test -z "${board}"; then
  setenv board "odroid-${variant}"
fi

this was also incorrect as it would set the board to things like odroid-n2_plus or odroid-n2l or odroid-hc4 and I only want to know which board it is so I can choose which overlays are used.
Upstream Kernel declare all variants of the N2 board (N2, N2Plus, N2L) as a "odroid-n2" board which makes sense, same with the C4 variants.

I am not sure if I understand correctly, board is defined to select device tree overlays. ODROID-N2/N2Plus/N2L can share the device tree overlays so they can use odroid-n2 for board while ODROID-C4 and ODROID-HC4 are not since they do not share pin headers. So my perspective the value of board is odroid-c4 for ODROID-C4 and odroid-hc4 for ODROID-HC4[/b]. But if board is defined in U-Boot itself or if a boot script provide a code to set the value whatever it is, U-Boot and Petitboot will run correctly.

I also opted to use:

Code: Select all

# Workaround if no overlay address exists (should work for all boards)
if test -z "${fdtoverlay_addr_r}"; then
  setenv fdtoverlay_addr_r ${scriptaddr}
fi

for now I'm not 100% sure if it will work, it should from all I know but I haven't tried it yet.

@tobetter
One thing that doesn't work for me though and this was always the problem with petitboot, is the selection of the dtb file.
It autofills the device-tree to "dtbs/<kernel-version>" and that's it. It completely ignores the fdtpath variables and/or fdtfile variables.
Which is quite annoying. Is there any variable that petitboot respects that I can use to define which dtb file to use?

fdtpath and fdtfile does not give me an issue with your image at all. Can you point me out which line exactly the problem happens?

FYI, I am planning to add new default environment variable soc and fdtoverlay_addr_r so your image can boot with Petitboot. One thing not resolved is the value of board, I can set odroid-n2 for ODROID-N2* and odroid-c4 for ODROID-C4 and ODROID-HC4 by default. They can be changed in a boot script again anyway.

[meveric]

You can ignore petiboot,autoboot for your image, it's added to test for @Moan in order to make your image to boot with current Petitboot.

That's not what I meant. The code you had was if test -z "${petitboot,autoboot}"; then which tests if the variable ${petitboot,autoboot} does NOT exist.
Meaning it would trigger this for every u-boot version that does NOT have this, which would in fact include upstream u-boot which does not have ${petitboot,autoboot} as available and then you would set environment variables like board and soc for this, while these u-boots actually have these variables already. Therefore I think this code was incorrect and to avoid checking for petitboot at all it's better to check for the missing environment variables instead.

soc is not with stock U-Boot so as long as its value is defined it will work.

Which is what I said, I check for soc, and if it's not set, then it should define it based on the fact if it finds a AmLogic board.

Code: Select all

if test -z "${board}"; then
  setenv board "odroid-${variant}"
fi

this was also incorrect as it would set the board to things like odroid-n2_plus or odroid-n2l or odroid-hc4 and I only want to know which board it is so I can choose which overlays are used.
Upstream Kernel declare all variants of the N2 board (N2, N2Plus, N2L) as a "odroid-n2" board which makes sense, same with the C4 variants.

I am not sure if I understand correctly

setting $board to "odroid-${variant}" would result in either
odroid-n2
odroid-n2l
odroid-n2_plus
odroid-c4
odroid-hc4

as you mapped it specifically to the VARIANT, while the desired outcome was either "odroid-n2" or "odroid-c4" for all variants.

fdtpath and fdtfile does not give me an issue with your image at all. Can you point me out which line exactly the problem happens?

It's not a line, it's the fact that petitboot (at least the original that came with my N2Plus and N2) completely ignores it.

The code it's suppose to use looks like this:

Code: Select all

setenv fdtfile "amlogic/meson64_odroid${variant}.dtb"

Mainly cause you provide different dtb files than upstream Kernel with some modifications, so instead of meson-sm1-odroid-c4.dtb which comes directly from the Kernel sources, and is also within the u-boot default, I prefer using your meson64_odroidc4.dtb which is fine
Works perfectly fine booting direct from u-boot, but when I boot via petitboot this is what petitboot defines the device-tree as:


It auto selects the path dtbs/<Kernel-Version> but it does not has a dtb file at all.
I also don't selected that path in my code, so this seems to come from petitboot directly.

[tobetter]

You can ignore petiboot,autoboot for your image, it's added to test for @Moan in order to make your image to boot with current Petitboot.

That's not what I meant. The code you had was if test -z "${petitboot,autoboot}"; then which tests if the variable ${petitboot,autoboot} does NOT exist.
Meaning it would trigger this for every u-boot version that does NOT have this, which would in fact include upstream u-boot which does not have ${petitboot,autoboot} as available and then you would set environment variables like board and soc for this, while these u-boots actually have these variables already. Therefore I think this code was incorrect and to avoid checking for petitboot at all it's better to check for the missing environment variables instead.

soc is not with stock U-Boot so as long as its value is defined it will work.

Which is what I said, I check for soc, and if it's not set, then it should define it based on the fact if it finds a AmLogic board.

True, that's why I am telling you that you can ignore it. The code block is NOT necessary for your boot script. That's added for @Moan to run with current Petitboot. This change will be added to Petitboot in the next release as I mentioned.

Code: Select all

if test -z "${board}"; then
  setenv board "odroid-${variant}"
fi

this was also incorrect as it would set the board to things like odroid-n2_plus or odroid-n2l or odroid-hc4 and I only want to know which board it is so I can choose which overlays are used.
Upstream Kernel declare all variants of the N2 board (N2, N2Plus, N2L) as a "odroid-n2" board which makes sense, same with the C4 variants.

I am not sure if I understand correctly

setting $board to "odroid-${variant}" would result in either
odroid-n2
odroid-n2l
odroid-n2_plus
odroid-c4
odroid-hc4

as you mapped it specifically to the VARIANT, while the desired outcome was either "odroid-n2" or "odroid-c4" for all variants.

fdtpath and fdtfile does not give me an issue with your image at all. Can you point me out which line exactly the problem happens?

It's not a line, it's the fact that petitboot (at least the original that came with my N2Plus and N2) completely ignores it.

The code it's suppose to use looks like this:

Code: Select all

setenv fdtfile "amlogic/meson64_odroid${variant}.dtb"

Mainly cause you provide different dtb files than upstream Kernel with some modifications, so instead of meson-sm1-odroid-c4.dtb which comes directly from the Kernel sources, and is also within the u-boot default, I prefer using your meson64_odroidc4.dtb which is fine

Works perfectly fine booting direct from u-boot, but when I boot via petitboot this is what petitboot defines the device-tree as:


It auto selects the path dtbs/<Kernel-Version> but it does not has a dtb file at all.
I also don't selected that path in my code, so this seems to come from petitboot directly.

Your screen explains that only fdtpath works. Petitboot is not smart as much as it select the device tree automatically. It select the device tree as instructed in the boot script. In your boot script, the device tree is selected via fdtfile which is set only when soc is defined which is false to Petitboot while your U-Boot does. By adding soc as meson for its value to your script, I think it will load the device tree properly.

Let me make it simple. In next Petitboot release, soc, fdtoverlay_addr_r and board will be added to Petitboot so that your boot script can run without change, But only the problem is the value of board which I expect to be odroid-${variant} in order to the device tree overlay files for ODROID-HC4 and other board which would use different GPIO map from ODROID-C4.

[meveric]

Your screen explains that only fdtpath works.

Actually it does not. Just for fun I put this in my boot script:

Code: Select all

# petitboot workaround test
setenv fdtpath "this-does-not-work"

This code is outside of ANY condition and is ALWAYS set.
Guess what changed compared to the picture above? If you guessed "nothing" you're correct.
It had absolutely no effect.

Petitboot is not smart as much as it select the device tree automatically. It select the device tree as instructed in the boot script. In your boot script, the device tree is selected via fdtfile which is set only when soc is defined which is false to Petitboot while your U-Boot does. By adding soc as meson for its value to your script, I think it will load the device tree properly.

It does not. I manually set soc to "meson" without any conditions, still the fdtfile will not be set as device-tree and the path will always be /dtbs/<kernel-version>.

Let me make it simple. In next Petitboot release, soc, fdtoverlay_addr_r and board will be added to Petitboot so that your boot script can run without change

Which only work if someone updates SPI/petitboot on the odroid, so out of box experience is still broken sadly. I wished there was a way to tell petitboot what dtb file to load even in the old version.

But only the problem is the value of board which I expect to be odroid-${variant} in order to the device tree overlay files for ODROID-HC4 and other board which would use different GPIO map from ODROID-C4.

That is rather confusing. If the overlays for HC4 and C4 are different, then why even on your git repository there is only one overlay folder for ODROID C4, but not for the ODROID HC4?
https://github.com/tobetter/linux/tree/ ... c/overlays

Edit:
I did some more digging, and I think I found the problem.
While u-boot itself supports checks like:

Code: Select all

if load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${fdtpath}/${fdtfile}; then

to check if a file exists and is loadable, petitboot does not understand this.
And it also seems that setting fdtfile and fdtpath is exclusive under petitboot.
If I set fdtfile (without conditions) it will try to load this via petitboot virtual file system.
If I set fdtpath it replaces fdtfile settings completely it seems and only has the path but no fdtfile.
It's a bit unclear under which condition one happens over the other.
I think I have to find a way to set fdtpah and fdtfile in the correct order without checking if they exist for petitboot to find the correct path.

[tobetter]

Your screen explains that only fdtpath works.

Actually it does not. Just for fun I put this in my boot script:

Code: Select all

# petitboot workaround test
setenv fdtpath "this-does-not-work"

This code is outside of ANY condition and is ALWAYS set.
Guess what changed compared to the picture above? If you guessed "nothing" you're correct.
It had absolutely no effect.

Petitboot is not smart as much as it select the device tree automatically. It select the device tree as instructed in the boot script. In your boot script, the device tree is selected via fdtfile which is set only when soc is defined which is false to Petitboot while your U-Boot does. By adding soc as meson for its value to your script, I think it will load the device tree properly.

It does not. I manually set soc to "meson" without any conditions, still the fdtfile will not be set as device-tree and the path will always be /dtbs/<kernel-version>.

Please let me know what's changed in your boot script, specifically which line did you change to set soc. No matter the value of soc, if there is exact line which tells about fdtfile, Petitboot does not know about it. Petitboot itself does not set the value fdtfile, if fdtfile is still not set, it's a logic error that it's not set for some reason. Your current boot script sets fdtfile only when [s]soc[/b] is meson, other than that it's empty in Petitboot.

Let me make it simple. In next Petitboot release, soc, fdtoverlay_addr_r and board will be added to Petitboot so that your boot script can run without change

Which only work if someone updates SPI/petitboot on the odroid, so out of box experience is still broken sadly. I wished there was a way to tell petitboot what dtb file to load even in the old version.

Current Petitboot runs when soc, fdtoverlay_addr_r and board are set. That's proven by the change I made for @Moan. Isn't it? You do not want to add fdtoverlay_addr_r with a fixed address and Petitboot does not know about the value, then nothing can work. soc is the same. I have no clue to select another environment variable rather than petitboot,autoboot in order to let the script is running with Petitboot or not, please let me know if you find better one.

But only the problem is the value of board which I expect to be odroid-${variant} in order to the device tree overlay files for ODROID-HC4 and other board which would use different GPIO map from ODROID-C4.

That is rather confusing. If the overlays for HC4 and C4 are different, then why even on your git repository there is only one overlay folder for ODROID C4, but not for the ODROID HC4?
https://github.com/tobetter/linux/tree/ ... c/overlays

Because there is no request a device tree for ODROID-HC4 yet, but a couple of users reached me to use it with a device tree overlay.

It's not a bug or a fault, just lack of Petitboot feature to support your image. That's why I am telling you that Petitboot is required to update/upgraded.

[meveric]

Please let me know what's changed in your boot script, specifically which line did you change to set soc.
No matter the value of soc, if there is exact line which tells about fdtfile, Petitboot does not know about it. Petitboot itself does not set the value fdtfile, if fdtfile is still not set, it's a logic error that it's not set for some reason. Your current boot script sets fdtfile only when [s]soc[/b] is meson, other than that it's empty in Petitboot.

I literally set:

Code: Select all

setenv soc "meson"

above the check if test "${soc}" = "meson"; then line and it did not have any effect.

Current Petitboot runs when soc, fdtoverlay_addr_r and board are set.

As you said you've noticed for the fdtfile to be set only the soc is required, the rest is just for overlays and can completely be ignored for now.
Still even setting explicitly soc to meson had no effect on the stock petitboot.
Maybe with later petitboot version this works but it seems with the original that came with the N2Plus I have it does not work.

That's proven by the change I made for @Moan. Isn't it?

Which I also said technically was the wrong code to begin with as you check if the variable "IS NOT SET", but from all I know this variable is set.
And was a logic error to begin with but still worked.
The only change that I did, rather than checking if the petitboot,autostart variable exists or not, I simply checked of the soc variable exists or not, which should be "more universal".

You do not want to add fdtoverlay_addr_r with a fixed address and Petitboot does not know about the value, then nothing can work.

This only applies for overlays. The problem is that not even the dtb file itself is loaded.. I'm not talking about overlays.
That's several steps ahead, I rather get the image to boot "at all" in the first step, before I bother getting overlays fixed or not

soc is the same. I have no clue to select another environment variable rather than petitboot,autoboot in order to let the script is running with Petitboot or not, please let me know if you find better one.

Once again. If soc is missing, why not check for soc that what's dictate the logic, does it not?
It's totally independent of petitboot.
in pseudo-code:

Code: Select all

if soc does not exist:
set soc

No need to check for petitboot in any way.

Because there is no request a device tree for ODROID-HC4 yet, but a couple of users reached me to use it with a device tree overlay.

Then yes, that's a condition for the future, but one that is currently not reflected in any code.

[meveric]

ok I've done some more testing:

setenv soc "meson"
has no effect, the path that checks if soc is set to meson is never true and therefor the fdtfile is never set.
Considering that even in that case the u-boot itself provides an default fdtfile and petitboot is ignoring this, is quite surprising.

As my code tries to find the correct dtb file in different locations the last thing petitboot sees is a setenv fdtpath "dtbs/${fk_kvers}" where I than try to load the fdtfile from:

Code: Select all

if load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${fdtpath}/${fdtfile}; then

for whatever reason petitboot stops here and has only dtbs/<fk_kvers} as a path for the device-tree file as apparently the fdtfile variable is empty?

If I explicitly set fdtfile to a random value:
setenv fdtfile "amlogic"

I get the result: device-tree=dtbs/<fk_kvers}/amlogic

If instead I set the value manually to an correct value:

Code: Select all

setenv fdtfile "amlogic/meson64_odroid${variant}.dtb"

It seems to go to my fallback state:

Code: Select all

load ${devtype} ${devnum}:${partition} ${fdt_addr_r} dtb

and the device-tree of petitboot will point to:
/tmp/usr/var/petitboot/mnt/dev/mmcblk1p1/dtb
which does work, but is not the desired outcome.

apparently petitboot (at least in the original version) is not very good at logic.

Edit:
I think I kinda figured out what is the main problem.
I might be wrong but it looks like this version of petitboot does not allow to create new variables.
Every setenv of a variable that petitboot does not know is ignored, and therefore also every check on a variable that it doesn't know fails.
I guess this is fixed in newer versions of petitboot, but this version seems to be somewhat broken.

[tobetter]

@meveric, What's the version of your Petitboot? Petitboot have been updated many times and latest version is "20220317".

[meveric]

to be honest I'm not sure.. I never updated petitboot it still has the same version on it as it came with.

[back2future]

Does Debian Bullseye64 at all support Mali G52 closed source Bifrost user space binary libraries (AFAIK, what depends on Wayland libraries support) and mali_kbase Kernel module (~r39p)?
(Thx)

[meveric]

You can run Wayland with the opensource panfrost drivers.
But no it does not support Mali GPU blobs from ARM. The Kernel module is missing.

[back2future]

Thanks for the explanation and support.
Debian Bullseye64 system is functional like described on first post, only me having special need for OpenGL (ES) 3.2 extensions (what seems supported with Kernel 4.9 and Bifrost GPU blobs ("OpenGL ES 1.1, 2.0, 3.0, 3.1, 3.2"), starting from an Ubuntu 22.04 original Odroid minimal image), what is 'only' partly worked into panfrost open source Mesa user space libraries (01/2023, panfrost ~90% of extensions included for OpenGL 3.2/3.3 (100% 3.1) and ~67% into OpenGL ES 3.2 (100% 3.1) version) at the moment.
Do You provide Kernel source for 6.1.0-arm64?

[meveric]

Not directly I use sources from: https://git.kernel.org/pub/scm/linux/ke ... /linux.git
But yes if you need Kernel 4.9 support you would have to use my Debian Buster images instead.

[Moan]

Older / stock versions of petitboot aren't that great. I assume everyone who would like to try this image to boot from USB would update petitboot anyway. Perfectly, some disclaimer could be added with a link to the updated version of petitboot.

Skipping some unexpected OS detection bug, the 20220317 version of petiboot worked perfectly fine for me. I was able to boot "Debian Bullseye (11) N2/N2L" from the USB microSD reader and M.2 NVME Adapter with no issues. The only problem is that something damages the existing OS on the SD card / eMMC when you boot this image from the USB for the first time. It probably tries to resize the incorrect partition, as I was getting a lot of errors related to no space left and I had to manually resize it with GParted on PC. But it's a minor issue, I learnt to just remove eMMC and microSD cards when booting OS from the USB. Besides that I refunded my eMMC module since it costs more than some NVMe disks, and my micro SD card slot died completely. So I have nothing to remove left xD

Back to the subject, the only problem I had was with overlays loading. Everything else worked perfectly fine from USB. I'm currently using a Kingston NVMe for this OS. It's really fast, especially compiling things like Samba. I will never want to return to microSD nor even eMMC after experiencing how fast it feels with NVMe on N2.

Anyway, @meveric you can send me the updated "boot.cmd". I'll manually change rootfs "UUID", and fk_kvers to match my current boot.scr. Then I'll let you know if overlays are loading. If they do, then I guess nothing else would be needed.

[meveric]

I've updated my setup-odroid package which handles configuration of flash-kernel.
The new boot script will be deployed automatically upon installation.

btw. you don't need to temper with the UUID of the rootfs or the fk_kvers in the boot script, if you check config.ini there is a option to set both of them manually in case you want to overwrite the defaults.

[Moan]

Thanks! After apt upgrade overlays are still loading correctly. I can use i2c and onewire (the ones that come by default) with no issues.