Micro-SD card boot hack for CorePure64

[PDP-8]

Got my UEFI-only box that has the capability to boot from an onboard micro sd-card slot to work with CorePure64 - BUT in an unusual way.

Warning - the following is an impromptu exploratory hack .. not from someone who truly knows what he is doing.

Environment: I wiped Windows 10 from my little coaster computer's eMMC, a Wintel 8 Pro and put a Debian Live Raspberry-Pi-Desktop on it.  Ok, boots fine.  In fact, it will also boot fine from a micro-sd card when directed to boot from that.  Ok.

That computer also boots a usb-stick which I made following Juanitos dual-boot for UEFI instructions, although I left out the dual-boot part.  Just uefi only.  Works great.

However, there seems to be no mmcblk filesystem support after boot.  (Unless I'm just missing something in grub.cfg?)

Fine - no mmcblk support means I won't accidentally wipe out my Debian RPD desktop on the internal eMMC.

THE BOOT HACK:
I just dd'ed the working bootable corepure64 usb stick to a micro-sd card.  IT BOOTS!

I'm a little freaked out thinking that UUID's might be messed up now being on a dd'ed micro-sd card, but it seemed to pull though anyway.

HOWEVER:  with no mmcblk support, of course after boot it can't find my TCE directory on the micro-sd.  BUT, it was easy enough to reboot, but this time have my working usb-stick attached, which does have the tce directory, but only use it for persistance and not booting - leaving that chore to the micro-sd card.

In other words, this is kind of neat - similar to read-only cd type operations - the micro-sd card boots corepure64, but immediately afterwards, you just can't mess with it because there is no filesystem support.  Ie, there is NO chance to mess with it once boot is over.

Ie, I can't mess up my internal eMMC.  Nor can I mess up my micro-sd card mmc device either!

I kind of find this a fascinating option not having (or me not configuring it properly) any mmc support.  But it will boot corepure64 from one on my uefi only box, even though I have to treat it like a cd kind of environment.

[PDP-8]

I think I found my issue:

lsmod reveals that the mmc_core module is loaded.

However, running

Code: [Select]

dmesg | grep MMC
reveals this troubling message:

Code: [Select]

acpi PNP0A08:00 [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge.
Ok.  On the list to study up and find out why!

[vinceASPECT]

Hello Forum,

Yes, Laptops have SD card slots and also the SIM card for Telco 3G internet,

The media can also serve as the storage "memory" feature  (upon power OFF one boots and has retained earlier work and OS  state.

Thx

V

[PDP-8]

Hmm..  running lsmod on the Debian live that does boot via sd-card if I want it to, shows the same warnings in dmesg, yet it sees *mmc devices.

Looks like what I need is
mmc_block
sdio_uart (maybe)

kernel modules.  Ok, I could ask for that, or just recompile my own kernel if I want it badly enough.

Some study reveals that there are some pretty poor implementations at the bios level for mmc support, (memory ranges getting overwritten and such) and using that for actual block-level filesystem support might not be the wisest idea.

Hmm .. perhaps I'll ask for an end-user mmc_module_extensions.tcz for those that want to risk / test it.

[Juanito]

Code: [Select]

$ ls /lib/modules/4.19.10-tinycore/kernel/drivers/mmc/core
mmc_block.ko.gz  mmc_core.ko.gz   sdio_uart.ko.gz

[PDP-8]

Thanks Jaunito!  It was right in front of me all the time...

Note:  I tried to depmod and insmod these, but the mmc hardware still wasn't getting detected for some reason.

However, on an Intel NUC, mmc devices were immediately recognized without any user-interaction.

Heh, hardware - what a pain sometimes.   Not a showstopper, but thanks for pointing out those kernel modules as standard with the system.

[Rich]

Hi PDP-8
Someone gave me an ASUS T100CHI to play with. Tinycore doesn't pick up the eMMC on it either. Booting a live Debian Buster ISO
does pick it up.

... However, running

Code: [Select]

dmesg | grep MMC
reveals this troubling message:

Code: [Select]

acpi PNP0A08:00 [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge.

I see the same message in both Tinycore and Buster.

In Tinycore I find this:

Code: [Select]

[    1.143810] mmc0: SDHCI controller on ACPI [INT33BB:00] using ADMA
Buster has this:

Code: [Select]

Dec  5 21:43:01 localhost kernel: [    5.008749] mmc0: SDHCI controller on ACPI [80860F14:01] using ADMA
Dec  5 21:43:01 localhost kernel: [    5.009623] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
Searching for  linux int33bb  suggests enabling this in the kernel config:

Code: [Select]

config X86_INTEL_LPSS
bool "Intel Low Power Subsystem Support"
depends on X86 && ACPI
select COMMON_CLK
select PINCTRL
select IOSF_MBI
---help---
  Select to build support for Intel Low Power Subsystem such as
  found on Intel Lynxpoint PCH. Selecting this option enables
  things like clock tree (common clock framework) and pincontrol
  which are needed by the LPSS peripheral drivers.
It's enabled in Buster but not in Tinycore.

[PDP-8]

I think you nailed it!  Check this out:

https://unix.stackexchange.com/questions/251376/no-dev-mmcblk0-during-boot

Exact scenario, and the last message confirmed it.

What can be really confusing is that one can initially boot from it, even if it or other mmc devices are not recognized immediately after.

Most normal people, not seeing any mmc's, wouldn't even try booting from the device, but I did.

Maybe we can request that CONFIG_X86_INTEL_SPSS module for a possible 10.2 update of TC?

[curaga]

Not for 10.2, but for 11 sure.