[U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
Marty E. Plummer
hanetzer at startmail.com
Sun May 6 20:41:35 UTC 2018
On Sun, May 06, 2018 at 10:21:55PM +0200, klaus.goger at theobroma-systems.com wrote:
>
> > On 06.05.2018, at 22:03, Marty E. Plummer <hanetzer at startmail.com> wrote:
> >
> > On Sun, May 06, 2018 at 02:08:25PM -0500, Marty E. Plummer wrote:
> >>> On Sun, May 06, 2018 at 08:39:23PM +0200, klaus.goger at theobroma-systems.com wrote:
> >>>> On 06.05.2018, at 16:25, Marty E. Plummer <hanetzer at startmail.com> wrote:
> >>>> + * we use the 0x00000000~0xfeffffff space
> >>>> + * since 0xff000000~0xffffffff is soc register space
> >>>> + * so we reserve it
> >>>> + */
> >>>
> >>> That's not true for all Rockchip SoCs. On the RK3399 for example the upper limit
> >>> is 0xf8000000. Even on the RK3288 DRAM address range is actually
> >>> 0x00000000-0xfe00000
> >>>
> >>>> + size_mb = min(size_mb, 0xff000000/SZ_1M);
> >>>> }
> >>>
> >>> Should be 0xfe000000 (4G-32MB) for RK3288.
> >>> But there is already a define for that, SDRAM_MAX_SIZE is defined in
> >>> rkxxx_common.h. Using that one would help to avoid possible breakage
> >>> of other Rockchip SoCs.
> >>>
> >> Oh, does that get #defined properly for each SoC? if so, I'll sub that
> >> in for better compat.
> > In fact, could you or someone else help me to understand the #include
> > chain here? I'm not certain as to what that is available in each header
> > mentioned can be used in this file to get max compat across the rockchip
> > lineup, and I don't want to break someone elses board/etc with something
> > that 'works for me'.
>
> You can get a full list of included headers by adding the -H file to the gcc command line.
> make V=1 will help you to see how it's called on your system.
>
> In that particular case the relevant include chain is:
> . include/common.h
> .. include/config.h
> ... include/configs/popmetal_rk3288.h
> .... include/configs/rk3288_common.h
>
> So the correct rk3xxx_common.h will be selected by config.h and SDRAM_MAX_SIZE
> is defined in all of them.
>
Ah, so 's:0xff000000:SDRAM_MAX_SIZE:' in that spot and it should be
golden for all the rockchip stuffs. I'll try that, then try without the
if (!size_mb) guard as well. Should it still work after that, I'll
resubmit that patch. Probably with patman, if I can grok how to use it.
Aside from these issues, does the rest of the series look fine?
More information about the U-Boot
mailing list