On 3/1/19 8:38 PM, Simon Goldschmidt wrote: > > > 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 <ma...@denx.de> wrote: >>>> >>>> On 1/9/19 10:42 PM, Simon Goldschmidt wrote: >>>>> >>>>> >>>>> Am Mi., 9. Jan. 2019, 22:39 hat Marek Vasut <ma...@denx.de >>>>> <mailto:ma...@denx.de>> geschrieben: >>>>> >>>>> On 1/9/19 10:34 PM, Simon Goldschmidt wrote: >>>>> > >>>>> > >>>>> > Am Mi., 9. Jan. 2019, 22:31 hat Marek Vasut <ma...@denx.de >>>>> <mailto:ma...@denx.de> >>>>> > <mailto:ma...@denx.de <mailto:ma...@denx.de>>> geschrieben: >>>>> > >>>>> > On 1/9/19 10:30 PM, Simon Goldschmidt wrote: >>>>> > > >>>>> > > >>>>> > > Am Mi., 9. Jan. 2019, 22:27 hat Marek Vasut >>>>> <ma...@denx.de >>>>> <mailto:ma...@denx.de> >>>>> > <mailto:ma...@denx.de <mailto:ma...@denx.de>> >>>>> > > <mailto:ma...@denx.de <mailto:ma...@denx.de> >>>>> <mailto:ma...@denx.de <mailto:ma...@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.goldschm...@gmail.com >>>>> <mailto:simon.k.r.goldschm...@gmail.com> >>>>> > <mailto:simon.k.r.goldschm...@gmail.com >>>>> <mailto:simon.k.r.goldschm...@gmail.com>> >>>>> > > <mailto:simon.k.r.goldschm...@gmail.com >>>>> <mailto:simon.k.r.goldschm...@gmail.com> >>>>> > <mailto:simon.k.r.goldschm...@gmail.com >>>>> <mailto:simon.k.r.goldschm...@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?
Can you rebase/repost those patches , so I can take a look ? Unless they are fixes, those will be for next. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
