[U-Boot] [PATCH 2/3] mx6qsabrelite: Change default environment to cope with OE changes

[Eric Nelson]

Hi Octavio,

On 09/19/2012 06:15 PM, Otavio Salvador wrote:
> On Wed, Sep 19, 2012 at 9:58 PM, Eric Nelson
> <eric.nelson at boundarydevices.com>  wrote:
>> On 09/19/2012 04:51 PM, Otavio Salvador wrote:
>>> I sort of agree; do you use 2 or 3 partitions in this case?
>>>
>>
>> Or 1 or 9?
>>
>> I'm actually not kidding here. The current Freescale Android image
>> (R13.4-Beta) actually does want 9 partitions for a bunch of stuff
>> like a 'recovery' partition, a 'vendor' partition, etc.
>>
>> Or even 0? Windows users have been known to use SD cards straight out
>> of the box with no partition table.
>>
>> In short, this is something that can't be solved in the general case,
>> so I think it's best for the main-line U-Boot code to not try and
>> provide policy, only functionality.
>
> I agree; but mainline could have defaults that works at least for
> usual U-Boot hacker. That's why I asked how many you use.
>
>> To that end, we've tried to standardize on something simple: the presence of
>> a file named '6q_bootscript' on one of the SD cards that can handle these
>> sorts of userspace details:
>>
>> http://boundarydevices.com/u-boot-conventions-for-i-mx6-nitrogen6x-and-sabrelite/
>>
>> This allows all of the userspace bits to go into the userspace filesystem,
>> but still allows machine-specific like the type of display connected to
>> be saved in the environment.
>>
>> Using this approach, you can load kernel(s) or RAM disks from anywhere
>> that U-Boot can reach without re-compiling U-Boot.
>
> This is indeed nice.
>
>>>> Isn't using 'mkenvimage' in OE a better route? That way, the environment
>>>> can
>>>> change with the userspace decision.
>>>
>>> In fact in OE we have a patch for it. Usually we don't call mkenvimage
>>> for it but I like the idea to add this feature there later.
>>
>> The best part of doing it in OE is that the same commit should be able to
>> update both the environment variables (or boot script) and the parts which depend
>> on it (like creation of the filesystem image(s)).
>
> Yes; I will work in a generic way for it in OE ... I like the idea and
> also see the added value for the flexibility.
>
> After MX23 I will focus on this ;-) (or Marek kills me :P)
>
> This doesn't solve the question:
>
> Better to have 2 or 3 partition layout by default in mainline?
>

I suspect that this question isn't for me, since I'm not sure which
userspace(s) we're targeting.

Heck, I didn't know that OE was still kicking... I kinda had the
impression that Yocto had taken it over ;)

Regards,


Eric