I would not make the use of that switch a daily activity. Mostly because it probably isn't setup for a long amount of cycles and I don't know how abusive it is to the memory holding the BIOS. The BIOS memory should hold out much longer than the switch but still. I swapped from my Crucial 1TB CT1000P1SSD8 NVMe to another Intel 660p 2TB SSDPEKNW020T8X1 NVMe. It does boot slowly without requiring intervention from my few reboot cycles thus far. I'll keep posted on my findings if I make any breakthroughs (or if a newer BIOS release fixes my issues).
Can you try this fix in Win10 environment... When Windows is powered down, actually it's in "Hybrid Hibernation" state (for faster start-up) which is a sub-state of S4, not a true S5 state. Disable that feature, Windows then can go down to the full power down state. Procedure: Under PC settings, search "POWER", find the "Choose or Customize a Power Plan". On that page's left side panel, click "Choose what the Power buttons do". Click-n-check "Change settings that are current unavailable", Uncheck "Turn On Fast Startup (Recommended)". This disables the fast-startup mode and gets Windows to the full powered-down state.
So does Linux: https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/pm/sleep-states.html My point: trying to get OS to completely shutdown instead of any of these hybernation states, then give it a try.
I'm almost positive this is due to the NVMe compatibility. Since changes to the Intel SSD over the Crucial I haven't experienced any hangs. The boot cycle is EXTREMELY SLOW but it at least completes now.
The issue of the Bolt being stuck at b4 a0 on boot may be distro specific. Having previously used Fedora 31/32 without issue, I installed lubuntu 20.04 last night. After every boot of lubuntu 20.04, my bolt would stall at boot/reboot at b4 a0, requiring a uefi reset to work. I reinstalled Fedora 32 and have not had any issues. I wonder what Ubuntu is doing that is causing this problem. I may investigate if I have time. Interestingly, I also encountered the boot/reboot issue with my Bolt from simply using a Lubuntu 20.04 live usb before installing Lubuntu to my NVME.
I just reactivated my bolt after about a year. I was frustrated over the noisy fan and tossed it in a drawer until now (green dotted fan, just opened a ticket). I still had Ubuntu 19.04 installed on an nvme ssd and it booted normally. Unfortunately I only booted it once, but I can't remember seeing the boot errors back when I got the bolt. BIOS is still on original 1.04 rc2. I then freshly installed Ubuntu 20.04 lts and now I run into the same a0 state hang. I never touched the emmc, the other m.2 slots are empty. Hope that helps to further investigate the problem. If you want to know more specs that could be helpful I will try to deliver. @evaloverde is this issue still under investigation? Thank you.
Hah, tired of Udoo Org lack of help, I spent this weekend on this issue, and looks like I finaly solved it. At least I can reliable cause it and remove. It looks to me this is a bug in udoo bios (firmware) and is NOT tied to specific distribution. For example I have this problem after both Windows and Linux. The interesting, and confirming that this is a firmware problem, thing is, that if you have this problem you can do this: 1. power off udoo 2. remove all sata/ m2.b/ m2.a devices 3. boot udoo -> it will enter bios/firmware 4. power off udoo 5. add any devices you removed previously in step 2 6. you can now ONE TIME boot system from the device reattached in step 5 7. next reboot hangs Anyway, there are critical two things, which are NOT factory default, which you must change in firmware for udoo to boot reliably, there are: I. Advanced/CSM configuration/enabled + uefi + postponed 1. Being in the Advanced tab (second) 2. select 'CSM configuration' position (in the middle of the list) 3. ENABLE it, and configure options: a. only uefi b. postponed Here, enabling it is the crucial step, while 3.a and 3.b configuration steps are just done to minimize CSM mode impacting your boot process, hence not critical. II. Boot/new boot option policy = PLACE LAST 1. Being in the Boot tab (second to last) 2. change 'New Boot Option policy" from default to 'Place Last' Those two things, make my bolt boot reliably, using only UEFI boot loader. This is important (for udoo org): I'm NOT using CSM boot mode. I'm using ESP partition and EFI boot managers, yet without CSM being enabled bolt can't boot. Guys, could you please confirm that my solution also works for you?
Did this and rebooted twice, which is 2 more times than I've ever been able to do before. Kudos! And thanks!
No luck for me. The BIOS keeps losing the drive in the NVME section and coming back. Restarting doesn't usually boot successfully, it sits there and dumps be back in the BIOS screen.
Looks like you're having different problem. Original (b4/a0 hang) is when you can not restart (non responsive) and you can NOT enter bios menu EVEN after poweroff. THe only way was to factory reset bios or disconnect all storage devices. Sorry for your problem
@rdslw you're a wizard! Finally I can put the board in its case and off of my workbench. Thank you for sharing your findings. Will you inform udoo about this solution?
After a long time of trying to get my Bolt to work, it sat in a box until just recently when I needed a mini PC to run a few things. rdslw, you are awesome. After all the problems I had for so long, this was the thing that fixed it. I have now been able to boot and shut down 5 times without having to reset the BIOS. Kudos.
