[PATCH 00/20] ppc: qemu: Add eTSEC support

[Simon Glass]

Hi Bin,

On Wed, 3 Mar 2021 at 09:49, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Mar 03, 2021 at 10:11:45AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Mar 3, 2021 at 9:53 AM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Tue, 2 Mar 2021 at 18:08, Bin Meng <bmeng.cn at gmail.com> wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn at gmail.com> wrote:
> > > > >
> > > > > QEMU ppce500 machine can dynamically instantiate an eTSEC device
> > > > > if "-device eTSEC" is given to QEMU.
> > > > >
> > > > > This series updates the fixed-link ethernet PHY driver as well as
> > > > > the Freescale eTSEC driver to support the QEMU ppce500 board.
> > > > >
> > > > > Based-on:
> > > > > http://patchwork.ozlabs.org/project/uboot/list/?series=230985
> > > > >
> > > > > This series is avaiable at u-boot-x86/eTSEC for testing.
> > > > >
> > > > >
> > > >
> > > > Azure results say there are several ARM boards fail to build due to
> > > > size overflow with this series.
> > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=334&view=results
> > > >
> > > > How do we handle this?
> > >
> > > The one I looked at, imx6dl_mamoj seems to be 0xbc5 over the limit.
> > > That's a very large growth, indicating that your series is doing
> > > something odd, perhaps?
> > >
> > > I suppose you know this, but you can use:
> > >
> > > buildman -b try imx6dl_mamoj
> > > buildman -b try -sS
> > >
> > > to see which commit creates the size growth, and -B to see which functions.
> >
> > Thanks, so it's caused by this patch:
> > http://patchwork.ozlabs.org/project/uboot/patch/20210302153451.19440-17-bmeng.cn@gmail.com/
> >
> > 16: dm: core: Correctly read <ranges> of simple-bus
> >        arm:  +   imx6dl_mamoj
> >        arm: (for 1/1 boards) all +274.0 bss -32.0 spl/u-boot-spl:all
> > +3232.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +2180.0
> > spl/u-boot-spl:text +1028.0 text +306.0
> >             imx6dl_mamoj   : all +274 bss -32 spl/u-boot-spl:all +3232
> > spl/u-boot-spl:data +24 spl/u-boot-spl:rodata +2180
> > spl/u-boot-spl:text +1028 text +306
> >                spl-u-boot-spl: add: 9/-1, grow: 1/0 bytes: 1070/-24 (1046)
> >                  function                                   old     new   delta
> >                  __of_translate_address                       -     404    +404
> >                  fdt_read_range                               -     208    +208
> >                  of_bus_default_map                           -     148    +148
> >                  of_bus_default_translate                     -     114    +114
> >                  fdt_read_prop                                -      66     +66
> >                  fdt_support_default_count_cells              -      52     +52
> >                  fdt_getprop_u32_default_node                 -      36     +36
> >                  of_busses                                    -      24     +24
> >                  fdt_translate_address                        -      12     +12
> >                  simple_bus_post_bind                        52      58      +6
> >                  ofnode_read_u32_array                       24       -     -24
> >                u-boot: add: 3/-1, grow: 1/0 bytes: 316/-24 (292)
> >                  function                                   old     new   delta
> >                  fdt_read_range                               -     208    +208
> >                  fdt_read_prop                                -      66     +66
> >                  fdt_getprop_u32_default_node                 -      36     +36
> >                  simple_bus_post_bind                        52      58      +6
> >                  ofnode_read_u32_array                       24       -     -24
> >
> >
> > But this patch is a bug fix. I am not sure how we can avoid the size increase.
>
> I'd love to hear there's a clever fix we can do here for SPL, but in the
> likely case there isn't, this might get stuck until the LTO series that
> was posted today goes in as well, as that will give us some size back.
> I assume this was a bug fix your series needed and not something you
> noticed while in the code.
>

The size increase is so enormous that I'd argue for a new Kconfig that
you can select for the board that needs it.

Regards,
Simon