I am using a 128 gb sd card. but I have also tried with an 8gb pendrive. they all do the behavior mentioned above. (But thats my problem)
Install on a 64 GB or 32 GB SD card.
the 64gb version works, the 128gb not. so seems like - if there are problems with 64gb - the one i have is not affected.
thats why i bought the A2 sandisk because it should be faster than the old ones i have, unfortunately smallest size is 64gb and i have chosen 128 because price per GB.
but no matter how big the SD, it should never lead to a segmentation fault, right? I am not a dev but afaik this should never happen (e.g. double free, access of a freeâd pointer etc.)
I think the issue is bad XHCI implementation in u-boot which prevents booting.
can i somehow help in fixing this? or is this even fixable?
Iâve never had any issues with a 32 gig or smaller ,others have success with 64 gig
And others have success with USB Drives,I have an older WD My Passport 500 gig ,reformat as exfat/fat 32 ,CoreELEC boots
Maybe try from start with the 128 gig, format a couple of times, then clean install
Maybe will work 
Why not just use the 64 gig ?You are success, and plenty of storage!!!
Happy Testing
From previous experience I just stick to 32 or 16. Even 4 works 
Exactly !!
Depends on User ,and what they have readily available
Manufacturers needs to fix the bootloader. And I doubt it would happen.
As I wrote: it depends on a USB stick type and not size specifically.
1 Like
thanks for clarification. I assume there is no list with compatible/incompatible SD cards?
I have this one with 128GB: SanDisk Extreme microSDXC UHS-I Memory Card 128 GB + Adapter: Amazon.de: Computer & Accessories - when i buy the 64GB version, it will most likely not work too, right?
Can you tell me why the bootloader needs to be fixed? Is it the thing that segfaults (bl301 blob)? Because i see[1] the logo of NO when this bootloop happens, which looks to me i am past the stage of bootloader. Maybe i am misunderstanding something.
[1] i was iirc even inside kodi but was not able to control anything, need to check that if the info is correct, if that helps in any way
You see logo? Then this is some different case which I didnât saw.
In my case using SanDisk Cruzer Ultra FIT 32/64 GB, USB 3.1 Gen 1 it stops early in u-boot.
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... XHCI timeout on event type 33... cannot recover.
BUG at ../drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
BUG!
resetting ...
If you get it booting then just look around in dmesg what is happening.
https://www.youtube.com/shorts/sT1kihkjHGE - i made a short, maybe that helps to show what is happening. If its not the bootloader, how can i get the dmesg info when it crashes so fast? Unfortunately, its a real reboot, not only a kodi crash 
Maybe you would see something useful on serial console adapter.
it seems to me there is no serial console that is exposed, so i can not use it. i assume that it crashes after the OS is loaded but before kodi is started. i have read/write access to the sd, so maybe i can create some sort of start script? or is there some way to disable the loading of kodi, to see if its really kodi thats leading to the reboot?
this is the segmentation fault i was talking about:
this happen when i put something on the SD in .updates
This is just something wrong with inject_bl301 binary which is executed as part of update process.
It has nothing to do with USB stick type or size. Totally different issue.
Ok, thought maybe thats somehow related.
Is it somehow possible to mis-use the update process to create the dmesg output, write it to e.g. storage/dmesg.log and then when it crashes, i could remove the SD, plug it in my workstation and read that?
This is confusing.
The segmentation fault above is harmless. Which device is this? Maybe you should not use inject bl301 on it at all.
The bootloop is different story. Is it happen with this same device and stick where update works? But normal boot doesnât? How do you even update in this case?
Its an Ugoos AM9. I have 2 SD cards, one âslowâ with 64GB where everything works. I also have a better/faster one with 128GB. I flashed to the 128GB one the latest NO nightly and booted it. It resizes the partition and then does the reboot. When thats done, i encounter this boot loop.
I can remove the SD, put it in my workstation and put something in .update, this is executed when i boot it.
I dont know how i could not use inject bl301, because thats part of NO, isnt it?
So the one SD card with 64GB works perfectly fine, but the 128GB one does not. I flashed couple of times, its always the same behaviour.
I should do only one thing at the time. I though we are talking about USB and not uSD cards.
Anway, on first partition is file config.ini. Add this at the end of the file
coreelec='nopkmute nosplash debug loglevel=8'
Maybe you will see something on a TV (make a photo at the correct time).
/usr/lib/coreelec/check-bl301 works fine on my device without segfault.
i added coreelec=ânopkmute nosplash debug loglevel=8â to the config.ini.
When i boot now, it does show only the screen from the chipset (this AV1 S905X thingen) and then the TV shows signal lost. I will try with nosplash and textmode. nosplash and textmode produced nothing except that chipset logo.
Out of curiosity i replaced my usb->sd-writer with another one and also replaced the SD (i ordered 2 of those), just to make sure its not a hardware fault. I write them with dd. Unfortunately, same behaviour.
tried it with coreelec=âdebugging textmode nosplash sshâ but i can not connect with ssh and the only thing the TV shows is this:
