Thanks for info …as for the eMMC did anyone already had similar issues with the eMMC 0 ?
Hi thanks for the info ! Also what I see is that loading the kernel to RAM from eMMC is pretty slow only ~900 kiB/s
interesting, how are you measuring it? I am still trying to access some documentation that describe the controller but so far got no luck.
Personally I dont think the issue is just a quirk - not getting the end of data interrupt seems pretty fundamental - so maybe there is a misconfigured setting somewhere (which maybe bears a relation with the slow speeds that you are mentioning)
I also posted a couple of patches to enable ENV support in eMMC.
https://lists.denx.de/pipermail/u-boot/2017-November/310823.html
https://lists.denx.de/pipermail/u-boot/2017-November/310824.html
1 Like
Hi @Loic ,
using ext4load and load commands I was able to load the image and the dtb to the same addresses in your example: 0x90000000,0x89000000
running md indeed shows the right content:
for the dtb file:
dragonboard410c => md 0x89000000
89000000: edfe0dd0 de120100 38000000 e0050100 …8…
89000010: 28000000 11000000 10000000 00000000 …(…
89000020: fe0c0000 a8050100 00000000 00000000 …
89000030: 00000000 00000000 01000000 00000000 …
89000040: 03000000 29000000 00000000 6c617551 …)…Qual
89000050: 6d6d6f63 63655420 6c6f6e68 6569676f comm Technologie
89000060: 49202c73 202e636e 20515041 36313038 s, Inc. APQ 8016
for the kernel image:
dragonboard410c => md 0x90000000
90000000: 91005a4d 143f7fff 00080000 00000000 MZ…?..
90000010: 01366000 00000000 0000000a 00000000 .`6…
90000020: 00000000 00000000 00000000 00000000 …
90000030: 00000000 00000000 644d5241 00000040 …ARMd@…
then I ran as you wrote (mmcblk0p10 is my rootfs partition):
setenv bootargs root=/dev/mmcblk0p10 rw rootwait console=tty0 console=ttyMSM0,115200n8 rootfs=ext4 noinitrd selinux=0
but then the bootm still fails:
dragonboard410c => bootm 0x90000000 - 0x89000000
Wrong Image Format for bootm command
ERROR: can’t get kernel image!
Any idea what can it be ?
it’s actually my first time using u-boot.
Thanks
Hi,
just solved it by running booti 0x90000000 - 0x89000000 instead of bootm 0x90000000 - 0x89000000
Quick question, I’ve been seeing a great deal of movement in getting U-Boot supported on this plaform and I was wondering if there are any advantages of using U-Boot over the standard aboot bootloader?
Are there any gains in stability using U-Boot over aboot?
I doubt there are any gains in stability (not least because at present u-boot is chain loaded by the existing bootloader anyway). What you get are the various features u-boot can provide.
Most concretely u-boot has strong interfaces that distributions can use to update the kernel. That, combined with the almost complete upstream kernel support for DB410C, means that third party distros can provide a very complete feature set on DB410C (without having to use customized kernels): Overview of aarch64 SBC support in Fedora 27 – nullr0ute's blog
exactly what @danielt said 
for our own Debian images, we are planning to include uboot in the ‘default’ images as well. I don’t expect any gain in stability (arguably, adding more code, can only bring more bugs, not less). There is one nice thing we will gain with the Debian images, with uboot we will be loading the kernel image from /boot/Image (and the initrd as well). so it will be possible to upgrade the kernel like you do on any linux system today:
sudo apt update
sudo apt upgrade
reboot
Hi ,
where you able to solve the issue with the eMMC on the uboot ?
yes, with this patch
https://patchwork.ozlabs.org/patch/833376/
which I think has been merged in master now.
Hi thanks for the info , I have checked the denx master , but I don’t see it yet so I will apply it locally .
oops. sorry. you’re right…
Hi @anon91830841 , anyway I tried this patch what you suggested and there is no response from eMMC , so the only solution which is working is that from @ldts , but actually this causes that the download from eMMC is pretty slow…
Where can I clone the sources to the most recent version of U-Boot for the dragonboard 410c?
I’ve tried the sources at https://github.com/Mani-Sadhasivam/u-boot.git but I’m having trouble reading from the emmc.
are you sure you applied the patch on top of the master branch? for some reason MMC is under heavy validation in u-boot’s mmc feature branch (many changes are going in and some other patches are causing trouble hence why this particular patch hasnt’ been merged yet)
however it should work - it does work on all my boards- and it is queued for being merged.
can you try again? just pull the master branch from uboot ( git://git.denx.de/u-boot.git) and apply
Any one have trouble finding the MAC address for the WCN3620 when booting through U-Boot?
When successfully booted using this bootloader the wlan0 interface mac address is always set to 00:00:00:00:00:00
I’ve tried setting it using the example on qualcomm’s site with no luck: https://developer.qualcomm.com/qfile/29540/lm80-p0436-44_set_up_wi-fi_mac_addr_dragonboard410c.pdf
This is a link to the guide that I am using to test U-Boot:
https://github.com/96boards/documentation/blob/master/ConsumerEdition/DragonBoard-410c/Guides/uboot-linux-sd.md
EDIT: I saw this commit for lk regarding the local MAC address in the DTS, could it be that loading the kernel with U-Boot rather than lk cause this to fail? working/qualcomm/lk.git - [no description]
Hi @Rob_Gries
My apologies, I know that the document Setup WiFI MAC is out of date. Before I update the document, I have been waiting for the three operating systems to be updated to store the MAC addresses in a more permanent place in the eMMC so it doesn’t get lost every time you reflash the board. The MAC address storage problem has been on my list for a very long time and I have been harassing the teams regularly, it is now closer to resolution. Once it is resolved I will update the document.
Full Disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinions of my employer.
The upstream u-boot should work.
