Posts by frakkin64

    Might be time to try an alternative high capacity SD card so you can emphatically state that LE is having difficulties with them.

    I would agree this is a worthwhile test, if you have a fresh SD card of the same size it would be a good idea to load LE11 and test that it also has an issue.

    Even though it works with LE 9 and LE 10, you don't really know if it's kernel related or just happens to be the possibility that the SYSTEM image lands on a bad memory cell with LE11 and doesn't with LE10 or LE9. So, no need to say "but works on LE10 and LE9", this is my rationale on why it could still be an SD card failure. Although, I don't think that is the case here, because the kernel is failing to probe the card and don't think it has even gotten this far.

    SD card failure is the most likely cause of the problem. If the another similar size SD cards works with LE11, then you would want to do a destructive read/write test on the suspect card to confirm it.

    Is 'mmc' how linux identifies a small card, and 'sdhc' how it identifies a large card? If so, then it looks like the problem is that it's trying to read a large card as a small one, which would totally make sense.

    Those are just some of the driver components that SD cards (and even eMMCs) share, generally the driver will probe the device and negotiate the appropriate voltage levels and signaling that is supported by both.

    I don't know any other tricks, but based on what your describing it would seem to be a kernel issue. You'll want one of the Raspberry Pi engineers to help you further, those guys can guide you on how to turn on debugging to perhaps gather more information.

    I just know SD cards can be finicky, and paired with driver bugs it's hard for an end user to figure out because usually the error messages are pretty generic.


    TY for confirming. Can I run 'sudo rpi-update' or should I use the build number as frakkin64 suggested?

    The latest version is 6.1.19, so you should be OK with rpi-update. The reason I mentioned the commit is yesterday 6.1.16 was the latest and had wireless breakage.

    The number of RPi2/3 users on LE10 and LE11 is actually quite high, during the last year the overall userbase distribution has been quite stable at roughly 40% RPi4, 30% RPi2/3, 20% Generic/x86, 10% everything else.

    Interesting, I guess it goes to prove that the forums are really only about problems. :) Do you guys publish those stats anywhere?

    I might try this if I get time, but the fact that this is a VERY repeatable error (this same sd card works fine with LE9 and LE10 but once upgraded to LE11, fails) leads me to believe there's a change somewhere between 10 and 11 that affects it's ability to read larger sd cards.

    Hopefully a dev at some point who has an RPI3 and large SD card can give this a whirl and see what they find.

    Yeah, that's where the Raspberry Pi OS comes into play, if it happens there then you might get more help on the Raspberry Pi Github or Forums. I don't know what the installs look like with LE11, but the impression from the release notes is that most RPi3 users may not be upgrading due to the loss of HEVC accelerated decoding. But they will be running the before mentioned kernel on Raspberry Pi OS, and the problem is probably something in the kernel since what you provided shows the kernel is failing to detect the SD card.

    Meestor_X

    Exiting the "debug shell" resulting in a panic is normal, because the kernel can't mount disks. A few things to try:

    1. Try "blkid" and report back what that shows in the shell.

    2. Try "dmesg" and see if you can capture the output in any meaningful way, looking to see if the mmc is detected. Alternatively you can try to filter it down to things that say mmc or sdhc with "dmesg|egrep -i '(mmc|sdhc)'" (without double quotes). You can also try piping dmesg output into more with "dmesg |more" if you want to capture each page on the display with a camera.

    3. Try adding " sdhci.debug_quirks2=4" to the end of /flash/cmdline.txt (without quotes, same line). This drops 1.8V signaling for UHS cards and runs them at a lower speed, it's worth a shot if only to narrow down the problem.

    Lastly, it might be a good idea to test with Raspberry Pi OS and use "sudo rpi-update 889323" to bump to the 6.1.14 kernel (should be similar/close to what LE11 is running) and reboot/test to see. If it's a problem there, then I would report it over on their Github. You can also bump around different kernel versions on Raspberry Pi OS with rpi-update to try and pin-point where it started by using the commit id's from the commit log here.

    It doesn't seem like it is a known issue, or a common issue -- but one of the developers might be in the know. I only use Raspberry Pi 4's, and only 1 of them has a 128GB SD card (and it's using Raspberry Pi OS with 6.1.15 kernel) and no problems there. The rest are all 16GB or 32GB cards.

    LE as far as I remember never had a caching resolver, where as Windows has a caching resolver as part of the OS.

    I suspect it's probably always worked this way and your just noticing it now. Here is a thread from 2018 that talks about using the connman DNS proxy:

    osen
    July 26, 2018 at 2:46 AM

    It appears to be intentional to avoid user confusion.

    ah, yes, RTL8822BU would work, but not RTL8812BU...

    deleonkikko bad luck, try another wifi dongle.

    I have two of these, works with rtw88 driver from 6.2 + usb patches & fixes from wireless mailing list. I think those are all rolled into the Allwinner builds, so maybe it's just enabling the module or running a later image?

    This is from an RPi4 w/ the patches from 6.2 + usb patches from mailing list:

    Bus 001 Device 003: ID 2357:012d TP-Link Archer T3U [Realtek RTL8812BU]

    BTW, I don't know if usb.ids is right here, because I have always used 8822bu drivers but perhaps they actually support 8812 & 8822:

    rtw88_8822bu 16384 0

    rtw88_8822b 221184 1 rtw88_8822bu

    rtw88_usb 24576 1 rtw88_8822bu

    rtw88_core 147456 2 rtw88_usb,rtw88_8822b

    mac80211 749568 2 rtw88_core,rtw88_usb

    I think the Allwinner problem is this maybe:

    # CONFIG_RTW88_8822BU is not set

    Are you connecting from localhost? If not, you need to add in your network & subnet mask, something like

    CREATE USER 'kodi'@'192.168.0.0/255.255.255.0';

    MySQL :: MySQL 8.0 Reference Manual :: 6.2.4 Specifying Account Names

    On Samsungs make sure Input Signal Plus is enabled.

    1. Settings > General > External Device Manager > Input Signal Plus

    2. Choose HDMI port you Pi4 is plugged into.

    Reboot your Pi4, after enabling 4k60 in config.txt, and you should see the 60Hz refresh rate.

    The other thing you may want to do is disable motion smoothing, that is only available when a 4K resolution is displayed (and I think you have to adjust it for each refresh rate). That is under Settings > Picture > Expert Settings > Picture Clarity Settings, you will want that Off.

    As a side note, I personally have yet to see/find any content in 4k60.

    Is that the 4K (S905X) or 4K+ (S905D)? .. I'm still waiting on a positive test report to send it upstream.

    I have the 4K+, which we tested already and I am enjoying the labors with LE & Armbian. Just being lazy with the extra character, it's too far from my fingers. :)

    Sam did promise to submit the FIP sources for his boards at some point (prob. minus the BL32 bits, but those are optional) .. but then he's also promised to test the 4K (for six months) and send me samples (for two years) so I'm not holding breath. Running your own business is time-consuming

    Yeah, that would be nice to see. The FIP sources, maybe, are in Github -- but considering the last commit is 2017 and I have received bootloader updates since then I don't trust it's current. It's minus the bl32 bits, of course. All of the commits after Amlogic are purely cosmetic.

    Some of these differences are intentional; partly to align with LE standard namings, but also because we (me) don't want users "updating" from all kinds of unknown legacy images to AMLGX and then showing up with tricky-to-solve support issues. Boot is already "fun" before you factor in large Kodi major version bumps and the Python2 to Python3 change which causes add-on carnage.

    After digging through the whole u-boot process, aml_autoscript, etc. I can fundamentally see why you wouldn't support eMMC's at all on Android TV-boxes and not even touch them. It's a nightmare, you would have to format & partition the eMMC to be supported by mainline, you probably would have to replace u-boot, and it just starts piling up with bricking scenarios.

    I have only worked up the nerve to chainload mainline u-boot on the Vero4K, pretty reluctant to format the eMMC and load that mainline u-boot. And naturally all working from SD cards. It's just not worth it, so far I haven't seen an SD card failure, and I have weekly backups anyways of /storage.

    2. Once you initiate recovery boot to load LE the u-boot environment is tweaked to use LE boot files (else it won't boot). If you remove the SD card (or USB) and force recovery boot again it should rediscover the AE install. You can't swap between distros solely by removing the SD card.

    I don't know how AE or people format the eMMC. But on the Vero4K they still use the original Amlogic u-boot from Android, plus the Android partition layout, and if you go toothpick mode on it without an SD card in it (or a valid aml_autoscript) then it wipes the "instaboot" partition (it's in the u-boot script). The problem on the Vero4K is they take several (most) of the Android partitions and throw it into an LVM and use that as the root filesystem. I don't remember the exact scenario, but I have wiped instaboot many many times playing with LE/CE/Armbian and had to reinstall OSMC. :)

    Hopefully it's just a unique scenario with the Vero4K, easily fixed, but I know the u-boot sources are not complete (missing bl32) and doubting if there is other pieces missing (just because I see package updates in OSMC but no source code updates in their source tree).

    Anyways, the point of this meandering is to share that toothpick method can kill eMMC installs depending on whether they use the instaboot partition in a similar way.