[U-Boot] Maximum size of u-boot.imx for TBS2910 board
Hello Soeren,
when trying to add support for function key support in the USB keyboard driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx. https://travis-ci.org/marex/u-boot-usb/builds/614059004
Do you remember why on the TBS2910 board this size is limited to 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger u-boot.imx.
The limit is defined here: include/configs/tbs2910.h:80: #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
Best regards
Heinrich
On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
Hello Soeren,
when trying to add support for function key support in the USB keyboard driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx. https://travis-ci.org/marex/u-boot-usb/builds/614059004
Do you remember why on the TBS2910 board this size is limited to 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger u-boot.imx.
The limit is defined here: include/configs/tbs2910.h:80: #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
The nature of these boards (aimed at end users) means that we just do not want to / cannot really move the stored environment. Thanks!
On 11/21/19 9:12 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
Hello Soeren,
when trying to add support for function key support in the USB keyboard driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx. https://travis-ci.org/marex/u-boot-usb/builds/614059004
Do you remember why on the TBS2910 board this size is limited to 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger u-boot.imx.
The limit is defined here: include/configs/tbs2910.h:80: #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
The nature of these boards (aimed at end users) means that we just do not want to / cannot really move the stored environment. Thanks!
Another possibility would be to reduce the image size by using CONFIG_REGEX=n which should be fine for a board with only one supported network interface.
Best regards
Heinrich
On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
On 11/21/19 9:12 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
Hello Soeren,
when trying to add support for function key support in the USB keyboard driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx. https://travis-ci.org/marex/u-boot-usb/builds/614059004
Do you remember why on the TBS2910 board this size is limited to 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger u-boot.imx.
The limit is defined here: include/configs/tbs2910.h:80: #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
The nature of these boards (aimed at end users) means that we just do not want to / cannot really move the stored environment. Thanks!
Another possibility would be to reduce the image size by using CONFIG_REGEX=n which should be fine for a board with only one supported network interface.
But the board was fine before your patchset got applied and this is just a workaround for added bloat, which reduces functionality. I dislike trading functionality for bloat, sorry.
On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
On 11/21/19 9:12 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
Hello Soeren,
when trying to add support for function key support in the USB keyboard driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx. https://travis-ci.org/marex/u-boot-usb/builds/614059004
Do you remember why on the TBS2910 board this size is limited to 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger u-boot.imx.
The limit is defined here: include/configs/tbs2910.h:80: #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
The nature of these boards (aimed at end users) means that we just do not want to / cannot really move the stored environment. Thanks!
Another possibility would be to reduce the image size by using CONFIG_REGEX=n which should be fine for a board with only one supported network interface.
But the board was fine before your patchset got applied and this is just a workaround for added bloat, which reduces functionality. I dislike trading functionality for bloat, sorry.
One persons "bloat" is another persons "added functionality". I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone.
On 11/21/19 11:45 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
On 11/21/19 9:12 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
Hello Soeren,
when trying to add support for function key support in the USB keyboard driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx. https://travis-ci.org/marex/u-boot-usb/builds/614059004
Do you remember why on the TBS2910 board this size is limited to 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger u-boot.imx.
The limit is defined here: include/configs/tbs2910.h:80: #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
The nature of these boards (aimed at end users) means that we just do not want to / cannot really move the stored environment. Thanks!
Another possibility would be to reduce the image size by using CONFIG_REGEX=n which should be fine for a board with only one supported network interface.
But the board was fine before your patchset got applied and this is just a workaround for added bloat, which reduces functionality. I dislike trading functionality for bloat, sorry.
One persons "bloat" is another persons "added functionality".
It would seem this board did not suffer from the lack of this particular functionality before, and I would say that a board should stay at least as functional as it was when it was added. Replacing existing functionality with random unrelated new one makes no sense.
I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone.
Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem.
On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
On 11/21/19 11:45 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
On 11/21/19 9:12 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote:
Hello Soeren,
when trying to add support for function key support in the USB keyboard driver u-boot.imx for the TBS2910 surpassed the maximum size for u-boot.imx. https://travis-ci.org/marex/u-boot-usb/builds/614059004
Do you remember why on the TBS2910 board this size is limited to 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger u-boot.imx.
The limit is defined here: include/configs/tbs2910.h:80: #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */
Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged?
Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
The nature of these boards (aimed at end users) means that we just do not want to / cannot really move the stored environment. Thanks!
Another possibility would be to reduce the image size by using CONFIG_REGEX=n which should be fine for a board with only one supported network interface.
But the board was fine before your patchset got applied and this is just a workaround for added bloat, which reduces functionality. I dislike trading functionality for bloat, sorry.
One persons "bloat" is another persons "added functionality".
It would seem this board did not suffer from the lack of this particular functionality before, and I would say that a board should stay at least as functional as it was when it was added. Replacing existing functionality with random unrelated new one makes no sense.
Was it tho? I believe we're talking about supporting some additional keys via USB keyboard. This board does in fact expect users to be at the U-Boot prompt via USB keyboard.
I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone.
Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem.
But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well.
On 11/22/19 1:32 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
On 11/21/19 11:45 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
On 11/21/19 9:12 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote: > Hello Soeren, > > when trying to add support for function key support in the USB keyboard > driver u-boot.imx for the TBS2910 surpassed the maximum size for > u-boot.imx. > https://travis-ci.org/marex/u-boot-usb/builds/614059004 > > Do you remember why on the TBS2910 board this size is limited to > 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger > u-boot.imx. > > The limit is defined here: > include/configs/tbs2910.h:80: > #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */ > > Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged? > > Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000.
The nature of these boards (aimed at end users) means that we just do not want to / cannot really move the stored environment. Thanks!
Another possibility would be to reduce the image size by using CONFIG_REGEX=n which should be fine for a board with only one supported network interface.
But the board was fine before your patchset got applied and this is just a workaround for added bloat, which reduces functionality. I dislike trading functionality for bloat, sorry.
One persons "bloat" is another persons "added functionality".
It would seem this board did not suffer from the lack of this particular functionality before, and I would say that a board should stay at least as functional as it was when it was added. Replacing existing functionality with random unrelated new one makes no sense.
Was it tho? I believe we're talking about supporting some additional keys via USB keyboard. This board does in fact expect users to be at the U-Boot prompt via USB keyboard.
How did you reach this conclusion ? It seems to be some sort of devkit.
I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone.
Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem.
But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well.
The other option is, we will sink in bloat and suffer endless size problems.
On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
On 11/22/19 1:32 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
On 11/21/19 11:45 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
On 11/21/19 10:59 PM, Heinrich Schuchardt wrote:
On 11/21/19 9:12 PM, Tom Rini wrote: > On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote: >> Hello Soeren, >> >> when trying to add support for function key support in the USB keyboard >> driver u-boot.imx for the TBS2910 surpassed the maximum size for >> u-boot.imx. >> https://travis-ci.org/marex/u-boot-usb/builds/614059004 >> >> Do you remember why on the TBS2910 board this size is limited to >> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger >> u-boot.imx. >> >> The limit is defined here: >> include/configs/tbs2910.h:80: >> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */ >> >> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged? >> >> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000. > > The nature of these boards (aimed at end users) means that we just do > not want to / cannot really move the stored environment. Thanks!
Another possibility would be to reduce the image size by using CONFIG_REGEX=n which should be fine for a board with only one supported network interface.
But the board was fine before your patchset got applied and this is just a workaround for added bloat, which reduces functionality. I dislike trading functionality for bloat, sorry.
One persons "bloat" is another persons "added functionality".
It would seem this board did not suffer from the lack of this particular functionality before, and I would say that a board should stay at least as functional as it was when it was added. Replacing existing functionality with random unrelated new one makes no sense.
Was it tho? I believe we're talking about supporting some additional keys via USB keyboard. This board does in fact expect users to be at the U-Boot prompt via USB keyboard.
How did you reach this conclusion ? It seems to be some sort of devkit.
It came up in one of the previous threads about this board and what we can / cannot do about the size constraint and the board maintainers unhappiness about the overall size growth and broken releases (until size growth became a link error on the platform).
I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone.
Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem.
But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well.
The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
On 11/22/19 2:30 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
On 11/22/19 1:32 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
On 11/21/19 11:45 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote:
On 11/21/19 10:59 PM, Heinrich Schuchardt wrote: > On 11/21/19 9:12 PM, Tom Rini wrote: >> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote: >>> Hello Soeren, >>> >>> when trying to add support for function key support in the USB keyboard >>> driver u-boot.imx for the TBS2910 surpassed the maximum size for >>> u-boot.imx. >>> https://travis-ci.org/marex/u-boot-usb/builds/614059004 >>> >>> Do you remember why on the TBS2910 board this size is limited to >>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger >>> u-boot.imx. >>> >>> The limit is defined here: >>> include/configs/tbs2910.h:80: >>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */ >>> >>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged? >>> >>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000. >> >> The nature of these boards (aimed at end users) means that we just do >> not want to / cannot really move the stored environment. Thanks! > > Another possibility would be to reduce the image size by using > CONFIG_REGEX=n which should be fine for a board with only one supported > network interface.
But the board was fine before your patchset got applied and this is just a workaround for added bloat, which reduces functionality. I dislike trading functionality for bloat, sorry.
One persons "bloat" is another persons "added functionality".
It would seem this board did not suffer from the lack of this particular functionality before, and I would say that a board should stay at least as functional as it was when it was added. Replacing existing functionality with random unrelated new one makes no sense.
Was it tho? I believe we're talking about supporting some additional keys via USB keyboard. This board does in fact expect users to be at the U-Boot prompt via USB keyboard.
How did you reach this conclusion ? It seems to be some sort of devkit.
It came up in one of the previous threads about this board and what we can / cannot do about the size constraint and the board maintainers unhappiness about the overall size growth and broken releases (until size growth became a link error on the platform).
Link please ? It sounds relevant to this thread too.
I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone.
Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem.
But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well.
The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
On Fri, Nov 22, 2019 at 02:38:51AM +0100, Marek Vasut wrote:
On 11/22/19 2:30 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
On 11/22/19 1:32 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
On 11/21/19 11:45 PM, Tom Rini wrote:
On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote: > On 11/21/19 10:59 PM, Heinrich Schuchardt wrote: >> On 11/21/19 9:12 PM, Tom Rini wrote: >>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote: >>>> Hello Soeren, >>>> >>>> when trying to add support for function key support in the USB keyboard >>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for >>>> u-boot.imx. >>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004 >>>> >>>> Do you remember why on the TBS2910 board this size is limited to >>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger >>>> u-boot.imx. >>>> >>>> The limit is defined here: >>>> include/configs/tbs2910.h:80: >>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */ >>>> >>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged? >>>> >>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000. >>> >>> The nature of these boards (aimed at end users) means that we just do >>> not want to / cannot really move the stored environment. Thanks! >> >> Another possibility would be to reduce the image size by using >> CONFIG_REGEX=n which should be fine for a board with only one supported >> network interface. > > But the board was fine before your patchset got applied and this is just > a workaround for added bloat, which reduces functionality. I dislike > trading functionality for bloat, sorry.
One persons "bloat" is another persons "added functionality".
It would seem this board did not suffer from the lack of this particular functionality before, and I would say that a board should stay at least as functional as it was when it was added. Replacing existing functionality with random unrelated new one makes no sense.
Was it tho? I believe we're talking about supporting some additional keys via USB keyboard. This board does in fact expect users to be at the U-Boot prompt via USB keyboard.
How did you reach this conclusion ? It seems to be some sort of devkit.
It came up in one of the previous threads about this board and what we can / cannot do about the size constraint and the board maintainers unhappiness about the overall size growth and broken releases (until size growth became a link error on the platform).
Link please ? It sounds relevant to this thread too.
https://lists.denx.de/pipermail/u-boot/2019-April/365297.html
I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone.
Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem.
But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well.
The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
On 11/22/19 3:53 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 02:38:51AM +0100, Marek Vasut wrote:
On 11/22/19 2:30 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
On 11/22/19 1:32 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote:
On 11/21/19 11:45 PM, Tom Rini wrote: > On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote: >> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote: >>> On 11/21/19 9:12 PM, Tom Rini wrote: >>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote: >>>>> Hello Soeren, >>>>> >>>>> when trying to add support for function key support in the USB keyboard >>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for >>>>> u-boot.imx. >>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004 >>>>> >>>>> Do you remember why on the TBS2910 board this size is limited to >>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger >>>>> u-boot.imx. >>>>> >>>>> The limit is defined here: >>>>> include/configs/tbs2910.h:80: >>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */ >>>>> >>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged? >>>>> >>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000. >>>> >>>> The nature of these boards (aimed at end users) means that we just do >>>> not want to / cannot really move the stored environment. Thanks! >>> >>> Another possibility would be to reduce the image size by using >>> CONFIG_REGEX=n which should be fine for a board with only one supported >>> network interface. >> >> But the board was fine before your patchset got applied and this is just >> a workaround for added bloat, which reduces functionality. I dislike >> trading functionality for bloat, sorry. > > One persons "bloat" is another persons "added functionality".
It would seem this board did not suffer from the lack of this particular functionality before, and I would say that a board should stay at least as functional as it was when it was added. Replacing existing functionality with random unrelated new one makes no sense.
Was it tho? I believe we're talking about supporting some additional keys via USB keyboard. This board does in fact expect users to be at the U-Boot prompt via USB keyboard.
How did you reach this conclusion ? It seems to be some sort of devkit.
It came up in one of the previous threads about this board and what we can / cannot do about the size constraint and the board maintainers unhappiness about the overall size growth and broken releases (until size growth became a link error on the platform).
Link please ? It sounds relevant to this thread too.
https://lists.denx.de/pipermail/u-boot/2019-April/365297.html
> I believe > the specific changes in question that once again push this board over > fall in to that grey area. Whatever size-trimming the board maintainer > is fine with next is fine with me, but needs to get ack'd by someone.
Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem.
But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well.
The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
On Fri, Nov 22, 2019 at 03:56:14AM +0100, Marek Vasut wrote:
On 11/22/19 3:53 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 02:38:51AM +0100, Marek Vasut wrote:
On 11/22/19 2:30 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 02:27:16AM +0100, Marek Vasut wrote:
On 11/22/19 1:32 AM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 01:23:56AM +0100, Marek Vasut wrote: > On 11/21/19 11:45 PM, Tom Rini wrote: >> On Thu, Nov 21, 2019 at 11:01:43PM +0100, Marek Vasut wrote: >>> On 11/21/19 10:59 PM, Heinrich Schuchardt wrote: >>>> On 11/21/19 9:12 PM, Tom Rini wrote: >>>>> On Thu, Nov 21, 2019 at 09:09:29PM +0100, Heinrich Schuchardt wrote: >>>>>> Hello Soeren, >>>>>> >>>>>> when trying to add support for function key support in the USB keyboard >>>>>> driver u-boot.imx for the TBS2910 surpassed the maximum size for >>>>>> u-boot.imx. >>>>>> https://travis-ci.org/marex/u-boot-usb/builds/614059004 >>>>>> >>>>>> Do you remember why on the TBS2910 board this size is limited to >>>>>> 0x5fc00? Other i.MX6 boards like the Wandboard allow a much larger >>>>>> u-boot.imx. >>>>>> >>>>>> The limit is defined here: >>>>>> include/configs/tbs2910.h:80: >>>>>> #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */ >>>>>> >>>>>> Could the value CONFIG_ENV_OFFSET=0x60000 be enlarged? >>>>>> >>>>>> Many i.MX6 defconfigs use CONFIG_ENV_OFFSET=0xC0000. >>>>> >>>>> The nature of these boards (aimed at end users) means that we just do >>>>> not want to / cannot really move the stored environment. Thanks! >>>> >>>> Another possibility would be to reduce the image size by using >>>> CONFIG_REGEX=n which should be fine for a board with only one supported >>>> network interface. >>> >>> But the board was fine before your patchset got applied and this is just >>> a workaround for added bloat, which reduces functionality. I dislike >>> trading functionality for bloat, sorry. >> >> One persons "bloat" is another persons "added functionality". > > It would seem this board did not suffer from the lack of this particular > functionality before, and I would say that a board should stay at least > as functional as it was when it was added. Replacing existing > functionality with random unrelated new one makes no sense.
Was it tho? I believe we're talking about supporting some additional keys via USB keyboard. This board does in fact expect users to be at the U-Boot prompt via USB keyboard.
How did you reach this conclusion ? It seems to be some sort of devkit.
It came up in one of the previous threads about this board and what we can / cannot do about the size constraint and the board maintainers unhappiness about the overall size growth and broken releases (until size growth became a link error on the platform).
Link please ? It sounds relevant to this thread too.
https://lists.denx.de/pipermail/u-boot/2019-April/365297.html
>> I believe >> the specific changes in question that once again push this board over >> fall in to that grey area. Whatever size-trimming the board maintainer >> is fine with next is fine with me, but needs to get ack'd by someone. > > Or, the other option is, make these new extra features configurable and > disable them on this board. And so there should be no size problem.
But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well.
The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms. I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good. Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>> I believe >>> the specific changes in question that once again push this board over >>> fall in to that grey area. Whatever size-trimming the board maintainer >>> is fine with next is fine with me, but needs to get ack'd by someone. >> >> Or, the other option is, make these new extra features configurable and >> disable them on this board. And so there should be no size problem. > > But that direction leads to saying every slight bit of functionality > requires a new Kconfig entry. Some levels of bugfixes as well.
The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
On 22.11.19 04:58, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>>> I believe >>>> the specific changes in question that once again push this board over >>>> fall in to that grey area. Whatever size-trimming the board maintainer >>>> is fine with next is fine with me, but needs to get ack'd by someone. >>> Or, the other option is, make these new extra features configurable and >>> disable them on this board. And so there should be no size problem. >> But that direction leads to saying every slight bit of functionality >> requires a new Kconfig entry. Some levels of bugfixes as well. > The other option is, we will sink in bloat and suffer endless size problems. Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
What a long discussion over night, so only a general answer:
Once upon a time there was plenty of space for tbs2910 u-boot. Then we had to convert everything to DM, for whatever reason. This increased the binary size a lot, had absolutely no advantage for u-boot users, was huge effort for board maintainers, and is still going on. (DM_VIDEO conversion still pending for this board, probably more to come, DM_SERIAL?). For all that additional space is required, apparently nobody tries to cleanup the non-DM code for converted subsystems to reclaim some of the space.
Several times I tried to disable unneeded functions to trim the binary size. After a few weeks the gained space was eaten up, apparently nobody cares about binary size anymore as long as there is no build failure. Even worse, since imx format is padded, people claim to not increase the binary size with there patches (what in fact is not true), and then some simple change / tool update again breaks everything.
What is the solution to that? I don't see much what _I_ can do. If I find some option to disable again, what is increasingly difficult, then this removes the last opportunity for upcoming DM conversions. For the "bloat" vs. "features" discussion: on long existing boards no user expects new features in defconfig, especially if they only come with reduced functionality somewhere else. And as hobbyist board maintainer I don't know which features existing users actually use. I only get bug reports about bricked boards when something is missing.
Soeren
On 11/22/19 11:29 AM, Soeren Moch wrote:
On 22.11.19 04:58, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>>>> I believe >>>>> the specific changes in question that once again push this board over >>>>> fall in to that grey area. Whatever size-trimming the board maintainer >>>>> is fine with next is fine with me, but needs to get ack'd by someone. >>>> Or, the other option is, make these new extra features configurable and >>>> disable them on this board. And so there should be no size problem. >>> But that direction leads to saying every slight bit of functionality >>> requires a new Kconfig entry. Some levels of bugfixes as well. >> The other option is, we will sink in bloat and suffer endless size problems. > Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or > "complete" choice for USB HID devices would make sense and allow us > further areas to reduce size, on the minimal portion. Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
What a long discussion over night, so only a general answer:
Once upon a time there was plenty of space for tbs2910 u-boot. Then we had to convert everything to DM, for whatever reason. This increased the binary size a lot, had absolutely no advantage for u-boot users, was huge effort for board maintainers, and is still going on. (DM_VIDEO conversion still pending for this board, probably more to come, DM_SERIAL?). For all that additional space is required, apparently nobody tries to cleanup the non-DM code for converted subsystems to reclaim some of the space.
Several times I tried to disable unneeded functions to trim the binary size. After a few weeks the gained space was eaten up, apparently nobody cares about binary size anymore as long as there is no build failure. Even worse, since imx format is padded, people claim to not increase the binary size with there patches (what in fact is not true), and then some simple change / tool update again breaks everything.
What is the solution to that? I don't see much what _I_ can do. If I find some option to disable again, what is increasingly difficult, then this removes the last opportunity for upcoming DM conversions. For the "bloat" vs. "features" discussion: on long existing boards no user expects new features in defconfig, especially if they only come with reduced functionality somewhere else. And as hobbyist board maintainer I don't know which features existing users actually use. I only get bug reports about bricked boards when something is missing.
Soeren
Hello Soeren,
what is your view on changing CONFIG_ENV_OFFSET=0x60000 to CONFIG_ENV_OFFSET=0xC0000?
Best regards
Heinrich
On Fri, Nov 22, 2019 at 12:42:49PM +0100, Heinrich Schuchardt wrote:
On 11/22/19 11:29 AM, Soeren Moch wrote:
On 22.11.19 04:58, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
> > > > > > I believe > > > > > > the specific changes in question that once again push this board over > > > > > > fall in to that grey area. Whatever size-trimming the board maintainer > > > > > > is fine with next is fine with me, but needs to get ack'd by someone. > > > > > Or, the other option is, make these new extra features configurable and > > > > > disable them on this board. And so there should be no size problem. > > > > But that direction leads to saying every slight bit of functionality > > > > requires a new Kconfig entry. Some levels of bugfixes as well. > > > The other option is, we will sink in bloat and suffer endless size problems. > > Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or > > "complete" choice for USB HID devices would make sense and allow us > > further areas to reduce size, on the minimal portion. > Or maybe there is a way to help compiler optimize that USB key code > handling better. Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
What a long discussion over night, so only a general answer:
Once upon a time there was plenty of space for tbs2910 u-boot. Then we had to convert everything to DM, for whatever reason. This increased the binary size a lot, had absolutely no advantage for u-boot users, was huge effort for board maintainers, and is still going on. (DM_VIDEO conversion still pending for this board, probably more to come, DM_SERIAL?). For all that additional space is required, apparently nobody tries to cleanup the non-DM code for converted subsystems to reclaim some of the space.
Several times I tried to disable unneeded functions to trim the binary size. After a few weeks the gained space was eaten up, apparently nobody cares about binary size anymore as long as there is no build failure. Even worse, since imx format is padded, people claim to not increase the binary size with there patches (what in fact is not true), and then some simple change / tool update again breaks everything.
What is the solution to that? I don't see much what _I_ can do. If I find some option to disable again, what is increasingly difficult, then this removes the last opportunity for upcoming DM conversions. For the "bloat" vs. "features" discussion: on long existing boards no user expects new features in defconfig, especially if they only come with reduced functionality somewhere else. And as hobbyist board maintainer I don't know which features existing users actually use. I only get bug reports about bricked boards when something is missing.
Soeren
Hello Soeren,
what is your view on changing CONFIG_ENV_OFFSET=0x60000 to CONFIG_ENV_OFFSET=0xC0000?
I am still against that move as we need to address the real underlying problem of size growth.
On 11/22/19 11:29 AM, Soeren Moch wrote:
On 22.11.19 04:58, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>>>> I believe >>>>> the specific changes in question that once again push this board over >>>>> fall in to that grey area. Whatever size-trimming the board maintainer >>>>> is fine with next is fine with me, but needs to get ack'd by someone. >>>> Or, the other option is, make these new extra features configurable and >>>> disable them on this board. And so there should be no size problem. >>> But that direction leads to saying every slight bit of functionality >>> requires a new Kconfig entry. Some levels of bugfixes as well. >> The other option is, we will sink in bloat and suffer endless size problems. > Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or > "complete" choice for USB HID devices would make sense and allow us > further areas to reduce size, on the minimal portion. Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
What a long discussion over night, so only a general answer:
Once upon a time there was plenty of space for tbs2910 u-boot. Then we had to convert everything to DM, for whatever reason. This increased the binary size a lot, had absolutely no advantage for u-boot users, was huge effort for board maintainers, and is still going on. (DM_VIDEO conversion still pending for this board, probably more to come, DM_SERIAL?). For all that additional space is required, apparently nobody tries to cleanup the non-DM code for converted subsystems to reclaim some of the space.
Several times I tried to disable unneeded functions to trim the binary size. After a few weeks the gained space was eaten up, apparently nobody cares about binary size anymore as long as there is no build failure. Even worse, since imx format is padded, people claim to not increase the binary size with there patches (what in fact is not true), and then some simple change / tool update again breaks everything.
What is the solution to that? I don't see much what _I_ can do. If I find some option to disable again, what is increasingly difficult, then this removes the last opportunity for upcoming DM conversions. For the "bloat" vs. "features" discussion: on long existing boards no user expects new features in defconfig, especially if they only come with reduced functionality somewhere else. And as hobbyist board maintainer I don't know which features existing users actually use. I only get bug reports about bricked boards when something is missing.
Thank you for spelling this out, I fully agree with these sentiments.
Hi Everybody,
On 22/11/19 11:29, Soeren Moch wrote:
On 22.11.19 04:58, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>>>> I believe >>>>> the specific changes in question that once again push this board over >>>>> fall in to that grey area. Whatever size-trimming the board maintainer >>>>> is fine with next is fine with me, but needs to get ack'd by someone. >>>> Or, the other option is, make these new extra features configurable and >>>> disable them on this board. And so there should be no size problem. >>> But that direction leads to saying every slight bit of functionality >>> requires a new Kconfig entry. Some levels of bugfixes as well. >> The other option is, we will sink in bloat and suffer endless size problems. > Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or > "complete" choice for USB HID devices would make sense and allow us > further areas to reduce size, on the minimal portion. Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
What a long discussion over night, so only a general answer:
Once upon a time there was plenty of space for tbs2910 u-boot. Then we had to convert everything to DM, for whatever reason. This increased the binary size a lot, had absolutely no advantage for u-boot users, was huge effort for board maintainers, and is still going on. (DM_VIDEO conversion still pending for this board, probably more to come, DM_SERIAL?). For all that additional space is required, apparently nobody tries to cleanup the non-DM code for converted subsystems to reclaim some of the space.
Several times I tried to disable unneeded functions to trim the binary size. After a few weeks the gained space was eaten up, apparently nobody cares about binary size anymore as long as there is no build failure. Even worse, since imx format is padded, people claim to not increase the binary size with there patches (what in fact is not true), and then some simple change / tool update again breaks everything.
What is the solution to that? I don't see much what _I_ can do. If I find some option to disable again, what is increasingly difficult, then this removes the last opportunity for upcoming DM conversions. For the "bloat" vs. "features" discussion: on long existing boards no user expects new features in defconfig, especially if they only come with reduced functionality somewhere else. And as hobbyist board maintainer I don't know which features existing users actually use. I only get bug reports about bricked boards when something is missing.
I come later to the discussion - anyway, I would like to search for a "pragmatic" solution. I think we can discuss a lot about which code flew in and why tbs2910 increases the size, but I do not know if this brings some results. Several changes (see improvements about fdt handling, and so on) are new features, and it is quite bad to surround any new change with a lot of #ifdef just to fit. We cannot discuss if it is correct or not that boards should switch to DM: this was decided a long time ago and decision won't be changed.
We are not talking about big changes in the size: tbs2910 has a low threshold for currrent U-Boot : 392192 and from a build to next build, the size can exceed for "some" bytes. We are not facing a big change, but the board is living on the edge with current U-Boot. I am then quite of Heinrich's opinion, and that the environment should be moved somewhere else to guarantee that board can be supported without fighting any time with the size in future. Soeren has already dropped most of the unused features, and I have no idea if there is something else he can do in this way without dropping used features on the board.
Best regards, Stefano
Hi Stefano,
On Fri, 6 Dec 2019 12:41:47 +0100 Stefano Babic sbabic@denx.de wrote: ...
I come later to the discussion - anyway, I would like to search for a "pragmatic" solution. I think we can discuss a lot about which code flew in and why tbs2910 increases the size, but I do not know if this brings some results. Several changes (see improvements about fdt handling, and so on) are new features, and it is quite bad to surround any new change with a lot of #ifdef just to fit. We cannot discuss if it is correct or not that boards should switch to DM: this was decided a long time ago and decision won't be changed.
We are not talking about big changes in the size: tbs2910 has a low threshold for currrent U-Boot : 392192 and from a build to next build, the size can exceed for "some" bytes. We are not facing a big change, but the board is living on the edge with current U-Boot. I am then quite of Heinrich's opinion, and that the environment should be moved somewhere else to guarantee that board can be supported without fighting any time with the size in future. Soeren has already dropped most of the unused features, and I have no idea if there is something else he can do in this way without dropping used features on the board.
I'm currently looking for ways to slightly reduce image size to convert this board to DM_VIDEO. Yesterday I've submitted two patches for video uclass, this is still not enough to be able to build the board with DM_VIDEO enabled. I'm currently trying to drop dead or useless code from mxc_ipuv3 driver and also tried to remove device tree nodes for stuff not used in U-Boot. This might give us a few kilobytes of image size reduction and DM_VIDEO could probably work (at least when using gcc-8.1). But I'm expecting new bloat when next merge window opens and new patches will be merged, this board will fail again. Moving the environment would help a lot.
-- Anatolij
On Fri, Dec 06, 2019 at 01:30:44PM +0100, Anatolij Gustschin wrote:
Hi Stefano,
On Fri, 6 Dec 2019 12:41:47 +0100 Stefano Babic sbabic@denx.de wrote: ...
I come later to the discussion - anyway, I would like to search for a "pragmatic" solution. I think we can discuss a lot about which code flew in and why tbs2910 increases the size, but I do not know if this brings some results. Several changes (see improvements about fdt handling, and so on) are new features, and it is quite bad to surround any new change with a lot of #ifdef just to fit. We cannot discuss if it is correct or not that boards should switch to DM: this was decided a long time ago and decision won't be changed.
We are not talking about big changes in the size: tbs2910 has a low threshold for currrent U-Boot : 392192 and from a build to next build, the size can exceed for "some" bytes. We are not facing a big change, but the board is living on the edge with current U-Boot. I am then quite of Heinrich's opinion, and that the environment should be moved somewhere else to guarantee that board can be supported without fighting any time with the size in future. Soeren has already dropped most of the unused features, and I have no idea if there is something else he can do in this way without dropping used features on the board.
I'm currently looking for ways to slightly reduce image size to convert this board to DM_VIDEO. Yesterday I've submitted two patches for video uclass, this is still not enough to be able to build the board with DM_VIDEO enabled. I'm currently trying to drop dead or useless code from mxc_ipuv3 driver and also tried to remove device tree nodes for stuff not used in U-Boot. This might give us a few kilobytes of image size reduction and DM_VIDEO could probably work (at least when using gcc-8.1). But I'm expecting new bloat when next merge window opens and new patches will be merged, this board will fail again. Moving the environment would help a lot.
I really want to not change the environment as I see it as a reminder that no, we need to address some of the underlying problems. The constraints imposed by the platform aren't unreasonable.
That said, I would also be happy to see patches to re-work the buildman toolchain logic to fetch the appropriate set of "builds something that works" toolchains as while there are 8.1.0 toolchains from kernel.org we need at least I believe 8.3 for both all ARM and x86 to work.
On 06.12.19 15:02, Tom Rini wrote:
On Fri, Dec 06, 2019 at 01:30:44PM +0100, Anatolij Gustschin wrote:
Hi Stefano,
On Fri, 6 Dec 2019 12:41:47 +0100 Stefano Babic sbabic@denx.de wrote: ...
I come later to the discussion - anyway, I would like to search for a "pragmatic" solution.
I'm not at all against a pragmatic solution. Tom just added a patch to further reduce binary size of this board.
I think we can discuss a lot about which code flew in and why tbs2910 increases the size, but I do not know if this brings some results. Several changes (see improvements about fdt handling, and so on) are new features, and it is quite bad to surround any new change with a lot of #ifdef just to fit.
Agreed.
We cannot discuss if it is correct or not that boards should switch to DM: this was decided a long time ago and decision won't be changed.
We are not talking about big changes in the size: tbs2910 has a low threshold for currrent U-Boot : 392192 and from a build to next build, the size can exceed for "some" bytes. We are not facing a big change, but the board is living on the edge with current U-Boot. I am then quite of Heinrich's opinion, and that the environment should be moved somewhere else to guarantee that board can be supported without fighting any time with the size in future.
My main concern is user experience. So I very much like the idea of Marek and Tom, at least to think about what can be done from the developers, before we break boards for users.
Moving the environment would brick the board for every updater, probably nobody uses the default environment with modern linux kernels. There are users that only access the environment from running linux. A special serial adapter (sold separately) is necessary for this board, so restoring a lost environment is not easy for everybody. (For me personally there is no problem at all, besides the incoming bug reports from other users about bricked boards.)
Before moving the environment I would consider disabling uncommon boot options, like NFS boot, while leaving TFTP boot enabled in defconfig. That at least would not break the boards for every user, only for hopefully more experienced ones.
Soeren has already dropped most of the unused features, and I have no idea if there is something else he can do in this way without dropping used features on the board.
There is something left, but if nobody cares about binary size, then this will not last long. But this discussion shows that we care about binary size again, great!
I'm currently looking for ways to slightly reduce image size to convert this board to DM_VIDEO. Yesterday I've submitted two patches for video uclass, this is still not enough to be able to build the board with DM_VIDEO enabled. I'm currently trying to drop dead or useless code from mxc_ipuv3 driver and also tried to remove device tree nodes for stuff not used in U-Boot. This might give us a few kilobytes of image size reduction and DM_VIDEO could probably work (at least when using gcc-8.1).
Thanks! Exactly such clean-up work is needed.
Besides that, binary size is not the main reason for the still pending DM_VIDEO conversion. On my first attempt I ended up without video signal at all. I haven't found time yet to investigate that further. Maybe something wrong with the hdmidetect logic to enable HDMI only if a monitor is connected, to not slow down the serial console, where we sometimes loose characters when typing fast and video is enabled.
But I'm expecting new bloat when next merge window opens and new patches will be merged, this board will fail again. Moving the environment would help a lot.
... for developers, while breaking support for users. And that's the target audience we maintain u-boot for, right? https://dict.leo.org/englisch-deutsch/target
I really want to not change the environment as I see it as a reminder that no, we need to address some of the underlying problems.
I support that idea.
Thanks, Soeren
The constraints imposed by the platform aren't unreasonable.
That said, I would also be happy to see patches to re-work the buildman toolchain logic to fetch the appropriate set of "builds something that works" toolchains as while there are 8.1.0 toolchains from kernel.org we need at least I believe 8.3 for both all ARM and x86 to work.
On 06.12.19 17:18, Soeren Moch wrote:
On 06.12.19 15:02, Tom Rini wrote:
On Fri, Dec 06, 2019 at 01:30:44PM +0100, Anatolij Gustschin wrote:
Hi Stefano,
On Fri, 6 Dec 2019 12:41:47 +0100 Stefano Babic sbabic@denx.de wrote: ...
I come later to the discussion - anyway, I would like to search for a "pragmatic" solution.
I'm not at all against a pragmatic solution. Tom just added a patch to further reduce binary size of this board.
I think we can discuss a lot about which code flew in and why tbs2910 increases the size, but I do not know if this brings some results. Several changes (see improvements about fdt handling, and so on) are new features, and it is quite bad to surround any new change with a lot of #ifdef just to fit.
Agreed.
We cannot discuss if it is correct or not that boards should switch to DM: this was decided a long time ago and decision won't be changed.
We are not talking about big changes in the size: tbs2910 has a low threshold for currrent U-Boot : 392192 and from a build to next build, the size can exceed for "some" bytes. We are not facing a big change, but the board is living on the edge with current U-Boot. I am then quite of Heinrich's opinion, and that the environment should be moved somewhere else to guarantee that board can be supported without fighting any time with the size in future.
My main concern is user experience. So I very much like the idea of Marek and Tom, at least to think about what can be done from the developers, before we break boards for users.
Moving the environment would brick the board for every updater, probably nobody uses the default environment with modern linux kernels. There are users that only access the environment from running linux. A special serial adapter (sold separately) is necessary for this board, so restoring a lost environment is not easy for everybody. (For me personally there is no problem at all, besides the incoming bug reports from other users about bricked boards.)
Before moving the environment I would consider disabling uncommon boot options, like NFS boot, while leaving TFTP boot enabled in defconfig. That at least would not break the boards for every user, only for hopefully more experienced ones.
Soeren has already dropped most of the unused features, and I have no idea if there is something else he can do in this way without dropping used features on the board.
There is something left, but if nobody cares about binary size, then this will not last long. But this discussion shows that we care about binary size again, great!
I'm currently looking for ways to slightly reduce image size to convert this board to DM_VIDEO. Yesterday I've submitted two patches for video uclass, this is still not enough to be able to build the board with DM_VIDEO enabled. I'm currently trying to drop dead or useless code from mxc_ipuv3 driver and also tried to remove device tree nodes for stuff not used in U-Boot. This might give us a few kilobytes of image size reduction and DM_VIDEO could probably work (at least when using gcc-8.1).
Thanks! Exactly such clean-up work is needed.
Besides that, binary size is not the main reason for the still pending DM_VIDEO conversion. On my first attempt I ended up without video signal at all. I haven't found time yet to investigate that further. Maybe something wrong with the hdmidetect logic to enable HDMI only if a monitor is connected, to not slow down the serial console, where we sometimes loose characters when typing fast and video is enabled.
But I'm expecting new bloat when next merge window opens and new patches will be merged, this board will fail again. Moving the environment would help a lot.
... for developers, while breaking support for users. And that's the target audience we maintain u-boot for, right? https://dict.leo.org/englisch-deutsch/target
Sorry, no idea where this link comes from...
I really want to not change the environment as I see it as a reminder that no, we need to address some of the underlying problems.
I support that idea.
Thanks, Soeren
The constraints imposed by the platform aren't unreasonable.
That said, I would also be happy to see patches to re-work the buildman toolchain logic to fetch the appropriate set of "builds something that works" toolchains as while there are 8.1.0 toolchains from kernel.org we need at least I believe 8.3 for both all ARM and x86 to work.
On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>>> I believe >>>> the specific changes in question that once again push this board over >>>> fall in to that grey area. Whatever size-trimming the board maintainer >>>> is fine with next is fine with me, but needs to get ack'd by someone. >>> >>> Or, the other option is, make these new extra features configurable and >>> disable them on this board. And so there should be no size problem. >> >> But that direction leads to saying every slight bit of functionality >> requires a new Kconfig entry. Some levels of bugfixes as well. > > The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
If, with your USB custodian hat on, your answer to Heinrich is that his changes expose a more fundamental problem with the code that needs addressing then no, I'm not overriding your objection.
On 11/22/19 4:44 PM, Tom Rini wrote:
On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>>>> I believe >>>>> the specific changes in question that once again push this board over >>>>> fall in to that grey area. Whatever size-trimming the board maintainer >>>>> is fine with next is fine with me, but needs to get ack'd by someone. >>>> >>>> Or, the other option is, make these new extra features configurable and >>>> disable them on this board. And so there should be no size problem. >>> >>> But that direction leads to saying every slight bit of functionality >>> requires a new Kconfig entry. Some levels of bugfixes as well. >> >> The other option is, we will sink in bloat and suffer endless size problems. > > Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or > "complete" choice for USB HID devices would make sense and allow us > further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
If, with your USB custodian hat on, your answer to Heinrich is that his changes expose a more fundamental problem with the code that needs addressing then no, I'm not overriding your objection.
The fundamental problem is that we are letting too much bloat in and now it starts to take over useful functionality on existing devices. I am strongly opposed to this, that's the fundamental problem we need to deal with. Heinrichs' approach only underlined the problem.
participants (6)
-
Anatolij Gustschin -
Heinrich Schuchardt -
Marek Vasut -
Soeren Moch -
Stefano Babic -
Tom Rini