On 04/29/2018 03:53 PM, Lukasz Majewski wrote:
> Hi Marek,
Hello Lukasz,
>> On 04/27/2018 06:15 PM, Lukasz Majewski wrote:
>>> Hi Marek,
>>>
>>> Thanks for prompt feedback.
>>>
>>>> On 04/27/2018 04:51 PM, Lukasz Majewski wrote:
>>>>> This commit provides the ability to generate u-boot environment(s)
>>>>> as images, which afterwards can be used to produce image (with
>>>>> wic) for flashing (eMMC or SPI-NOR).
>>>>>
>>>>> This change removes the need to run "env default" during
>>>>> production phase, as proper environment (including redundant one)
>>>>> is already stored on persistent memory (the CRC is also correct).
>>>>>
>>>>> Signed-off-by: Lukasz Majewski <lu...@denx.de>
>>>>
>>>> If your default env is correct, why do you need this ?
>>>
>>> Some users wants to have the working board (i.e. without any
>>> warnings that CRC for envs is bad) after flashing the SPI-NOR/eMMC
>>
>> And the board is not working when it tells you your env is not
>> populated?
>
> It complains that CRC is wrong, which is true as without this patch
> (and some wic adjustments) we don't have proper envs in expected
> non-volatile area.
This is NOT an error, this is warning and a correct behavior. If your
default U-Boot environment is not correct, that is a bug in your U-Boot
port.
If you need to adjust that environment later in the product life cycle,
that's a different topic.
>> Then maybe the board port is broken.
>
> Then it proceeds with default envs - and boots.
I think I might not quite understand the problem anymore. Is the issue
here that U-Boot informs you that it's using default environment which
you do not like ?
[...]
>>>>> +# Generate default environment
>>>>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
>>>>> environment(s)" +do_gen_default_envs () {
>>>>> + ${B}/source/scripts/get_default_envs.sh ${B} >
>>>>> ${B}/${DEFAULT_ENVS} +
>>>>> + # Generate env image
>>>>> + ${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
>>>>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}
>>>>
>>>> Does this actually work during cross build , when mkenvimage
>>>> architecture is different than host architecture ?
>>>
>>> Yes. This was tested.
>>
>> How can it work if this binary cannot be executed ? :)
>
> Could you be more specific here?
>
> I do follow normal u-boot recipe build. If mkenvimage is build in a
> wrong way (as other tools) - then I suppose that the whole u-boot recipe
> is broken.
>
> The get_default_envs.sh script is prepared to use either native or
> cross-compiled set of binutils (that thought I had in mind when I said
> that it was tested).
Consider you crosscompile mkenvimage for ARM and try to run it on x86 host.
>>>>> + # Generate redundant env image
>>>>> + ${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
>>>>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}
>>>>
>>>> Is redundant env always needed on all systems ?
>>>
>>> No, they are not. However, it shall not be a problem if it is build
>>> anyway - user can adjust wic to only put primary env image.
>>
>> So many wasted CPU cycles for a feature barely anyone needs. Nope :)
>
> I will try to craft some OE magic to make it not build when not
> needed... :-)
Can't you just patch a correct default env into the U-Boot port ?
--
Best regards,
Marek Vasut
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
