| Message ID | 20210302153451.19440-1-bmeng.cn@gmail.com |
|---|---|
| Headers | show |
| Series | ppc: qemu: Add eTSEC support | expand |
Hi Tom, On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn@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? Regards, Bin
Hi Bin, On Tue, 2 Mar 2021 at 18:08, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Tom, > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn@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. Regards, Simon
Hi Simon, On Wed, Mar 3, 2021 at 9:53 AM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Tue, 2 Mar 2021 at 18:08, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Tom, > > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn@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. Regards, Bin
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@chromium.org> wrote: > > > > Hi Bin, > > > > On Tue, 2 Mar 2021 at 18:08, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > Hi Tom, > > > > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn@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.
Hi Bin, On Wed, 3 Mar 2021 at 09:49, Tom Rini <trini@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@chromium.org> wrote: > > > > > > Hi Bin, > > > > > > On Tue, 2 Mar 2021 at 18:08, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > Hi Tom, > > > > > > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn@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
Hi Simon, On Thu, Mar 4, 2021 at 1:21 AM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Wed, 3 Mar 2021 at 09:49, Tom Rini <trini@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@chromium.org> wrote: > > > > > > > > Hi Bin, > > > > > > > > On Tue, 2 Mar 2021 at 18:08, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn@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. OK, a new Kconfig seems to be odd, but it looks there is no better way of doing this. Regards, Bin
Hi Bin, On Wed, 3 Mar 2021 at 20:58, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Thu, Mar 4, 2021 at 1:21 AM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Wed, 3 Mar 2021 at 09:49, Tom Rini <trini@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@chromium.org> wrote: > > > > > > > > > > Hi Bin, > > > > > > > > > > On Tue, 2 Mar 2021 at 18:08, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Tue, Mar 2, 2021 at 11:35 PM Bin Meng <bmeng.cn@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. > > OK, a new Kconfig seems to be odd, but it looks there is no better way > of doing this. OK then. Regards, Simon