trouble with eMMC on rock Pi4

1st Official Post

    Hi,

    I got a new rockpi4 and as the board does not fit into pentasata-tower with sdcard, I bought a emmc card with usb-adapter.

    USB-adapter claimed to be usefull to write images to emmc ...

    ... but the pi does not boot from emmc card. First I tried the self built image with my changes and got these errors:

    Then I thought: may be I made a mistake on image creation and tried a nightly image, which leaded to this output:

    So I searched the forum about emmc support ...

    ... and found many posts about install2emmc.

    Searching repository for install2emmc got 2 hits: one in procjects Allwinner and one in projects NXP :(

    So no support for rockpi?

    So I opened the source to see, whether I could migrate it to rockpi.

    But booting LE from sdcard shows no emmc card (as expected from script).

    So I continued searching and found radxa wiki.

    Nothing special there, so I followed the instructions.

    - I erased the spi flash

    - loaded and unzipped an image to debian (linaro)

    - debian recognized the emmc card, so I could write the image to emmc card

    - then reboot without sdcard

    -> same result as on second picture.

    What am I doing wrong?

    How could I bring rockpi to start from emmc?

    Hi,

    I did some more researches and found the "mount_flash" (from second error message above) in scripts for busybox.

    That means to me, that the boot-master (who is it?) already accessed the emmc and read the SYSTEM and KERNEL files and executed KERNEL.

    Is that right?

    But then I don't understand the error-message. The shorter UUID is from the tiny FAT partition, where KERNEL and SYSTEM reside. If they are already active, what could be the problem?

    I did some tests and when I boot from sdcard, I have no problem mount the partitions from emmc.

    so I stil have a big gap in understanding.

    I don't think, that I already understand your advice.

    So I searched for linux*.conf

    ... and I even understand less than before.

    From what I read at other postings, LE is 32bit, which means ARCH=arm ...

    ... but RockPi, which is Rockchip/.../RK3399 contains only kernel config for 64bit system.

    Anyway - I looked a .config from current kernel build and the only emmc related settings are enabled options. No modules in use.

    What else could I search for?

    Or may be I don't understand the boot process?

    Could busybox be used before current kernel is activated?

    Is my understanding right?

    extlinux is the last boot stage, which is activated by mbr, so when extlinux fails, accessing of media has already been successful.

    Is that uboot that selects boot media and that loads kernel and image?

    I tried writing uboot into spiflash, but when I removed all boot media, nothing happened.

    Where else could I search for informations/hints?

    • Official Post

    LE runs 64-bit kernel and 32-bit userspace (so widevine DRM libs work), so the =arm in the build command is correct, and the aarch64 kernel conf is also correct. The original problem is probably solved by using "boot=LABEL=LIBREELEC disk=LABEL=STORAGE" in extlinux.conf instead of the GUIDs; assuming LIBREELEC/STORAGE are the partition labels.

    Thank you for your help.

    I sadly have to say, that it didn't solve the problem.

    Just a different error:

    Guess I have to try a sdcard adapter.

    lsmod will list all loaded modules.

    In best case find the documentation which bus is used to connect the eMMC. PCI, USB ...

    lspci -k and lsusb may be useful to get additional information.

    Edit: Wrote this before reading your post. If systemd is to be loaded the FS is mounted and "something" was read before from eMMC.

    Edited once, last by mglae (May 2, 2021 at 3:59 PM).

    Thank you for your attention!

    Wiki tells about problems if mbr partition tables are used, instead of GUID partition tables. I guess, extlinux needs mbr partition tables. Wiki recommends clearing spi-bootloader - and I followed that instructions.

    lsmod output is really poor:

    Code
    $> lsmod
Module                  Size  Used by
autofs4                40960  3

    there's no lspci and lsusb does not help either.

    The only difference so far is by looking at the device links (mmcblk0 is the sdcard and mmcblk1 is the emmc):

    similar differences looking at their path:

    I tried to compare kernel config files from debian and LE, but first, I don't know enuf from kernel development to verify the changes and second - debian uses kernel 4.4 where as LE is at 5.10 ...

    Quote from chewitt

    LE runs 64-bit kernel and 32-bit userspace (so widevine DRM libs work)

    Hi, I had to search for widevine - I read it at several postings, but didn't know what it is all about.

    From what I read, widevine is a library to bypass drm protection. Right?

    Is that the only reason for LE to be 32bit system?

    I'm not sure, but I would state, that I don't have any drm content.

    Yesterday I tried armbian buster - and it boots from emmc without any special treatment. Writing image to emmc with balena, plug it to the pi and power it on - armbian boots just fine.

    Looks like armbian is 64bit system and with quick tests, videos from youtube play pretty well.

    Don't know, if I got it right. I read that video decoding from browser/youtube is done in software only. So if those videos play well, how much better would be those with hardware decoding support.

    I'll keep on testing :)

    • Official Post

    RPi Foundation need to support a large and diverse range of devices that until RPi4 were all 32-bit. To keep things simple during initial bring-up the kernel driver support for RPi4 (which is 64-bit capable) was kept at 32-bit. Now that development has shifted from hoarding a huge collection of downstream patches for a 32-bit kernel to upstreaming everything to 'the' kernel, it's increasibly viable to run a 64-bit kernel, but it is less tested and proven. For LE's use-case a 2GB RPi4 is fine, so while the majority of users purchase the 4GB model (and a minority the 8GB) there's no real-world need for LE to run RPi4 with a 64-bit kernel and the RPi Foundation would prefer we used the 32-bit version until they finish porting/upstreaming drivers. In many other ARM SoCs we support the kernel is only available as 64-bit so that's what we use; but we use 32-bit userspace with all ARM devices to leverage libwidevine so users can watch software decoded Netflix and Amazon (as there are no 64-bit libs). On RPi4 YouTube (via Kodi add-ons) plays 1080p H264 hardware decoded already so there's zero advantage from using 64-bit software decoding.

    TL/DR; You aren't going to make a eureka discovery of some RPi4 performance/optimisation trick we (or the Pi Foundation devs) missed.

    Quote from chewitt

    TL/DR; You ...

    What does TL/DR mean?

    I guess, you got me completely wrong. I'm not hunting for the ultimate optimization.

    I have a (short) list of features, I'd like to see on my rockpi box and respect to multimedia/video LE already fulfills all my needs.

    But LE does not start from emmc, has no fan control and no nfs-server.

    So that's what I'm searching support for.

    I don't really care about 32bit or 64bit - whatever works is fine.

    Therefore I mentioned armbian and youtube - it shows, that (some) video work fine on my rockpi box even without hardware support. Opposed to that, youtube don't run on plain linaro supported from radxa.

    DRM-support is not on the list of my requirements, therefore I'm open for new ideas.

    For me the completeness of my featureset is important. As all problems require skills, I don't have, I have to search for help/external support.

    Thank you for that translation :)

    My oppinion:

    When you ask for advice, the very least you can do - at least for me - is to read the answers in full.

    For me, anyone who doesn't do that is superficial, stupid and rude.

    So I definitely read all the answers I receive. Unfortunately, this does not mean that I understand all the answers in their entirety.