[U-Boot] [PATCH 3/3] arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ

[Simon Goldschmidt]

On 10.01.2019 09:38, Marek Vasut wrote:
> On 1/10/19 9:19 AM, Simon Goldschmidt wrote:
>> On Wed, Jan 9, 2019 at 10:44 PM Marek Vasut <marex at denx.de> wrote:
>>>
>>> On 1/9/19 10:42 PM, Simon Goldschmidt wrote:
>>>>
>>>>
>>>> Am Mi., 9. Jan. 2019, 22:39 hat Marek Vasut <marex at denx.de
>>>> <mailto:marex at denx.de>> geschrieben:
>>>>
>>>>      On 1/9/19 10:34 PM, Simon Goldschmidt wrote:
>>>>      >
>>>>      >
>>>>      > Am Mi., 9. Jan. 2019, 22:31 hat Marek Vasut <marex at denx.de
>>>>      <mailto:marex at denx.de>
>>>>      > <mailto:marex at denx.de <mailto:marex at denx.de>>> geschrieben:
>>>>      >
>>>>      >     On 1/9/19 10:30 PM, Simon Goldschmidt wrote:
>>>>      >     >
>>>>      >     >
>>>>      >     > Am Mi., 9. Jan. 2019, 22:27 hat Marek Vasut <marex at denx.de
>>>>      <mailto:marex at denx.de>
>>>>      >     <mailto:marex at denx.de <mailto:marex at denx.de>>
>>>>      >     > <mailto:marex at denx.de <mailto:marex at denx.de>
>>>>      <mailto:marex at denx.de <mailto:marex at denx.de>>>> geschrieben:
>>>>      >     >
>>>>      >     >     On 1/9/19 8:56 PM, Simon Goldschmidt wrote:
>>>>      >     >     > socfpga_common.h defines CONFIG_SYS_BOOTMAPSZ to 64 MiB.
>>>>      >     >     >
>>>>      >     >     > Since having this define overrides the 'bootm_size' env
>>>>      >     variable for
>>>>      >     >     > the whole socfpga platform, let's remove this define from
>>>>      >     >     socfpga_common.h
>>>>      >     >     > and instead rely on the 'bootm_size' env variable
>>>>      (which is
>>>>      >     >     initialized
>>>>      >     >     > to 160 MiB in the same file's default env). This gives
>>>>      users the
>>>>      >     >     > chance to override it in their own environment.
>>>>      >     >     >
>>>>      >     >     > Signed-off-by: Simon Goldschmidt
>>>>      >     <simon.k.r.goldschmidt at gmail.com
>>>>      <mailto:simon.k.r.goldschmidt at gmail.com>
>>>>      >     <mailto:simon.k.r.goldschmidt at gmail.com
>>>>      <mailto:simon.k.r.goldschmidt at gmail.com>>
>>>>      >     >     <mailto:simon.k.r.goldschmidt at gmail.com
>>>>      <mailto:simon.k.r.goldschmidt at gmail.com>
>>>>      >     <mailto:simon.k.r.goldschmidt at gmail.com
>>>>      <mailto:simon.k.r.goldschmidt at gmail.com>>>>
>>>>      >     >     > ---
>>>>      >     >     >
>>>>      >     >     >  include/configs/socfpga_common.h | 2 --
>>>>      >     >     >  1 file changed, 2 deletions(-)
>>>>      >     >     >
>>>>      >     >     > diff --git a/include/configs/socfpga_common.h
>>>>      >     >     b/include/configs/socfpga_common.h
>>>>      >     >     > index e9b368d93a..04e0f06230 100644
>>>>      >     >     > --- a/include/configs/socfpga_common.h
>>>>      >     >     > +++ b/include/configs/socfpga_common.h
>>>>      >     >     > @@ -10,8 +10,6 @@
>>>>      >     >     >   */
>>>>      >     >     >  #define CONFIG_CLOCKS
>>>>      >     >     >
>>>>      >     >     > -#define CONFIG_SYS_BOOTMAPSZ         (64 * 1024 * 1024)
>>>>      >     >     > -
>>>>      >     >     >  #define CONFIG_TIMESTAMP             /* Print image
>>>>      info with
>>>>      >     >     timestamp */
>>>>      >     >     >
>>>>      >     >     >  /* add target to build it automatically upon "make" */
>>>>      >     >     >
>>>>      >     >     Can you at least "imply" it to 64 MiB, so we don't
>>>>      change the
>>>>      >     behavior ?
>>>>      >     >
>>>>      >     >
>>>>      >     > You mean change the "boot_size" value in default environment
>>>>      to 64
>>>>      >     MiB?
>>>>      >     > Sure.
>>>>      >
>>>>      >     Sure, just so we won't change the behavior, some people like
>>>>      to run
>>>>      >     gigantic kernels.
>>>>      >
>>>>      >
>>>>      > Well, 28th this patch, the size should grow from 64 MiB (from the
>>>>      > define) to 160 MiB (bootm_size value). I figured that would be ok for
>>>>      > everyone... But if you want me to shrink that back to 64 MiB, I'm ok
>>>>      > with that either...
>>>>
>>>>      160 is fine too.
>>>>
>>>>
>>>> Ok, so no V2 for this one. I'll check i2c DM tomorrow.
>>>
>>> Thanks, appreciated.
>>
>> I had a quick look, but I2C eemprom access has change too much from legacy
>> to DM for me to just dry-code that.
>>
>> Hoever, I just saw the PHY1 extension board for my SoCrates has an I2C eeprom,
>> too. So I'll first try to get that running before just converting the
>> Vining. But this
>> will probably need more time.
> 
> The MW opens next week, so that's fine .

I failed to find the time to do this. It did not "just work" and I could 
not get it to run in the short time I had for this. Could we still merge 
2/3 and 3/3 for this release? Or even leave the vining I2C cleanup to 
that board's maintainer (don't know who that is actually) and apply 1/3 too?

Regards,
Simon