openSUSE microOS (the Tumbleweed-based one) on Pine64: Intermittently hangs during reboots in "BIOS"
Hi all, I recently installed openSUSE MicroOS on a Pine64 (LTS or whatever it is called). Installation was a breeze, but now intermittently it hangs during reboots. It hangs in the "BIOS" boot phase, aka before grub is started and the OS takes over. I get errors like these when I open the serial console once I notice the hang: Unknown command 'jT)HL' - try 'help' => Seems like it fails to properly detect that there is no PXE/tftp to boot from and it should really boot from the sdcard. Or something else makes it stop the autoboot and enters 'jT)HL' as command. Unfortunately I failed to find proper instructions on how to disable PXE boot and nail it down to only boot from sdcard. Did anyone experience similar issues? Any ideas? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Johannes, On 19.11.22 13:24, Johannes Kastl wrote:
Hi all,
I recently installed openSUSE MicroOS on a Pine64 (LTS or whatever it is called). Installation was a breeze, but now intermittently it hangs during reboots.
It hangs in the "BIOS" boot phase, aka before grub is started and the OS takes over.
I get errors like these when I open the serial console once I notice the hang:
Unknown command 'jT)HL' - try 'help' =>
Is it possible that there is noise on your serial line? So that "hit any key to stop autoboot" in grub gets activated?
Seems like it fails to properly detect that there is no PXE/tftp to boot from and it should really boot from the sdcard. Or something else makes it stop the autoboot and enters 'jT)HL' as command.
line noise? Is the serial always connected?
Unfortunately I failed to find proper instructions on how to disable PXE boot and nail it down to only boot from sdcard.
I don't know about the Pine64, but I guess the first boot loader you can see is U-Boot. Reboot with the serial console connected and you'll probably see U-Boot reading bootaa64.efi from the EFI partition of your rootdevice and that is the GRUB2 binary. Before it loads grub, you can interrupt it on the serial console and then will be in U-Boot's shell. Check the u-boot documentation for details, but "printenv" will get you started with the current settings. On the raspberrypi, the u-boot config can actually be written to the "bootpartition" as u-boot.env file, if you are lucky the pine64 is configured similar (making for an easy way to save your old settings... and restore them in case you screw up...), but it is also possible that U-Boot env is stored in a flash partition of the device. In that case, copy-pasting the output of "printenv" to a safe place is something I'd recommend before you start playing around with it ;-) Good luck and have a lot of fun... seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hi Seife, On 19.11.22 at 14:17 Stefan Seyfried wrote:
On 19.11.22 13:24, Johannes Kastl wrote:
I get errors like these when I open the serial console once I notice the hang:
Unknown command 'jT)HL' - try 'help' =>
Is it possible that there is noise on your serial line?
It is not connected normally to any laptop or machine normally. I.e. the cable is just hanging around, connected to the Pine64 and not plugged in on the other end :-)
So that "hit any key to stop autoboot" in grub gets activated?
That would have been my guess, yes.
Seems like it fails to properly detect that there is no PXE/tftp to boot from and it should really boot from the sdcard. Or something else makes it stop the autoboot and enters 'jT)HL' as command.
line noise? Is the serial always connected?
No, not connected.
Before it loads grub, you can interrupt it on the serial console and then will be in U-Boot's shell. Check the u-boot documentation for details, but "printenv" will get you started with the current settings.
I found printenv, but that was just a lot of funny things where I have no clue what they could mean... :-)
On the raspberrypi, the u-boot config can actually be written to the "bootpartition" as u-boot.env file, if you are lucky the pine64 is configured similar (making for an easy way to save your old settings... and restore them in case you screw up...), but it is also possible that U-Boot env is stored in a flash partition of the device. In that case, copy-pasting the output of "printenv" to a safe place is something I'd recommend before you start playing around with it ;-)
Nice, thanks for the hints!
Good luck and have a lot of fun...
Thanks! -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Johannes, On 19.11.22 14:37, Johannes Kastl wrote:
Hi Seife,
On 19.11.22 at 14:17 Stefan Seyfried wrote:
On 19.11.22 13:24, Johannes Kastl wrote:
I get errors like these when I open the serial console once I notice the hang:
Unknown command 'jT)HL' - try 'help' =>
Is it possible that there is noise on your serial line?
It is not connected normally to any laptop or machine normally. I.e. the cable is just hanging around, connected to the Pine64 and not plugged in on the other end :-)
Then the first thing I'd try is to disconnect it on the Pine64 side also. I'm guessing you have a FTDI(?) cable connected which is unpowered if not connected to the PC? In that case, it might get parasite power from the GPIOs used as UART for the serial console and act in unpredictable ways. Just disconnect it, or add relatively low value pull-down resistors on TXD/RXD lines. Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hi Seife, On 20.11.22 at 00:23 Stefan Seyfried wrote:
On 19.11.22 14:37, Johannes Kastl wrote: Then the first thing I'd try is to disconnect it on the Pine64 side also.
I have tried that and it seemed to help, but today the machine was unreachable again. This time it told me that I need to load the kernel first, after grub loaded the kernel and the initrd. I'll dig deeper and report back. Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 22.11.22 at 16:22 Johannes Kastl wrote:
I'll dig deeper and report back.
I managed to properly set the boot order, so only mmc0 is being used. Thanks, Seife, for the hint! But apparently this board has a known issue where ethernet with GBit causes problems. Forcing this to 100MBit on the switch side did not solve this. I used a systemd timer that just brutally reboots the machine every 15 minutes. But after 2 hours of successfull rebooting it went unreachable again. I'll try to set the ethernet device to 100MBit via the OS too. Let's see if it helps. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 25.11.22 at 15:57 Johannes Kastl wrote:
On 22.11.22 at 16:22 Johannes Kastl wrote:
I'll dig deeper and report back.
Bug reported, as the boot intermittently fails with grub errors: Pine64: Intermittent boot errors with "../../grub-core/disk/efi/efidisk.c:602:failure reading sector 0x3786d40 from `hd1'." https://bugzilla.opensuse.org/show_bug.cgi?id=1205777 Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 25.11.22 at 20:39 Johannes Kastl wrote:
Bug reported, as the boot intermittently fails with grub errors:
This might have been caused by a USB stick that was attached to the Pine64. To me it looks like sometimes[tm] the devices are not found in the same order, so grub tries the wrong device. Why it even manages to start grub in this case is beyond me, so that might be totally not the problem. I removed the USB stick, so only the microSDXC card is present, that contains the OS. Next error: Sometimes to boot drops into the u-boot prompt, as no storage devices seem to be found.
U-Boot 2022.10 (Oct 04 2022 - 00:00:00 +0000) Allwinner Technology
CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB Core: 68 devices, 20 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0 Loading Environment from FAT... OK In: serial Out: serial Err: serial Net: eth0: ethernet@1c30000 starting USB... Bus usb@1c1a000: 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 Hit any key to stop autoboot: 0 =>
Typing "reset" reboots the device and suddenly the microSDXC card is found again and the device boots.... -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 19.11.22 at 13:24 Johannes Kastl wrote:
I recently installed openSUSE MicroOS on a Pine64 (LTS or whatever it is called). Installation was a breeze, but now intermittently it hangs during reboots.
Did anyone try to get this thing to only do a USB boot? If I identified my board properly and read the sparse documentation correctly, my board does not have a SPI flash. So it reads u-boot from somewhere on the microSD-Card. I wanted to get rid of the microSD card, as Michal mentioned in the bug report that there might be a bug in the mmc code in u-boot. But if I read the docs properly, I would need the sdcard to get to u-boot, which can then boot from USB. Not sure if this improves anything, but might be worth a try. Did anyone manage to set that up? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Sat, Nov 26, 2022 at 07:34:07PM +0100, Johannes Kastl wrote:
On 19.11.22 at 13:24 Johannes Kastl wrote:
I recently installed openSUSE MicroOS on a Pine64 (LTS or whatever it is called). Installation was a breeze, but now intermittently it hangs during reboots.
Did anyone try to get this thing to only do a USB boot?
If I identified my board properly and read the sparse documentation correctly, my board does not have a SPI flash. So it reads u-boot from somewhere on the microSD-Card.
If you need to boot from the SD card anyway it won't help much. It might be worth trying to enable watchdog in u-boot so the board reboots automatically if the boot fails. From the but report it sounds like the mmc boot is not reliable byt succeeds at least sometimes so the watchdog may make it boot eventually. Thanks Michal
Hi Michal, On 26.11.22 at 19:42 Michal Suchánek wrote:
If you need to boot from the SD card anyway it won't help much.
Yes, that was what I was fearing.
It might be worth trying to enable watchdog in u-boot so the board reboots automatically if the boot fails.
That sounds good.
From the but report it sounds like the mmc boot is not reliable byt succeeds at least sometimes so the watchdog may make it boot eventually.
I'll search for how to enable that, thanks for the hint, Michal! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Michal, hi all, On 26.11.22 at 20:14 Johannes Kastl wrote:
On 26.11.22 at 19:42 Michal Suchánek wrote:
It might be worth trying to enable watchdog in u-boot so the board reboots automatically if the boot fails.
I'll search for how to enable that, thanks for the hint, Michal!
Is it just me or is the documentation on u-boot... let's say, challenging? I find lots of funny lines that someone apparently has to add somewhere to configure/enable the watchdog. But I fail to find clear instructions what needs to be done where. It seems to me I need to somehow recompile u-boot with enabled watchdog? How do I use this on the Pine64? How does it end up in that special 8kB in sector 16 of the sdcard? If someone could point me in the right direction, that would be great. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 27.11.22 11:20, Johannes Kastl wrote:
Hi Michal, hi all,
On 26.11.22 at 20:14 Johannes Kastl wrote:
On 26.11.22 at 19:42 Michal Suchánek wrote:
It might be worth trying to enable watchdog in u-boot so the board reboots automatically if the boot fails.
I'll search for how to enable that, thanks for the hint, Michal!
Is it just me or is the documentation on u-boot... let's say, challenging?
"The code is enough documentation" :-P
I find lots of funny lines that someone apparently has to add somewhere to configure/enable the watchdog. But I fail to find clear instructions what needs to be done where.
It seems to me I need to somehow recompile u-boot with enabled watchdog? How do I use this on the Pine64? How does it end up in that special 8kB in sector 16 of the sdcard?
AFAICT from the build logs of hardware:boot/u-boot (checked flavours pine64plus and pineh64), the watchdog drivers are built. Also, your boot logs show that the drivers are available (at least that's how I interpret it): | U-Boot 2022.10 (Oct 04 2022 - 00:00:00 +0000) Allwinner Technology | | CPU: Allwinner A64 (SUN50I) | Model: Pine64+ | DRAM: 2 GiB | Core: 68 devices, 20 uclasses, devicetree: separate | WDT: Not starting watchdog@1c20ca0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ now the U-boot doc/usage/cmd/wdt.rst says different things about the "wdt" command, that you could play with. Note that the U-Boot "shell" might tickle the watchdog while it is interactively waiting for input, so to test if the watchdog triggers, you might need to create some kind of inifinite loop. If you found a command that starts the watchdog to your liking, you need to put this somehow into your boot command, before the mmc scan and grub load stuff is executed. You could also try to just put "reset" as the last command in your boot sequence, so that if booting fails (and without mmc and stuff it should fail?) the board just resets and tries again... But that will only help for the "it fails in U-Boot already" case. If it fails in grub2, then you'd need to find out how to make grub2 reset instead of dropping to the shell in case of errors. Good luck :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hi Seife, On 27.11.22 at 12:18 Stefan Seyfried wrote:
On 27.11.22 11:20, Johannes Kastl wrote:
I find lots of funny lines that someone apparently has to add somewhere to configure/enable the watchdog. But I fail to find clear instructions what needs to be done where.
It seems to me I need to somehow recompile u-boot with enabled watchdog? How do I use this on the Pine64? How does it end up in that special 8kB in sector 16 of the sdcard?
AFAICT from the build logs of hardware:boot/u-boot (checked flavours pine64plus and pineh64), the watchdog drivers are built. Also, your boot logs show that the drivers are available (at least that's how I interpret it):
| U-Boot 2022.10 (Oct 04 2022 - 00:00:00 +0000) Allwinner Technology | | CPU: Allwinner A64 (SUN50I) | Model: Pine64+ | DRAM: 2 GiB | Core: 68 devices, 20 uclasses, devicetree: separate | WDT: Not starting watchdog@1c20ca0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OK, I missed that. That looks promising.
now the U-boot doc/usage/cmd/wdt.rst says different things about the "wdt" command, that you could play with.
OK, that did not come up when looking for watchdog (for $REASONS).
Note that the U-Boot "shell" might tickle the watchdog while it is interactively waiting for input, so to test if the watchdog triggers, you might need to create some kind of inifinite loop.
If you found a command that starts the watchdog to your liking, you need to put this somehow into your boot command, before the mmc scan and grub load stuff is executed.
Thanks, now it seems a lot clearer.
You could also try to just put "reset" as the last command in your boot sequence, so that if booting fails (and without mmc and stuff it should fail?) the board just resets and tries again...
I'll give that a try.
But that will only help for the "it fails in U-Boot already" case. If it fails in grub2, then you'd need to find out how to make grub2 reset instead of dropping to the shell in case of errors.
I am not sure but I think since I removed the USB device the grub errors were fewer or absent. Let's see.
Good luck :-)
Thanks, I'll report back. Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 28.11.22 at 17:09 Johannes Kastl wrote:
now the U-boot doc/usage/cmd/wdt.rst says different things about the "wdt" command, that you could play with.
Meh. :-(
=> wdt dev Unknown command 'wdt' - try 'help'
Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 28.11.22 17:16, Johannes Kastl wrote:
On 28.11.22 at 17:09 Johannes Kastl wrote:
now the U-boot doc/usage/cmd/wdt.rst says different things about the "wdt" command, that you could play with.
Meh. :-(
=> wdt dev Unknown command 'wdt' - try 'help'
doc/usage/cmd/wdt.rst:The command is only available if CONFIG_CMD_WDT=y. So fork u-boot on OBS, add echo CONFIG_CMD_WDT=y >> .config before line 460 in u-boot.spec, check the macros to add to your prjconf around line 262 of the same and have a lot of fun... :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 28.11.22 at 19:42 Stefan Seyfried wrote:
So fork u-boot on OBS, add echo CONFIG_CMD_WDT=y >> .config before line 460 in u-boot.spec, check the macros to add to your prjconf around line 262 of the same and have a lot of fun...
Short update: As stated in the bug report, done, but I am missing a step. The package was installed, but the command is still available. I had no time yet to check on how to actually write the image to the proper sector of the disk (which I guess is what is missing, but again, no time yet).
https://build.opensuse.org/project/show/home:ojkastl_buildservice:u-boot_wit...
Seife had some hints on how to solve the grub errors (grub hanging waiting for a confirmation after $SOME_ERROR. Unfortunately sometimes grub just drops into a shell and I need to enter "reboot" for the device to reboot and boot again... Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Thu, Dec 01, 2022 at 01:07:20PM +0100, Johannes Kastl wrote:
On 28.11.22 at 19:42 Stefan Seyfried wrote:
So fork u-boot on OBS, add echo CONFIG_CMD_WDT=y >> .config before line 460 in u-boot.spec, check the macros to add to your prjconf around line 262 of the same and have a lot of fun...
Short update:
As stated in the bug report, done, but I am missing a step. The package was installed, but the command is still available. I had no time yet to check on how to actually write the image to the proper sector of the disk (which I guess is what is missing, but again, no time yet).
https://build.opensuse.org/project/show/home:ojkastl_buildservice:u-boot_wit...
Seife had some hints on how to solve the grub errors (grub hanging waiting for a confirmation after $SOME_ERROR.
Unfortunately sometimes grub just drops into a shell and I need to enter "reboot" for the device to reboot and boot again...
That's probably because it fails to load the config that tells it to reboot. There is another config built into the grub image that tells it where to load the config from, and you probably need a reboot at the end of that as well. If you add that debugging grub not finding a config will be difficult but it should always reboot then. Thanks Michal
On 01.12.22 at 13:32 Michal Suchánek wrote:
On Thu, Dec 01, 2022 at 01:07:20PM +0100, Johannes Kastl wrote:
Unfortunately sometimes grub just drops into a shell and I need to enter "reboot" for the device to reboot and boot again...
That's probably because it fails to load the config that tells it to reboot.
That was my guess, too...
There is another config built into the grub image that tells it where to load the config from, and you probably need a reboot at the end of that as well.
I take it that would mean building the grub2 package and tweaking the settings somewhere?
If you add that debugging grub not finding a config will be difficult but it should always reboot then.
Sounds like it is not worth the hassle to support the board. Even if grub2 can be modified to never hang AND u-boot can be configured to reboot instead of waiting forever, I may still end up with a device that will just boot forever and will not be usable in a normal way. Kind Regards, J -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Fri, Dec 02, 2022 at 10:42:08AM +0100, Johannes Kastl wrote:
On 01.12.22 at 13:32 Michal Suchánek wrote:
On Thu, Dec 01, 2022 at 01:07:20PM +0100, Johannes Kastl wrote:
Unfortunately sometimes grub just drops into a shell and I need to enter "reboot" for the device to reboot and boot again...
That's probably because it fails to load the config that tells it to reboot.
That was my guess, too...
There is another config built into the grub image that tells it where to load the config from, and you probably need a reboot at the end of that as well.
I take it that would mean building the grub2 package and tweaking the settings somewhere?
There is some grub2-mkimage or something to do that, you don't need to rebuild the package. Looking at how it is done during build might be helpful for producing similar results, though.
If you add that debugging grub not finding a config will be difficult but it should always reboot then.
Sounds like it is not worth the hassle to support the board. Even if grub2 can be modified to never hang AND u-boot can be configured to reboot instead of waiting forever, I may still end up with a device that will just boot forever and will not be usable in a normal way.
On one hand I would see it that way. On the other it exposes in the extreme the problems you would run into when trying to make a system reliably boot always, and the work you do here may be useful to others in other situations if you document it. YMMV Thanks Michal
On 02.12.22 at 11:51 Michal Suchánek wrote:
On Fri, Dec 02, 2022 at 10:42:08AM +0100, Johannes Kastl wrote:
I take it that would mean building the grub2 package and tweaking the settings somewhere?
There is some grub2-mkimage or something to do that, you don't need to rebuild the package. Looking at how it is done during build might be helpful for producing similar results, though.
OK, I'll try that if time permits.
Sounds like it is not worth the hassle to support the board. Even if grub2 can be modified to never hang AND u-boot can be configured to reboot instead of waiting forever, I may still end up with a device that will just boot forever and will not be usable in a normal way.
On one hand I would see it that way. On the other it exposes in the extreme the problems you would run into when trying to make a system reliably boot always, and the work you do here may be useful to others in other situations if you document it. YMMV
I will try to find some time to dig around. But the time might be better spent by adding paragraph to the Pine64 entry in the Wiki, stating the current (unreliable) state of support for this device. Kind Regards, Johannes P.S.: And if I did not mention this clearly enough: Thanks a lot for your help! -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (3)
-
Johannes Kastl -
Michal Suchánek -
Stefan Seyfried