[U-Boot-Users] [PATCH 1/3] ppc: Report back the location we put the device tree if we dont boot

Kumar Gala galak at kernel.crashing.org
Wed Aug 6 15:16:14 CEST 2008


On Aug 6, 2008, at 3:33 AM, Wolfgang Denk wrote:

> Dear Bartek,
>
> in message <48995F0F.8070807 at semihalf.com> you wrote:
>>
>> The test you're referring to was introduced by commit
>> 75fa002c47171b73fb4c1f2c2fe4d6391c136276 "[new uImage] Respect  
>> autostart
>> setting in linux bootm" by Kumar -- he should be better able to  
>> explain
>> the details.
>
> Thanks - and sorry for blaming you, I should have checked this myself
> first.
>
>> It looks like that the "autostart" field has been added to the
>> bootm_headers structure so that the arch-specific code can make
>> decisions about booting without the need to call getenv("autostart").
>> Instead, the "autostart" field is set based on the env. variable  
>> once,
>> and passed to boot-related functions via a parameter (e.g.,  
>> "images" in
>> do_bootm_linux()).
>>
>> Again, this field has beed introduced by Kumar
>> (f5614e7926863bf0225ec860d9b319741a9c4004, "[new uImage] Add  
>> autostart
>> flag to bootm_headers structure"), who should be able to comment  
>> more.
>
> Indeed - but as mentioned before, this all makes no sense to me,
> because with the intended and documented use of the "autostart"
> variable the bootm command will not be called at all.
>
>
> Kumar, if I were to back out commit f5614e79 - what exactly would it
> break in your opinion?

There is intent and what the old code did.  My feeling is that  
'autostart = no' means to load the images but not actually jump to the  
new image.

The old code would load the "kernel" image and set 'filesize' and  
return (only if the image was of type IH_TYPE_STANDALONE).

I think when sent 'f5614e7926863bf0225ec860d9b319741a9c4004' I didn't  
notice the IH_TYPE_STANDALONE aspect.

We can revert the commit but it puts be back to square one w/o a  
solution to my problem.

- k




More information about the U-Boot mailing list