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.