Overall I'm really loving the RockPro64 and running real, full (as can yet be) Slackware on it. However I need to be able to boot other systems and don't want to mess with a serial console so it appears, due to USB (meaning kbd and mouse) being disabled during the boot process, that limitation has seriously curtailed the ability to boot anything else.

For a time I could circumvent this limitation by snapping an eMMC drive in place and it would default to the boot process on it but suddenly, and for no apparent to me reason, my eMMC will no longer boot. It goes right to the SD card Slackware boot.

I'll never give up Slackware and in fact my interest in other distros is to find out what I can adapt from things like OpenMediaVault and distros running cockpit or Webmin to be able to use Slackware as a true NAS with Web interface.

What could possibly have changed? I have read that eMMC can be a bit fragile but can they lose their boot record while keeping everything else? I tried reflashing OpenMediaVault and it still would no longer boot so I think the drive would have to be physically damaged unless there is some quirk in RockPro64 that, say, internally affects boot defaults just like the "disable eMMC" jumper or something like that.

On the upside my old, retired External eSATA Dual Bay Enclosure with a 50-60 watt PSU and killer 80mm Fan is working like a champ. More than enough power for the RockPro64, serious fan, PCIe 4-port SATA card, 1xSSD and 2xSeagate 2TB spinners. NFS works but it would be like falling off a log with a web interface.

Any suggestions gratefully accepted. Thanks.

Can't help with your question but I can say Yes to above. I have something going like you in old desktop case.

You need to edit the boot_targets variable at the command line of U-boot. Which has to be done over a serial console.

Slackware defaults to boot from the sd card. So if you have an sdcard in the rockpro, the SPI flash will load that first. Write the image to the eMMC you wish to boot. Then remove the sd card while powered off. Finally, you will need to modify the extlinux.conf to boot the eMMC and point it to the relevant boot partition bits. I haven't heard of anyone dual booting on single boards like is possible on x86. The easiest course of action would be to just swap out the sd card with the operating system of choice.

While I really would rather not have to resort to serial console I suppose I will have to but please tell me why it EVER booted from eMMC AFTER installing full Slackware, just by popping out the Micro SD card? It worked that way at least for a dozen, maybe 2 dozen, boots with 3 different distros on it (OpenSuse, Manjaro, and OpenMediaVault). I accept that computers only theoretically do the very same thing exactly the very same way every time but geez.

What you are saying is that the other distributions will not boot now off of the eMMC? Even without the SD card plugged in?

You did write u-boot to the SPI Flash during the Slackware installation process, correct?

I boot different images on various other SD cards just fine with the Slackware U-boot binary in SPI flash. I do so on the Pinebook Pro, but I do not dual or triple boot. Technically, it should work with the eMMC as well. The eMMC can be unreliable and this is why it's not recommended as a boot medium for Slackware in the documentation.

Yes. Obviously I had to flash SPl to allow AarchSlackware installer but I also allowed the installer to re-flash as recommended.

Correct. At first removing the MicroSD and inserting an eMMC would boot that system instead. Occasionally, and I think it was if I issued "reboot" or "Ctrl-Alt-Del" it would try to boot from SPl and fail (of course since the /boot in the MicroSD was not present) but resetting or powering off and back on would boot the eMMC. Now (and I don't have a clue as to what has changed unless more was changed with the recent upgrade to allow more than just the Slackware Logo to display <hmmm..which could be I suppose>)
the only thing that ever comes up no matter what I do is the page with the Slackware Logo. Nothing else will boot.

Yes I am aware that eMMC is not especially rugged so that is high on the list for inquiry but it isn't dead. I have used both cfdisk and GParted to clear the eMMC and etcher to write images to it at least a half dozen times with zero errors. OpenMediaVault for example creates a half dozen pseudo partitions as part of the BTRFS process and all seem to transcribe with no errors from etcher with error check enabled.

Maybe I'm just avoiding the somewhat long process of reinstalling to get back to the original Uboot image without the logo to rule that out as a possible hiccough but if so I will probably do that a little longer, especially since you apparenlt can still boot from eMMC after the upgrade. I love the logo but I'll forgo that brief pleasure if it somehow prevents function.

How is it not booting? What is the text on the screen? Did you try booting from an SD card without the eMMC attached to the board? As a test, does the Slackware installer boot?

An easy way to erase u-boot and flash it onto a separate sd card is with a recovery image, located here:
https://slackware.uk/slackwarearm/pl...covery/rk3399/

That should bring you back to a "known" good state in u-boot. All it does it start up u-boot, erase SPI Flash, then install u-boot to SPI Flash once more.

HOWEVER, you will need to configure u-boot if you take this step. That is typically done by serial console.

Once u-boot is installed, it should pick up the files on your SD card in /boot and start up Slackware.

Hello again mralk3 and tyvm for your responses. I respect that you're a busy man and this level of support is phenomenal. Trust me, it won't go unrewarded.

Slackware boots perfectly fine on my Rockpro64. That hasn't changed. It's just that it used to (excepting the conditions I mentioned in last post) boot the eMMC If and When BOTH the eMMC was installed and the MicroSD was disconnected. Now, it always tries to boot Slackware which obviously is unsuccessful when MicroSD is removed but returns w/ no faults when SD is reinserted, whether the eMMC is connected or not.

It looks like I should probably buy at least one new MicroSD and possibly a very high quality eMMC so I will do that today. At least that will inform me if my existing eMMC has some problem. Whatever turns out to work my goal is to have Slackware as my default always but be able to test out many other systems. The USB disabling during Uboot is a serious hassle since some systems, like OpenSuse, employ Grub as a bootloader (which is kinda nice... kernel selection as well as Recovery and multi-boot options) but is useless if keyboard is a null function, no selection possible. FWIW Grub and menu selection did work until the Slackware flash. How bad is that USB bug?

I'm also looking into trying a laptop display on the eDP header but that's a whole other thread for the future. Thanks again.

EDIT: Well Damn! an additional MicroSD won't boot either. I tried an eMMC-to-MicroSD adapter and always the Uboot/SPl looks for Slackware Boot SD. Guess I have to wait on new eMMC

Some good news. I rebuilt u-boot, recovery images, and an SD card image using the Slackware build scripts. I enabled the USB Preboot configuration option and it looks like USB is working in u-boot. I tested on my Pinebook Pro and it works. I booted the recovery image and let it erase spi flash and reflash it with my u-boot image. What this does is erase anything saved within SPI Flash. It does not touch the eMMC or any other storage device, including the sd card. Then rewrites the new u-boot image stored within the archive.

In the early days of the Aarch64 port we ran into a lot of these type of quirks. Which is why the recovery images exists. You should be able to see progress if you attach a monitor to your RockPro64.

Here you are: https://slackware.uk/slackwarearm/people/brent/testing/

Make sure you use the RockPro64 recovery image. Wait a few minutes for the SD card image. My network connection is very slow when uploading.

That's a rather major upgrade, Brother. Thank you.

(5 minutes later)

On 2nd thought I'd better go over this so I'm certain I understand.

So 1st step is naturally make certain Monitor is on and connected (HDMI is OK if I understand the rest, right?)
The rest is much like initial Slackware install steps, that write to the SPI, yes?
So I wipe my boot MicroSD (or use a new one) and install the "flash-spi-rockpro64,img as before but with this new .img.
Then I connect a jumper between pins 23 & 25 on the pi header like before and start it up.
Message appears giving me ~30 seconds to remove jumper and flashing will begin... wait to complete.

Then I re-flash my MicroSD with the image I saved of /boot before I started this... (Clonezilla OK?)
Reinsert MicroSD and now USB will be operating for boot selection.

Man! That is way cool.

1 members found this post helpful.

I don't know if this will solve your problems, but it should make it easier to use the SD Card file extlinux/extlinux.conf as a way to dual boot. You would have to store the boot files for each distro on the sd card. Partitioning should be similar to x86 for any other storage devices. I have removed the eMMC from my Pinebook and RockPro. If I have time tomorrow I may try to test against the eMMC to see what is effecting it.

Cool! The MicroSD and eMMC are both from ameriDroid seem to be very good quality and substantial storage so the boot files should be no problem.. The eMMC is extremely fast as well. My case (a re-purposed drive bay) isn't the greatest for getting at eMMC connector and SD slot but it's great for cooling, power, and RAID and I'm not having any problems mixing LABEL and /dev/foo in fstab so far. This is gonna be fun!

You can boot the SPI flasher and it will take care of writing a good u-boot. Peripherals should all work the same as x86. I didn't have to jumper the Pinebook, but yes, that is the process. "Nullifying" SPI flash until the SD image that contains the new u-boot boots up and overwrites the flash. Reboot, remove SD card, and replace the contents of the SD card with the installer image. Then just follow the steps outlined in the documentation on slack docs.

I am uploading new spi flash recovery images and a new generic rk3399 installer image to my user directory on slackware.uk.

I tested on the RockPro64 and Pinebook Pro this morning. USB works in U-boot on both hardware models.

Are you saying I will need to reinstall Slackware that currently works on SATA? or just /boot on MicroSD?

Don't get me wrong. I'm not adverse to re-installing. I just will want to know before.