@ldts, about Bluetooth address, note that property is no more local-mac-address but local-bd-address (driver uses local-bd-address) and with least significant byte first contrary to WiFi mac address. (e.g. BD address 00:11:22:33:44:55 => local-bd-address = [ 55 44 33 22 11 00 ]).
ah good to know. that is a patch for LK then
Oh yes, just see you decided to keep this stuff in LK, so think we are good 
well, we decided to leave it in LK for ‘backward compatibility’. but we don’t need it anymore. So I suggest we don’t ‘import’ local-mac-address in the BT node in uboot, only the local-bd-address.
just for completeness (in case you want to update your u-boot tree) this is what I am going to commit.
2 Likes
Quick question, does this still use the eMMC s/n to populate the local-mac-address property in the DTS?
If not, then does this require changes to LK to make this work?
yes, the LK does that .
https://git.linaro.org/landing-teams/working/qualcomm/lk.git/commit/?h=release/LA.BR.1.2.4-00310-8x16.0&id=c0026dd80f0cb26a0b32169e66837ea30796f218
yes …I tried also today with the v2018.01-rc2 from denx master . Could you tell me the commit hash that worked for you ?
you need this commit…
http://git.denx.de/?p=u-boot/u-boot-mmc.git;a=commit;h=c7e47ab0aa98da76824b6fa166fb02cfaa7284ad
the db410c (if you look at the device tree ) saves now the environment to the boot partition in emmc. Probably you are using two conflicting configs for you environment hence the warning …so that one is very likely a problem with your setup, not with uboot itself.
yeah, the performance is not great. that is a driver issue for sure.
ok so at least this part is clear . Anyway I think the eMMc is working on 52Mhz , is it possible to speed up to HS200 mode ?
yeah, I can put it on my list. but if you have time and interest have a look at
-
working/qualcomm/lk.git - [no description]
$ git grep HS200 (will show platform/msm_shared/… -
then replicate the relevant bits in u-boot (maybe a new file for the msm)
what do you think?
Hi I think that this make sense . Anyway I think the performance is even worst after this changes in driver
not sure I understand, what changes?
Hi sorry that was my misunderstanding…Actually I changed the rootfs from ext4 to ext3 and it’s much better with the performance . I have still one more problem I patched the dragonboard410c.h cause I wanted to changed the bootcmd , so I modified the CONFIG_EXTRA_ENV_SETTINGS , do you know maybe why uboot is ignoring this …? ( or maybe how to change it properly )
EXTRA_ENV_SETTINGS only affects the default environment and this typically only used to reconstruct the environment if it gets damaged…
From the logs it looks like DB410C stores the environment in uEnv.txt. Did you rememer to nuke that file after updating the build config?
PS I generally prefer to keep u-boot configuration stock and include writing to uEnv.txt are part of the board provisioning.
Looks like you are getting confused by the double partitioning of eMMC.
There are the boot partitions of eMMC and there is a partition on the eMMC called boot… and they are different!
Use gdisk to find which partition is called boot and the environment should be in the last 0x2000 bytes.
so if I understand it right in this scenario when boot partition is (nr 8) , the fw_env.config should be set like this
/dev/mmcblk0p8 -0x2000 0x2000
correct ?
this is the code relevant to the implementation:
This is the commit that introduced the feature:
https://lists.denx.de/pipermail/u-boot/2017-November/310823.html
and this is the db410 dts change
https://lists.denx.de/pipermail/u-boot/2017-November/310824.html
