eMMC/SD catch-22

[blonc]

Hello!
I'm a CS student getting into experimenting with Linux and have found myself in a difficult situation. After messing up my factory Debian install on the Pinebook Pro, I went to flash a fresh install of that exact image onto the eMMC again from an SD card, but this resulted in a boot loop, so I just decided to flash Bionic MATE onto the eMMC instead. I've found that I'm not the biggest fan of Bionic, and want to try other distros on the eMMC, but Bionic seems to have messed with the file(s) that tell the machine how to boot and caused it to skip over the SD card slot in looking for a bootable image. 

Now, if I boot with the eMMC disabled with the hardware switch, I can't make changes to the eMMC, even if I turn the switch back on after booting to the SD card. If I boot with the eMMC switch on, though, it always skips the SD card and boots to the eMMC, which means I can't make changes to what's installed there. 

I could really use some help in figuring out how I could circumvent this mess as I recognise that I'm pretty new to this whole scene and would love to get back on track in making and breaking Linux. 
Cheers!

[pfeerick]

[edit: sorry, my mistake, had a brain fart and was thinking of the A64, not the RK3399, where it's SPI -> EMMC -> SD]

That's shouldn't be the case... the SD card should have priority over the eMMC, so maybe there's something wrong with the image you have on the SD card.

If you're flicking the eMMC disable switch to boot form the SD, it's a time sensitive affair... you don't just disable the eMMC, boot from the SD and then turn the eMMC back on again... you basically need to flick it within a couple of seconds of the SD card booting. So try again, and see if you can get the timing right. Otherwise, I'm sure others will be along soon to help you along.

[blonc]

I've tried multiple different images on the SD, all etched with BalenaEtcher, none of which seemed to want to take precedence over the eMMC. I'll try disabling eMMC, booting to SD, and quickly turning the eMMC back on to see if I can get access to the "mmcblk1" dir to be able to write to it and see what happens.

[pfeerick]

Sorry, had to edit that... I was thinking of the A64 when I wrote that, where SD has priority over eMMC, but on the RK3399 in the PBP it's SPI -> EMMC -> SD, so you're basically in a pickle and having to either play with the disable switch, remove the eMMC and put it into a eMMC USB adapter and re-write it, or play with maskboot recovery mode (requiring an specific USB to USB cable)... not for the faint of heart!

I know on the RockPro64 there was a SPI bootloader that made it so SD had priority over eMMC (and also allowed usb and even PXE boot) but I don't know what the state of affairs for that is on the PBP. That would basically make it unbrickable though, as you'd always have SD boot priority.

[blonc]

I've just shelled out for an eMMC-to-USB adapter on the Pine store, so I'll keep tinkering around until it gets here and I can really get this thing taken care of. I'll update the thread as to how that all goes.

[PakoSt]

Check Xalius'es notes on the Discord channel about rescanning the emmc instead of fiddling with the timing. Same trick as the wifi killswitch.
DO NOT use the method on already mounted device.

But if you have the emmc usb adapter, go with it. Far more convenient and safe (as long as you don't overuse it).

[Arwen]

Here is a link to some instructions I wrote, (and someone else tested), to re-enable the eMMC if you miss the 2 second window;

https://forum.pine64.org/showthread.php?...9#pid54349

Eventually I will put it on the Wiki.

[tophneal]

You just need to write a new u-boot. (We should really put a warning on the wiki for ayufan's images about this.) Or a FAQ. You're not the first to experience this, OP.

ayufan's images all use an older BSP u-boot, that uses the soc boot order emmc>SD>mask rom. If you go to this section of the wiki, you can use the u-boots and scripts linked here: https://wiki.pine64.org/index.php/Pinebo...root_drive to overwrite the BSP u-boot. Both of the u-boot options there will place SD before emmc again. If you choose to use either script, open it up before running and verify that you have all 3 necessary files, and the names/script match. (Some have uboot.img, some have u-boot.img.)

[pfeerick]

ayufan's images all use an older BSP u-boot

WTH? When did this happen... talk about a step backwards!? It's getting close to two years ago that ayufan made the SPI bootloader available for the rockpro64 which would boot USB, PXE, SD then eMMC... which I would have thought was directly transferable to the PBP, as long as you don't mind no uboot display during the uboot phase.

https://github.com/ayufan-rock64/linux-b...ash-spi.md

[tophneal]

ayufan's images all use an older BSP u-boot

WTH? When did this happen... talk about a step backwards!? It's getting close to two years ago that ayufan made the SPI bootloader available for the rockpro64 which would boot USB, PXE, SD then eMMC... which I would have thought was directly transferable to the PBP, as long as you don't mind no uboot display during the uboot phase.

https://github.com/ayufan-rock64/linux-b...ash-spi.md

I agree, but I've seen several instances of this issue and that's the problem. It would have been nice to have USB booting right out of the gate, and hell, the PBP currently has no visual output (save through UART) during u-boot phase. Every time I've seen this issue, though, it's because the image has a different boot priority on its u-boot. After flashing the MrFixit u-boot, everything's great again.

Maybe he chose BSP u-boot to get going quickly and hasn't had time to revisit it? IDK, I can only speculate. @pcm720 has made a suitable alternative, swapping the PXE for NVMe. And it's available to flash to SPI.