@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.
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 …I tried also today with the v2018.01-rc2 from denx master . Could you tell me the commit hash that worked for you ?
Use the branch u-boot-mmc
you need this commit…
thanks , actually I think there is still problem with innit but with this solution at least it works , but if you look at those numbers , then performance is really slow ?
DRAM: 986 MiB
MMC: sdhci@07824000: 0, sdhci@07864000: 1
*** Warning - bad CRC, using default environment
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
552 bytes read in 11 ms (48.8 KiB/s)
17478144 bytes read in 59416 ms (287.1 KiB/s)
71502 bytes read in 121 ms (576.2 KiB/s)
Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 0000000083000000, end 000000008301474d
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
$ 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.
Hi thanks for the info…actually I have one more problem . I tried to modify the uboot env variables from the user space, so I compiled (openembedded) the fw_utils .So this works ok , but I cannot set the correct offset and address to read it after that :
This are my configs
#define CONFIG_ENV_SIZE 0x2000
#define CONFIG_ENV_OFFSET 0
#define CONFIG_SYS_MMC_ENV_DEV 0 /* mmc0 = emmc, mmc1 = sd /
#define CONFIG_SYS_MMC_ENV_PART 2
/ Size of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + SZ_8M)
when I will also #define CONFIG_ENV_IS_IN_MMC the uboot is not starting at all …but with this config it’s works. I’m not sure where the variables are stored after I run the saveenv ? cause when I looked in the /dev/mmcblk0boot0 the same as the mmcblk0boot1…they look empty…
root@dragonboard-410c:~# hexdump -C /dev/mmcblk0boot0
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
so I’m not sure what I’m doing wrong ?
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.