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

Marek Vasut marex at denx.de
Thu Jan 10 08:38:51 UTC 2019


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 .

-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list