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

[Angus Ainslie]

On 2018-12-27 8:19 p.m., Andy Green wrote:
>
>
> 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.
>
Hey Andy,

Long time no chat. Yeah it's pretty exciting working on this project.


>> 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.
>
Yeah we know it's deprecate. We've archived it until we can update the
process.

https://source.puri.sm/Librem5/vmdeboostrap


> 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).
>
Yeah we're in the process of getting the tools to pull everything from
Jenkins.
> 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.
>
When I'm working from the eMMC on the kernel I just have a couple of
scripts that copy directly from my build directory to the target. The
scripts also copy over the modules and devicetrees.

Cheers

Angus


> -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
>>