crosser

My change was about restoring the eth0/end0 MAC address to its intended value (ie grabbed from OTP via SPI as it was designed to work until it was broken at one point).
It does not change the interface names. I warned about it as if one had a static DHCP lease on the MAC that was set for a few years other than the OTP one the lease would not apply.
 
The change is included for 6.9 and up, the issue reported above is for 6.8 (though it is likely a user space issue as interface renaming is udev userspace).
So I guess @crosser upgraded from a kernel with the initial behavior I restored to an intermediate one which did not grab the MAC from the OTP.
 
Note also that I did not apply these changes to the 6.6 kernel (-current), only to -edge.
 
The MAC address and the interface rename issue are unrelated.

Started work on syncing the helios64 dts to upstream for 6.9: https://github.com/prahal/build/tree/helios64-6.9 .
 
I removed the overclock disabling patch as the overclock as it disables an overclock that is at least nowadays not in the included rk3399-opp.dtsi (ie cluster0 has no opp6 and cluster no opp8). It was not a high priority beforehand but as the helios64 dts starts to change, thus carries unnecessary work.
 
The pachtset applies. The helios64 dts compile fine to dtb.
Kernel built and booted. (see below for network connection, ie ethernet MAC fixup)
 
There are not many functional changes on my side (there are in upstream dts). There are a few differences with upstream dts I did not bring as I don't know if they are leftover from the initial patch set or new fixups. But this could already have been an issue before 3.9 for most of these changes (there is at least a new upstream change 93b36e1d3748c352a70c69aa378715e6572e51d1  "arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64") I brought forward.
I also brought in vcc3v0_sd node "enable-active-high;"  and "gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;".
 
 
Beware.
ethernet MAC change (now working as designed). The fact I kept the aliases from upstream fixes the ability for the eth0 (then renamed to end0 by armbian-hardware-optimization) ethernet mac - grabbed from OTP via SPI in u-boot to be applied. Thus if you bound the MAC address that was generated by the kernel instead of from the hardware to a host and IP, you will have to find the new IP assigned by the DHCP server to connect to the helios64.
I believe this is fine for edge even if not for current (so should be good for 6.9?).

Thanks!
I could not respond earlier because forum allows to make only one post in the first day.
It is embarrassing, I am actually quite certain that I tried to boot with SD card and without it several times, and the result was the same (no signs of life). And I even wrote the image to the card again and tried again. But when I tried to boot yet again with the same card the next day, after reading @SIGSEGV's answer, it booted! I can only suspect lousy contact on the card or something?..
@gprovost yes, of course I did. And believe that I explained clear enough at "which step".
Anyway all is well now, thank you for your help!

Thanks!
I could not respond earlier because forum allows to make only one post in the first day.
It is embarrassing, I am actually quite certain that I tried to boot with SD card and without it several times, and the result was the same (no signs of life). And I even wrote the image to the card again and tried again. But when I tried to boot yet again with the same card the next day, after reading @SIGSEGV's answer, it booted! I can only suspect lousy contact on the card or something?..
@gprovost yes, of course I did. And believe that I explained clear enough at "which step".
Anyway all is well now, thank you for your help!

I got my box yesterday and assembled it (looks gorgeous, and reasonably easy to assemble).
Without external power and with battery connected, green led 1 is on. With external power, orange led 9 in addition to that.
FTDI chip is recognized regardless of power status, I can connect to the console.
After pressing power button, green LEDs 2 and 3 and blue LEDs 4 and 5 light up immediately, and after that nothing else happens. Nothing on the serial console, no LEDs change status.
Tried disconnecting the battery. Then without external power, all LEDs are dark (but FTDI chip is still visible), with external power orange LED 9 blinks, the rest is exactly the same: four more LEDs light up on pressing the power button, and no other signs of life.
 
Looks to me as if either u-boot is absent / corrupted / inaccessinle, or the SoC does not enter boot mode.
 
No jumpers connected. There is no CR1225 (the board arrived without it. But with the 18660 pack).
 
Any advise? (I would be comfortable to play with low level boot tools).

Did you create a bootable microSD card?
The U-Boot image is not on SPI yet - so it needs it will look for it on the SD and eMMC - if you haven't written the image on either of these you won't get any output on the console.