[Buildroot] [PATCH v3 2/2] configs/beaglev_ahead: new defconfig

Giulio Benetti giulio.benetti at benettiengineering.com
Thu Feb 15 17:22:23 UTC 2024


Hi Kilian,

On 15/02/24 00:03, kilian.zinnecker--- via buildroot wrote:
> Hello Giulio, all,
> 
> [--SNIP--]
> 
>>> a/board/beaglev-ahead/patches/uboot/0001-Overwrite-bootcmd-by-force.patch
>>> b/board/beaglev-ahead/patches/uboot/0001-Overwrite-bootcmd-by-force.patch
>>> new file mode 100644
>>> index 0000000000..bcf5b965ce
>>> --- /dev/null
>>> +++
>>> b/board/beaglev-ahead/patches/uboot/0001-Overwrite-bootcmd-by-force.patch
>>> @@ -0,0 +1,30 @@
>>> +From 81db2d155db74192e127ae1d98dd4ec415f53dd3 Mon Sep 17 00:00:00 2001
>>> +From: Kilian Zinnecker <kilian.zinnecker at mail.de>
>>> +Date: Mon, 21 Aug 2023 23:51:59 +0200
>>> +Subject: [PATCH] Overwrite bootcmd by force
>>> +
>>> +This patch is a dirty hack: Trying to overwrite the bootcmd via the
>>> +usual BOOT_COMMAND had no effect: Upon boot the bootcmd defaulted
>>> +to some preset value and could not be changed easily. Therefore a
>>> +hook is used to force the bootcmd to be overwritten.
>>
>> This is strange because if so also the bootcmd content of uEnv.txt below
>> should be skipped, or maybe there is a bug in this u-boot that evaluates
>> bootcmd too early without taking into account environment variables.
>> But I'm also noticing that you have your Environment variables in Fat,
>> but it depends how u-boot deals with environment variables. Usually
>> you have to specificy an offset in memory where environment variables
>> live.
>>
>> But I see in your "make uboot-menuconfig" that CONFIG_ENV_IS_IN_FAT is
>> not enabled, but only CONFIG_ENV_IS_IN_MMC is and you have to specify:
>> CONFIG_ENV_OFFSET
>> CONFIG_ENV_SIZE
>>
>> So if you want to go with vfat way you need to enable
>> CONFIG_ENV_IS_IN_FAT and specify:
>> CONFIG_ENV_FAT_INTERFACE
>> CONFIG_ENV_FAT_DEVICE_AND_PART
>> and most of all:
>> CONFIG_ENV_FAT_FILE=uEnv.txt
>> in uboot.fragment below
>>
>> I would go with this last way instead of adding such dirty hack, can you
>> work on that?
> 
> I tried, but so far I am not successful, maybe due to my lack of experience
> with uboot or maybe due to the customization of this particular uboot. I
> removed my custom-uboot patch and added the following configs to the
> uboot.fragment file, but it did not work yet:
> 
> # CONFIG_ENV_IS_IN_MMC is not set
> CONFIG_ENV_IS_IN_FAT=y
> CONFIG_ENV_FAT_INTERFACE="mmc"
> CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
> CONFIG_ENV_FAT_FILE="uEnv.txt"

First of all you have to give a try using ush(u-boot shell) to see if
you can really access fat partition and read uEnv.txt file.
Like:
=> fatload ...
to a memory address

If that works then you should also:
=> printenv
and check if the variables you want to override look like expected

> 
> I also tried to use mainline uboot v2024.01, which features the Lichee Pi 4A,
> which features the same SoC, but this didn't work either. I had a look at the
> custom uboot source and it defines a lot of configs inside this header file:
> 
> https://openbeagle.org/beaglev-ahead/beaglev-ahead-u-boot/-/blob/beaglev-v2020.01-1.1.2-ubuntu/include/configs/light-c910.h?ref_type=heads#L363-388

This is a usual way for the these variables. You can dig into it or 
override them as you're trying to do. But you need to make sure uEnv.txt
is really read from your sd-card.

For example it could be a problem with CONFIG_ENV_FAT_INTERFACE name or
CONFIG_ENV_FAT_DEVICE_AND_PART numbering.
If you try using ush everything will be clearer.

> 
> I tried to remove the hard-coded bootcmd from this header, but that also
> didn't work. I don't understand the inner workings of uboot well enough yet to
> get it properly working, so I appreciate all hints and any help here.

Above there is some explanation. Anyway do all the tests without the
uboot patch applied.

> However, I will already send a v4 of the patches, in which I try to address
> all the other issues. > Thanks again for reviewing and best regards,

You're welcome, the goal is to make this patch looks the best it could.

Best regards
-- 
Giulio Benetti
CEO&CTO at Benetti Engineering sas



More information about the buildroot mailing list