[Librem-5-dev] U-Boot support for uSD

[Andy Green]

On 27/12/2018 20:40, Angus Ainslie via Librem-5-dev wrote:
> Hi Andy,
> 
> On 2018-12-27 12:09 a.m., Andy Green via Librem-5-dev wrote:
>> Hi -
>>
>> It seems my reasonably midrange for 2018 uSD (Sandisk Ultra U1 32GB)
>> cannot be brought up by U-Boot on the dev board.
>>
>>   u-boot=> mmc dev 1
>>   Card did not respond to voltage select!
>>   mmc_init: -95, time 29
>>
>> But there's no evident problem using that card on a Linux box via a
>> cheapo USB adapter.
>>
>> "Just me"?  Known issue not on the list of known issues[1]?  Any
>> recommended cards that do work?
>>
>> (Please don't send me to some non-scalable "chat"... let's get the
>> answer on the ml and in google... maybe even in the docs...)

Hey Angus, I hope you're well.  You have a cool gig here.

> If you are testing kernel changes you can use the SDP and an initramfs.
> 
> Check this page
> 
> https://source.puri.sm/Librem5/librem5-devkit-tools
> 
> Using the  "Create the initramfs" instructions you can specify a kernel
> path to get the modules from. Then copy the kernel "Image" into the
> files sub-directory and then use uuu ( SDP ) to upload and run all of it.
> 
> sudo uuu uuu_scripts/test_librem5.lst

Thanks... I use Fedora... it has debootstrap packaged, but not 
vmdebootstrap needed by the create_tarball script.  Googling around, in 
fact vmdebootstrap is deprecated, "vmdb2"[1] from the same author seems 
to be "the successor"[2], but this also is not in Fedora.

In short the official tools and flow require a Debian (or maybe 
Debian-ish like Ubuntu) build environment atm.  Debian is a great choice 
but if it's just building and testing the kernel, really that should 
have no dependencies on the build host distro.

(Also poking around on 
https://storage.puri.sm/librem5/binaries/unstable, although 
fetch-latest.sh supports using it, the unstable dir seems not updated 
any more since Sept, it should maybe be archived somewhere / removed 
from fetch-latest.sh by the look of it).

Although it must have been great during bringup now there are known-good 
eMMC images and eMMC works reliably, the flow of booting entirely from 
SDP with an initramfs is less crucial... at this point you usually want 
to know if the kernel works well with stuff on the eMMC rootfs. 
Pivoting from the initramfs with the modules in to the eMMC rootfs as / 
means losing access to the contemporary modules in the initramfs 
afterwards (unless there is some trick I missed).  So putting the temp 
kernel and modules on eMMC doesn't seem so bad.

-Andy

[1] https://vmdb2.liw.fi/ http://git.liw.fi/vmdb2
[2] https://liw.fi/vmdb2/

> Cheers
> 
> Angus
> 
> 
> 
>> Thanks...
>>
>> -Andy
>>
>> [1]
>> https://developer.puri.sm/Librem5/Development_Environment/Boards/Known_Issues.html
>> _______________________________________________
>> Librem-5-dev mailing list
>> Librem-5-dev at lists.community.puri.sm
>> https://lists.community.puri.sm/listinfo/librem-5-dev
> 
> _______________________________________________
> Librem-5-dev mailing list
> Librem-5-dev at lists.community.puri.sm
> https://lists.community.puri.sm/listinfo/librem-5-dev
>