Debian on Omninas Shuttle KS10

Quote

It has a Power button?

Yes, it has a power button.

Quote

the correct Power Off GPIO (if it is indeed using GPIO).

What are the other options?

Quote

Unfortunately the stock boot log does not show the SPI flash chip name.

u-boot has some information

Shuttle>> sf probe 0
1024 KiB EN25Q80 at 0:0 is now current device

Quote

>

Quote

the correct Power Off GPIO (if it is indeed
> using GPIO).

>
> What are the other options?

Some boxes don't use GPIO for power off or restart. Some boxes don't even have a power off. But there is a button here, so likely it is GPIO.

Quote

>

Quote

Unfortunately the stock boot log does not
> show the SPI flash chip name.

>
> u-boot has some information
>
>

> Shuttle>> sf probe 0
> 1024 KiB EN25Q80 at 0:0 is now current device
> 

There is a section in drivers/mtd/spi-nor/core.c.

/* Flashes that can't be detected using JEDEC */
        {"m25p05-nonjedec"},    {"m25p10-nonjedec"},    {"m25p20-nonjedec"},
        {"m25p40-nonjedec"},    {"m25p80-nonjedec"},    {"m25p16-nonjedec"},
        {"m25p32-nonjedec"},    {"m25p64-nonjedec"},    {"m25p128-nonjedec"},

Since the jdec seems unrecognized by the kernel:

Quote

[ 5.737484][ T1] spi-nor spi0.0: unrecognized JEDEC id bytes: 1c 31 14 1c 31 14

One of those in the table might work. Most likely:

"m25p80-nonjedec"

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

The dts job seems to be done. After all the 'reboot' gpio 55 was the power-off gpio. Somehow it causes a reboot when activated from shell, but it powers down the box when shutting down. Maybe the combination with the blue system led which is on when up, but somewhere switches off during shutdown.

Now I can startup and shutdown the box using the same button. For some reason the 'POWER' button in esekeyd.conf didn't work, it had to be KEY_116.

-----

Spi flash works (at least reading, didn't dare to write so far, as I didn't get kwboot to work).

[    5.755449] spi-nor spi0.0: m25p80-nonjedec (1024 Kbytes)
[    5.762066] 3 fixed-partitions partitions found on MTD device spi0.0
[    5.769502] Creating 3 MTD partitions on "spi0.0":
[    5.775033] 0x000000000000-0x0000000c0000 : "u-boot"
[    5.782978] 0x0000000c0000-0x0000000d0000 : "u-boot-env"
[    5.792399] 0x0000000d0000-0x000000100000 : "unused"

-----

Wake on lan works

ethtool -s eth0 wol g

enables it. Unfortunately it doesn't work when the box has lost it's power in between. According to my switch it has no link in that case, so it's not just an unknown MAC address.

-----

Wake on RTC works.

echo `date '+%s' -d '+ 1 minutes'` > /sys/class/rtc/rtc0/wakealarm ; poweroff

switches off the box, and it restarts after 1 minute. This survives a power cycle.

-----

The SATA driver of u-boot leaves some room for optimisation. Loading uImage and uInitrd (15MB together) from disk takes slightly more than 1 minute.

-----

@bohdi, thank you for your support. I have learned a lot.

Quote

Shuttle>> bootm
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   ARM OpenWrt Linux-5.10.90
   Created:      2022-01-13   8:33:29 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5087137 Bytes =  4.9 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

DTB:0x004DEBE8 (0x000033B9)
C:0x000080C0-0x004E2040->0x0119D200-0x01677180
DTB:0x01673D28 (0x00003452)
Uncompressing Linux... done, booting the kernel.

Does anybody have the corresponding log for a 512MB Armada box?

C:0x000080C0-0x004E2040->0x0119D200-0x01677180

Both ranges are 5087104 bytes in size, so I suppose the decompressor moves the compressed kernel from 0x000080C0 to 0x0119D200, and decompresses it back. According to binwalk the decompressed kernel is 18433664 bytes (there is an initramfs inside), so the address 0x0119D200 (18469376) should fit, but there is not much room left.

Hi Mijzelf,

> The dts job seems to be done. After all the
> 'reboot' gpio 55 was the power-off gpio. Somehow
> it causes a reboot when activated from shell, but
> it powers down the box when shutting down. Maybe
> the combination with the blue system led which is
> on when up, but somewhere switches off during
> shutdown.

Awesome!

> Now I can startup and shutdown the box using the
> same button. For some reason the 'POWER' button in
> esekeyd.conf didn't work, it had to be KEY_116.

Yes, I recall some problem with how recent version of esekeyd deals with key names. I think it does not map that key KEY_116 to Power button correctly (other buttons also have same problem). But as you've found, using key number works fine!

> Spi flash works (at least reading, didn't dare to
> write so far, as I didn't get kwboot to work).

> [ 5.755449] spi-nor spi0.0: m25p80-nonjedec
> (1024 Kbytes)

Cool!

Did you use the SPI mtd dump for kwboot?

> Wake on lan works
>

> ethtool -s eth0 wol g
>

> enables it. Unfortunately it doesn't work when the
> box has lost it's power in between. According to
> my switch it has no link in that case, so it's not
> just an unknown MAC address.

It must be because the wait logic is in the NIC. So it's gone when power is interrupted.

> Wake on RTC works.
>

> echo `date '+%s' -d '+ 1 minutes'` >
> /sys/class/rtc/rtc0/wakealarm ; poweroff
>

> switches off the box, and it restarts after 1
> minute. This survives a power cycle.

Nice! it makes sense (with its own battery).


> The SATA driver of u-boot leaves some room for
> optimisation. Loading uImage and uInitrd (15MB
> together) from disk takes slightly more than 1
> minute.

This u-boot is too old.

> @bohdi, thank you for your support. I have learned
> a lot.

You're welcome! glad I can help to make this board bring up go a bit faster.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> Does anybody have the corresponding log for a
> 512MB Armada box?
>

> C:0x000080C0-0x004E2040->0x0119D200-0x01677180
>

> Both ranges are 5087104 bytes in size, so I
> suppose the decompressor moves the compressed
> kernel from 0x000080C0 to 0x0119D200, and
> decompresses it back. According to binwalk the
> decompressed kernel is 18433664 bytes (there is an
> initramfs inside), so the address 0x0119D200
> (18469376) should fit, but there is not much room
> left.

GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade (Linux-5.10.7)

While the RN102 uses loadaddr 0x2000000, The Mirabox uses loadaddr 0x6400000. Perhaps try 0x6400000 to see it will make any difference.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
>
> While the RN102 uses loadaddr 0x2000000, The
> Mirabox uses loadaddr 0x6400000. Perhaps try
> 0x6400000 to see it will make any difference.

You mean this? Unfortunately it didn't make any difference

Using egiga0 device
TFTP from server 172.20.172.252; our IP address is 172.20.172.169
Filename 'openwrt-mvebu-cortexa9-globalscale_mirabox-initramfs-kernel.bin'.
Load address: 0x6400000
Loading: #################################################################
  #################################################################
  #################################################################
  #################################################################
  #################################################################
  ######################
done
Bytes transferred = 5087201 (4d9fe1 hex)
Shuttle>> bootm 0x06400000
## Booting kernel from Legacy Image at 06400000 ...
  Image Name:   ARM OpenWrt Linux-5.10.90
  Created:      2022-01-13   8:33:29 UTC
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:    5087137 Bytes =  4.9 MB
  Load Address: 00008000
  Entry Point:  00008000
  Verifying Checksum ... OK
  Loading Kernel Image ... OK
OK

Starting kernel ...

DTB:0x004DEBE8 (0x000033B9)
C:0x000080C0-0x004E2040->0x0119D200-0x01677180
DTB:0x01673D28 (0x00003452)
Uncompressing Linux... done, booting the kernel. 

Quote

Nice! it makes sense (with its own battery).

Well, there is no visible battery on the board, but I suppose the RTC is that low powered that it can keep the time on a capacitor.

Quote

This u-boot is too old.

Correction: This u-boot is old. It still gets its job done, I just have to wait a little longer. (And yes, a new u-boot with fdt support and everything would be nice, but at the end of the day this one Just Works™

Quote

Did you use the SPI mtd dump for kwboot

Yes. I stripped the u-boot environment and everything behind:

kwboot -b spidump -p -a -t /dev/ttyUSB0
Sending boot message. Please reboot the target...-
Sending boot image...
Booting from SPI flash
DDR3 Training Sequence - Ver 2.3.5 
DDR3 Training Sequence - Ended Successfully 
  0 % [+xmodem: Protocol error

Google found me this. I tried the recover.bin which Willy Tarreau offers:

kwboot -b recover.bin -p -a -t /dev/ttyUSB0
Sending boot message. Please reboot the target...|
Sending boot image...
  0 % [......................................................................]
  1 % [......................................................................]
  2 % [......................................................................]
  3 % [......................................................................]
  4 % [......................................................................]
  6 % [......................................................................]
  7 % [......................................................................]
  8 % [.................................................^C

At around 6% the speed slowed down, and after a minute it was at 8%. When you leave it, it stops at 21%. According to Willy the whole upload should take around 45 sec. Reading Willy's page, I think at 6% the DDR3 initialisation code was uploaded, and the box somehow slowed down a lot due to wrong timings.

So I tried to patch my own dump. Willy talks about 0x10000, but I don't know if that is 0x00010000 or 0x010000. When looking for 0x010000 I found a few occurrences, unfortunately not on the same addresses, but I patched them anyway. Problem is now that some checksum doesn't fit, I think:

kwboot -b spidump -p -a -t /dev/ttyUSB0
spidump: Invalid image.

So I can try to patch kwboot to correct it on the fly, or do you have a better idea?

Mijzelf,


> Yes. I stripped the u-boot environment and
> everything behind:

You really don't need to strip anything, use the whole SPI mtd dump is better (no doubt if anything missing). It just a bit slower. After you can boot it with kwboot, you can tweak it to make it smaller.

> Google found me
> this.
> I tried the recover.bin which Willy Tarreau
> offers:

I did credit Willy Tarreau blog in my Mirabox installation post.

> and the box somehow slowed down a lot due to wrong
> timings.

Yes, it might be problematic because DDR timing of different boards.

> So I can try to patch kwboot to correct it on the
> fly, or do you have a better idea?

kwboot has been substantially improved, much more robust than older versions.

In case you were running the kwboot on your box distro (which must be a few generation older), I've attached the ARM kwboot binary I've just built today. Please try this kwboot with the SPI mtd dump.

I'll be back, it's pretty late in my timezone :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 01/22/2022 05:47AM by bodhi.

OK, this kwboot works:

 ./kwboot -b spidump -t /dev/ttyUSB0 
kwboot version 2022.01-00673-g70fe7827f2-dirty
Patching image boot signature to UART
Aligning image header to Xmodem block size
Sending boot message. Please reboot the target.../
Waiting 2s and flushing tty
Sending boot image header (59648 bytes)...
  0 % [......................................................................]
<snip>
 75 % [......................................................................]
 90 % [..............................................                        ]
Done
DDR3 Training Sequence - Ver 2.3.5 
DDR3 Training Sequence - Ended Successfully 

Sending boot image data (674628 bytes)...
  0 % [......................................................................]
<snip>
 98 % [......................................................................]
 99 % [.....................                                                 ]
Done
Finishing transfer
[Type Ctrl-\ + c to quit]

     _           _   _   _       
    | |         | | | | | |      
 ___| |__  _   _| |_| |_| | ___  
/ __| '_ \| | | | __| __| |/ _ \ 
\__ \ | | | |_| | |_| |_| |  __/ 
|___/_| |_|\__,_|\__|\__|_|\___| 
          _   _     ____              _
         | | | |   | __ )  ___   ___ | |_ 
         | | | |___|  _ \ / _ \ / _ \| __| 
         | |_| |___| |_) | (_) | (_) | |_ 
          \___/    |____/ \___/ \___/ \__| 

 ** LOADER **


U-Boot 2009.08 ( 9月 25 2013 - 16:20:16)Marvell version: 1.1.3 NQ
<snip>

But it simply reads the environment, and boots Debian. How do I know that it's actually the uploaded u-boot which runs? I tried to edit the prompt, but again:

 ./kwboot -b spidump2 -t /dev/ttyUSB0 
kwboot version 2022.01-00673-g70fe7827f2-dirty
spidump2: Invalid image.

BTW, where did you compile this binary? I had to create a symlink /lib/ld-linux.so.3 to /lib/ld-linux-armhf.so.3 on my Debian box to get this running.

Meanwhile I have found the problem of the OpenWrt image. It's the patch target/linux/mvebu/patches-5.10/300-mvebu-Mangle-bootloader-s-kernel-arguments.patch, which has as comment

Quote

The command-line arguments provided by the boot loader will be
appended to a new device tree property: bootloader-args.
If there is a property "append-rootblock" in DT under /chosen
and a root= option in bootloaders command line it will be parsed
and added to DT bootargs with the form: <append-rootblock>XX.
Only command line ATAG will be processed, the rest of the ATAGs
sent by bootloader will be ignored.
This is usefull in dual boot systems, to get the current root partition
without afecting the rest of the system.

and edits

 
 arch/arm/Kconfig                        | 11 ++++
 arch/arm/boot/compressed/atags_to_fdt.c | 85 ++++++++++++++++++++++++-
 init/main.c                             | 16 +++++

Without it the image is about 1k smaller, and it boots.

Reading the patch it's not clear to me why it would be a problem in the KS10, but not on the KD22

Cool!

> But it simply reads the environment, and boots
> Debian. How do I know that it's actually the
> uploaded u-boot which runs?

You could try Willy's recover.bin with the new kwboot. It might boot.

Note how Willy use the old doimage command. It's probably needed to produce the correct image.

> BTW, where did you compile this binary? I had to
> create a symlink /lib/ld-linux.so.3 to
> /lib/ld-linux-armhf.so.3 on my Debian box to get
> this running.

I compiled it on the Thecus N2350 (Armada 385) box. That's strange, usually by default, compile u-boot tools natively will produce a static binary. And I run it on the NSA310S (Kirkwood Soc, which is armel) so there is no armhf share library on thix box. Let me see I can find out why.

> Meanwhile I have found the problem of the OpenWrt
> image. It's the patch
> target/linux/mvebu/patches-5.10/300-mvebu-Mangle-bootloader-s-kernel-arguments.patch,

> Without it the image is about 1k smaller, and it
> boots.

Ah. Congrats! so that's where they patched it.

> Reading the patch it's not clear to me why it
> would be a problem in the KS10, but not on the
> KD22

Does the KD22 boot with my Mirabox image?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I see

#file kwboot

kwboot: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, BuildID[sha1]=14a40583f5233440e98814a1843c6c5a73ef80a9, for GNU/Linux 3.2.0, not stripped

So I was wrong, the default is dynamically link binary for the tools.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 01/22/2022 05:07PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> Also you don't need to change the memory size in
> the DTS. It will be detected by u-boot.

I was looking further at that patch. It adds a 'ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE' to Kconfig / .config. And in arch/arm/boot/compressed/atags_to_fdt.c, there is a code block disabled by this config:

#ifndef CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE
                else if (atag->hdr.tag == ATAG_MEM) {
                        if (memcount >= sizeof(mem_reg_property)/4)
                                continue;
                        if (!atag->u.mem.size)
                                continue;
                        memsize = get_cell_size(fdt);

                        if (memsize == 2) {
                                /* if memsize is 2, that means that
                                 * each data needs 2 cells of 32 bits,
                                 * so the data are 64 bits */
                                __be64 *mem_reg_prop64 =
                                        (__be64 *)mem_reg_property;
                                mem_reg_prop64[memcount++] =
                                        cpu_to_fdt64(atag->u.mem.start);
                                mem_reg_prop64[memcount++] =
                                        cpu_to_fdt64(atag->u.mem.size);
                        } else {
                                mem_reg_property[memcount++] =
                                        cpu_to_fdt32(atag->u.mem.start);
                                mem_reg_property[memcount++] =
                                        cpu_to_fdt32(atag->u.mem.size);
                        }

So this looks like the patch disables the pass through of the detected memory size to the kernel.

What I don't understand is, why is this code here anyway? AFAIK the atag data is in the first 0x8000 bytes. The piggyback + compressed kernel is put on 0x8000. So the decompressing piggyback could just not touch this area, and let the decompressed kernel handle it. If I now choose to not compress the kernel, this code is not attached, and so there has to be a second atag interpreter, or it's not allowed to have a not compressed kernel.

When looking in the OpenWrt wiki to bootlogs, I have the impression that most MIPS devices have the bootloader decompress the kernel, while most (all?) ARM devices have a decompressing piggyback on the kernel. The directory arch/mips/boot/compressed is much smaller than arch/arm/boot/compressed.

Maybe the atag blocks are handled by the piggyback, because it needs the memory size itself, somehow. When I look at the log with the patch removed

DTB:0x01673BD0 (0x00003402)
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0

compared to start_kernel

asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
{
        char *command_line;
        char *after_dashes;

        set_task_stack_end_magic(&init_task);
        smp_setup_processor_id();

the first bootline comes from smp_setup_processor_id(), which doesn't seem to do anything outside the stack, and set_task_stack_end_magic() only puts a marker at the end of the current stack, which is setup either by the bootloader, or by the piggyback. So when it crashes before this bootline, the crash is in the piggyback.

/Edit:
meanwhile I found that the patch disables this lines in function atags_to_ftd() in atags_to_fdt.c in the piggyback, which causes the crash.

               else if (atag->hdr.tag == ATAG_MEM) {

                        if (memcount >= sizeof(mem_reg_property)/4)
                                continue;
                        if (!atag->u.mem.size)
                                continue;
                        memsize = get_cell_size(fdt);

                        if (memsize == 2) {
                                /* if memsize is 2, that means that
                                 * each data needs 2 cells of 32 bits,
                                 * so the data are 64 bits */
                                __be64 *mem_reg_prop64 =
                                        (__be64 *)mem_reg_property;
                                mem_reg_prop64[memcount++] =
                                        cpu_to_fdt64(atag->u.mem.start);
                                mem_reg_prop64[memcount++] =
                                        cpu_to_fdt64(atag->u.mem.size);
                        } else {
                                mem_reg_property[memcount++] =
                                        cpu_to_fdt32(atag->u.mem.start);
                                mem_reg_property[memcount++] =
                                        cpu_to_fdt32(atag->u.mem.size);
                        }
                }
<snip>
	}
        if (memcount) {
                setprop(fdt, "/memory", "reg", mem_reg_property,
                        4 * memcount * memsize);
        }

So now I have to try if providing the right memory size in the dtb file fixes this issue.

/Edit2: It does.



Edited 3 time(s). Last edit at 01/23/2022 11:20AM by Mijzelf.

> So now I have to try if providing the right memory
> size in the dtb file fixes this issue.
>
> /Edit2: It does.

Congrats for figuring out this problem!

So the crash had nothing to do with the UART address, since EARLYPRINTK is not used. But the memory was wrong so the decompression crashed!!!

My personal preference is to let u-boot pass the right memory, and the kernel just ignore what's in the DTS. This is more flexible is you have full control of u-boot. OpenWrt does not need that flexibility, and it usually runs with stock u-boot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

You could try Willy's recover.bin with the new kwboot. It might boot.

It doesn't

$ ./kwboot  -b recover.bin -t /dev/ttyUSB0 
kwboot version 2022.01-00673-g70fe7827f2-dirty
Sending boot message. Please reboot the target...|
Waiting 2s and flushing tty
Sending boot image header (48640 bytes)...
  0 % [......................................................................]
 18 % [......................................................................]
 37 % [......................................................................]
 55 % [......................................................................]
 73 % [......................................................................]
 92 % [..............................                                        ]
Done

Poor memory. Pushed too hard.

So I patched kwboot to patch the checksum of my patched dump:

$ ./kwboot -f -b  spidump.patched -t /dev/ttyUSB0 
kwboot version 2022.01
sum32 260959006 != -336687930
Patching image boot signature to UART
Aligning image header to Xmodem block size
Sending boot message. Please reboot the target...|
Waiting 2s and flushing tty
Sending boot image header (59648 bytes)...
  0 % [......................................................................]
 15 % [......................................................................]
 30 % [......................................................................]
 45 % [......................................................................]
 60 % [......................................................................]
 75 % [......................................................................]
 90 % [..............................................                        ]
Done
DDR3 Training Sequence - Ver 2.3.5 
DDR3 Training Sequence - Ended Successfully 

Sending boot image data (674628 bytes)...
  0 % [......................................................................]
  1 % [......................................................................]
<snip>
 98 % [......................................................................]
 99 % [.....................                                                 ]
Done
Finishing transfer
[Type Ctrl-\ + c to quit]

     _           _   _   _       
    | |         | | | | | |      
 ___| |__  _   _| |_| |_| | ___  
/ __| '_ \| | | | __| __| |/ _ \ 
\__ \ | | | |_| | |_| |_| |  __/ 
|___/_| |_|\__,_|\__|\__|_|\___| 
          _   _     ____              _
         | | | |   | __ )  ___   ___ | |_ 
         | | | |___|  _ \ / _ \ / _ \| __| 
         | |_| |___| |_) | (_) | (_) | |_ 
          \___/    |____/ \___/ \___/ \__| 

 ** LOADER **


Patched U-boot ( 9月 25 2013 - 16:20:16)Marvell version: 1.1.3 NQ

Indeed the uploaded u-boot is active.

Quote

Does the KD22 boot with my Mirabox image?

My guess is yes, but I don't know. The only information I have is that OpenWrt thread.

/Edit: After removing the 'read_only' tag from the u-boot-env partition in the dts file, I was able to change the environment using fw_setenv, the box still booted :) , and the environment change survived a reboot.



Edited 1 time(s). Last edit at 01/25/2022 10:36AM by Mijzelf.

Quote

So I patched kwboot to patch the checksum of my patched dump
....
Patched U-boot ( 9月 25 2013 - 16:20:16)Marvell version: 1.1.3 NQ

Cool! it will be very handly in testing certain u-boot images. Could you post the kwboot patch?

Quote

/Edit: After removing the 'read_only' tag from the u-boot-env partition in the dts file, I was able to change the environment using fw_setenv, the box still booted :) , and the environment change survived a reboot.

Well done :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Could you post the kwboot patch?

Sure.

Thanks!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bohdi: Do you apply any patches to your kernel regarding power off? I've read linux-5.10.7-mvebu-370xp-tld-1.patch, but as far as I can see it only adds dts files, and a disk led driver.
For some reason in OpenWrt I can switch off the box, but I can't switch it on again without powercycling. Tried in both 21.02.1 (Kernel 5.4.154) and master (5.10.90). While your kernel works fine (5.10.7). Same dts file, of course.

@Mijzelf,

> @bohdi: Do you apply any patches to your kernel
> regarding power off? I've read
> linux-5.10.7-mvebu-370xp-tld-1.patch, but as far
> as I can see it only adds dts files, and a disk
> led driver.

The difference from mainline is all in the patch. I'm very careful when I create the patch (a new source tree is used each build), so that's all I got.

> For some reason in OpenWrt I can switch off the
> box, but I can't switch it on again without
> powercycling. Tried in both 21.02.1 (Kernel
> 5.4.154) and master (5.10.90). While your kernel
> works fine (5.10.7). Same dts file, of course.

I do recall in some boxes (don't remember which), a separate driver for Restart must be used, so perhaps OpenWrt has some differences regarding this.

# grep -i power_reset /boot/config-5.16.5-mvebu-tld-1

CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_BRCMKONA is not set
# CONFIG_POWER_RESET_BRCMSTB is not set
CONFIG_POWER_RESET_GPIO=y
CONFIG_POWER_RESET_GPIO_RESTART=y
CONFIG_POWER_RESET_LINKSTATION=m
# CONFIG_POWER_RESET_LTC2952 is not set
CONFIG_POWER_RESET_QNAP=y
# CONFIG_POWER_RESET_REGULATOR is not set
# CONFIG_POWER_RESET_RESTART is not set
# CONFIG_POWER_RESET_VERSATILE is not set
# CONFIG_POWER_RESET_SYSCON is not set
# CONFIG_POWER_RESET_SYSCON_POWEROFF is not set

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Yep, that was it. I had to set
CONFIG_POWER_RESET_GPIO=y
(and so also
CONFIG_POWER_RESET=y)

Cool!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)