[U-Boot] [PATCH v7 0/7] arm: socfpga: update default u-boot environment

[Marek Vasut]

On 01/27/2017 03:30 AM, Dalon Westergreen wrote:
> On Fri, 2017-01-27 at 03:11 +0100, Marek Vasut wrote:
>> On 01/26/2017 11:33 PM, Dalon Westergreen wrote:
>>>
>>> On Thu, 2017-01-26 at 22:41 +0100, Marek Vasut wrote:
>>>>
>>>> On 01/26/2017 10:05 PM, Dalon Westergreen wrote:
>>>>>
>>>>>
>>>>> On Thu, 2017-01-26 at 21:54 +0100, Marek Vasut wrote:
>>>>>>
>>>>>>
>>>>>> On 01/26/2017 09:31 PM, Dalon Westergreen wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Dalon Westergreen <dalon.westergreen at intel.com>
>>>>>>>
>>>>>>> These patches update the boot and os partition numbers in
>>>>>>> the                   
>>>>>>> default uboot environment for a number of socfpga
>>>>>>> boards.  Per                  
>>>>>>> request, common environment configurations have been moved to
>>>>>>> a                 
>>>>>>> shared
>>>>>>> header.                                                             
>>>>>>>     
>>>>>>>  
>>>>>>>
>>>>>>> Changed in v7:
>>>>>>>   Changed the bootloader partition to 3 to match the default layout
>>>>>>> for
>>>>>>>   socfpga.  commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed
>>>>>>> this
>>>>>>> to
>>>>>>> 1
>>>>>>>   which broke a number of socfpga kits.
>>>>>>
>>>>>> And this commit will break another bulk of kits, great ...
>>>>> I think the only kit that MAY be affected is the DE1 kit and I
>>>>> actually dont even think that is true b/c they are probably
>>>>> using the method described in the former thread where they just 
>>>>> write the u-boot-with-spl.sfp to +64KB.  
>>>>> CONFIG_SPL_ABORT_ON_RAW_IMAGE is defined for the board.
>>>>
>>>> And all the kits which used the environment in mainline U-Boot.
>>>>
>>>>>
>>>>>
>>>>> If i had a board I would test it.  But that said, this is currently 
>>>>> how all of the altera kits, and the de0 kit work.
>>>>
>>>> I'd be happy to take the previous patchset without this new "windows
>>>> compatibility"/"ancient u-boot compatibility" crap and then proceed
>>>> with a discussion on this new topic.
>>>>
>>>> But now that it came up, well, I guess I'll wait for Dinh to make the
>>>> decision, since we clearly have totally different opinions.
>>>>
>>> Thanks.  I am open to any suggestions, i could just wrap the 
>>> boot partition number in socfpga_common with an ifndef? and define 
>>> it as partition 3 in the altera boards which currently use that setup?
>>
>> Uh no, let's not add more ifdefs.
>>
>>>
>>> another option would be to re-implement the method used in the older
>>> 2013.01.01 uboot used by socfpga which, rather than using a partition
>>> number specifically looked for a partition of type 0xa2 making the
>>> partition number irrelevant?
>>
>> Either that or load u-boot.img from FS (even better). Do you have an
>> example patch for the first approach ? How intrusive is it ?
> I am working on it as we speak.  I like that approach, i am thinking
> searching for the a2 partition is a failover in spl_mmc_load_image
> after mmc_load_image_raw_sector.  i can test it, and send a patch
> for you to decide if it is too invasive?

OK, thanks


-- 
Best regards,
Marek Vasut