<peterm6881>
im creating a new note, whats the command to kill thew screen again , sry
<Xogium>
ctrl+a then K, then answer with y
<peterm6881>
thanks
<Xogium>
dinner time, bbl
<peterm6881>
ok interesting stuff happening with gadget
<peterm6881>
i dont think its power related, and its not the sd card
<peterm6881>
it gets stuck in a reboot loop until you connect via gadget
<peterm6881>
then it finishes booting
<peterm6881>
on uart0 it hangs at [ 1.617912] systemd[1]: Detected architecture arm.
<peterm6881>
with gadget connected, the point at which it starts the reboot loop is 8.456009] systemd[1]: Reached target Path Units.
<peterm6881>
its consistent
<peterm6881>
this is complex
<peterm6881>
ok on purely gadget serial connection with micro usb power, it doesnt boot until you connect to the gadget serial. Thats why it doesnt boot for me but it does for you
<peterm6881>
dunno if thats fixable
<peterm6881>
dont suppose we can ditch systemd ;)
<peterm6881>
160 milliamps by the way
<peterm6881>
yeah just to confirm
<peterm6881>
on uart0, powering via usb, it hangs completely at [ 1.764484] systemd[1]: Detected architecture arm.
<peterm6881>
if i power with a data usb cable as opposed to just usb power, on uart0 i get a reboot loop, triggered by [ 8.445707] systemd[1]: Reached target Path Units.
<peterm6881>
it keeps looping at that point until i connect via gadget, then it magically finishes booting and the software runs fine
<peterm6881>
its consistent. systemd on lichee gadget not happy
<peterm6881>
results are exactly the same if I power the board through the bridge. I can confirm the board doesnt care about receiving power simultaneously via the bridge and the micro usb cable. Current via the microusb cable drops from 160 milliamps to 120 milliamps, so the board is sharing the current between the 2 sources
<peterm6881>
so its safe for you to leave the bridge power wire in play, trust me on this
<peterm6881>
you should be able to replicate these results
<peterm6881>
I just dont know whether you will be able to do anything about systemd not liking gadget serial on Lichee
<peterm6881>
its bizarre it finishes fine once you screen onto the Gadget Serial port
<peterm6881>
finishes booting
<peterm6881>
so maybe its fixable
<peterm6881>
if you screen onto the bridge port and reset the device, you'll see the boot loop cycling. As soon as you screen onto the Gadget Serial port it will magically finish booting
<peterm6881>
you may have to connect to Gadget a couple of times, depending on where you catch the boot cycle
<peterm6881>
interesting, you get a shit ton of additonal, useful messages on Gadget Serial
<peterm6881>
Starting Play a bootup sound...
<peterm6881>
for example. They must be coming from the software...
<peterm6881>
great work getting this far with Gadget Serial though, thats very impressive
<Xogium>
wierd stuff
<Xogium>
never seen this before, orange pi was not buggy like this
<peterm6881>
exactly
<peterm6881>
do you still have an orange pi
<peterm6881>
so you're able to replicate
<peterm6881>
yeah orange pi is absolutely perfect, boots perfectly, connects to /dev/ttyACM1 no bother at all
<peterm6881>
let me know if theres anything i can check for you, perhaps to compare between the two
<peterm6881>
my orange pi is running identical Buildroot 22.02.4 and kernel 5.19.2
<peterm6881>
same as lichee
<peterm6881>
does any of this help:
<peterm6881>
I actually realized that systemd was stuck trying to clear the TTY, so it never even got around to starting agetty. The only way to unstuck the process was to set the TTY directives to no :
<peterm6881>
TTYVHangup=no
<peterm6881>
TTYReset=no
<peterm6881>
You can quickly override the existing service file like this :
<peterm6881>
TTYVTDisallocate=no
<peterm6881>
$ sudo systemctl edit getty@ttyGS0
<peterm6881>
And paste :
<peterm6881>
[Service]
<peterm6881>
TTYReset=no
<peterm6881>
TTYVHangup=no
<peterm6881>
TTYVTDisallocate=no
<peterm6881>
This can also be done manually by creating an override.conf in /etc/systemd/system/getty@ttyGS0.service.d :