Re: [PATCH v4 0/6] FUSB302 USB-C controller support

[Sören Moch]

On 03.09.24 13:00, Soeren Moch wrote:

Hi Sebastian,

On 31.08.24 15:36, Soeren Moch wrote:
[...]

Unfortunately I see the same problem as in v3: boot loop when powering
the board from my notebook (ThinkPad X1 Nano running Ubuntu 24.04.1
LTS),
see boot log below.

Patch version v2 is still running totally fine in the exact same setup
(patch series on top of u-boot 2024.07, same board, same cabling).

Unfortunately I currently have no access to the miniPC (Zotac ZBOX
CI620)
I used as additional test platform before.

The boot log is unfortunately not very helpful. If you provide an
additional
patch enabling more debug output, I'm happy to retest with that (v2
and/or v4).


Here additional debug messages for the not working case (LOG_DEBUG
enabled):

U-Boot 2024.07-6-g65a73892d9-dirty (Sep 03 2024 - 12:22:42 +0200)

Model: Radxa ROCK 5 Model B
DRAM:  8 GiB
fusb302 usb-typec@22: set pd RX off
fusb302 usb-typec@22: vconn is already off
fusb302 usb-typec@22: TCPM: set polarity = 0
fusb302 usb-typec@22: pd header : sink, device
fusb302 usb-typec@22: TCPM: state change INVALID_STATE -> SNK_UNATTACHED
fusb302 usb-typec@22: TCPM: Start toggling
fusb302 usb-typec@22: TCPM: state change SNK_UNATTACHED -> TOGGLING
fusb302 usb-typec@22: get cc1 = open, cc2 = open
fusb302 usb-typec@22: TCPM: CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING,
polarity 0, disconnected]
fusb302 usb-typec@22: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
fusb302 usb-typec@22: IRQ: VBUS_OK, vbus=On
fusb302 usb-typec@22: IRQ: 0x01, a: 0x40, b: 0x00, status0: 0x82
fusb302 usb-typec@22: IRQ: TOGDONE
fusb302 usb-typec@22: get cc1 = rp-1.5, cc2 = open
fusb302 usb-typec@22: TCPM: CC1: 0 -> 4, CC2: 0 -> 0 [state TOGGLING,
polarity 0, connected]
fusb302 usb-typec@22: TCPM: state change TOGGLING -> SNK_ATTACH_WAIT
fusb302 usb-typec@22: TCPM: pending state change SNK_ATTACH_WAIT ->
SNK_DEBOUNCED @ 200 ms [rev1]
fusb302 usb-typec@22: detected cc1=rp-1.5, cc2=open
fusb302 usb-typec@22: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x92
fusb302 usb-typec@22: IRQ: BC_LVL, handler pending
fusb302 usb-typec@22: BC_LVL handler, status0 = 0x92
fusb302 usb-typec@22: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x92
fusb302 usb-typec@22: IRQ: BC_LVL, handler pending
fusb302 usb-typec@22: BC_LVL handler, status0 = 0x92
fusb302 usb-typec@22: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0xc2
fusb302 usb-typec@22: IRQ: BC_LVL, handler pending
fusb302 usb-typec@22: BC_LVL handler, status0 = 0xd1
fusb302 usb-typec@22: cc1: rp-1.5 -> rp-def
fusb302 usb-typec@22: get cc1 = rp-def, cc2 = open
fusb302 usb-typec@22: TCPM: CC1: 4 -> 3, CC2: 0 -> 0 [state
SNK_ATTACH_WAIT, polarity 0, connected]
fusb302 usb-typec@22: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x92
fusb302 usb-typec@22: IRQ: BC_LVL, handler pending
fusb302 usb-typec@22: BC_LVL handler, status0 = 0x92
fusb302 usb-typec@22: cc1: rp-def -> rp-1.5
fusb302 usb-typec@22: get cc1 = rp-1.5, cc2 = open
fusb302 usb-typec@22: TCPM: CC1: 3 -> 4, CC2: 0 -> 0 [state
SNK_ATTACH_WAIT, polarity 0, connected]
fusb302 usb-typec@22: TCPM: state change SNK_ATTACH_WAIT ->
SNK_DEBOUNCED [delayed 200 ms]
fusb302 usb-typec@22: TCPM: state change SNK_DEBOUNCED -> SNK_ATTACHED
fusb302 usb-typec@22: TCPM: set polarity = 0
fusb302 usb-typec@22: pd header : sink, device
fusb302 usb-typec@22: TCPM: state change SNK_ATTACHED -> SNK_STARTUP
fusb302 usb-typec@22: TCPM: state change SNK_STARTUP -> SNK_DISCOVERY
fusb302 usb-typec@22: TCPM: set vbus = 0 charge = 1
fusb302 usb-typec@22: TCPM: state change SNK_DISCOVERY ->
SNK_WAIT_CAPABILITIES
fusb302 usb-typec@22: set pd RX on
fusb302 usb-typec@22: TCPM: pending state change SNK_WAIT_CAPABILITIES
-> SOFT_RESET_SEND @ 310 ms [rev3]
fusb302 usb-typec@22: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x92
fusb302 usb-typec@22: IRQ: BC_LVL, handler pending
fusb302 usb-typec@22: BC_LVL handler, status0 = 0x92
fusb302 usb-typec@22: IRQ: PD sent good CRC
fusb302 usb-typec@22: Received PD message (header=0x17a1 len=4)
fusb302 usb-typec@22: TCPM: PD RX, header: 0x17a1 [1]
fusb302 usb-typec@22: TCPM: state change SNK_WAIT_CAPABILITIES ->
SNK_NEGOTIATE_CAPABILITIES
fusb302 usb-typec@22: TCPM: cc=0 cc1=4 cc2=0 vbus=0 vconn=sink polarity=0
fusb302 usb-typec@22: TCPM: PD TX, header: 0x1082
fusb302 usb-typec@22: Send PD message (header=0x1082 len=4)
fusb302 usb-typec@22: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x92
fusb302 usb-typec@22: IRQ: BC_LVL, handler pending
fusb302 usb-typec@22: BC_LVL handler, status0 = 0x92
fusb302 usb-typec@22: IRQ: PD tx success
fusb302 usb-typec@22: Received PD message (header=0x161 len=0)
fusb302 usb-typec@22: TCPM: PD TX complete, status: 0
fusb302 usb-typec@22: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x92
fusb302 usb-typec@22: IRQ: BC_LVL, handler pending
fusb302 usb-typec@22: BC_LVL handler, status0 = 0x92
fusb302 usb-typec@22: IRQ: PD sent good CRC
fusb302 usb-typec@22: Received PD message (header=0x9a3 len=0)
fusb302 usb-typec@22: TCPM: PD RX, header: 0x9a3 [1]
fusb302 usb-typec@22: TCPM: state change SNK_NEGOTIATE_CAPA

Re: [PATCH v3 0/7] FUSB302 USB-C controller support

[Sören Moch]

On 08.08.24 15:58, Soeren Moch wrote:



On 02.08.24 19:59, Sebastian Reichel wrote:

Hi,

On ROCK 5B power is usually supplied via it's USB-C port. This port
has the
data lines connected to RK3588, VBUS connected to the input regulator
and
CC pins connected to FUSB302. FUSB302 is a USB-C controller, which
can be
accessed via I2C from RK3588. The USB-C controller is needed to
figure out
the USB-C cable orientation, but also to do USB PD communication.
Thus it
would be great to enable support for it in the operating system.

But the USB-PD specification requires, that a device reacts to USB-PD
messages
send by the power-supply within around 5 seconds. If that does not
happen the
power-supply assumes, that the device does not support USB-PD. If a
device
later starts sending USB-PD messages it is considered an error, which
is solved
by doing a hard reset. A USB-PD hard reset means, that all supply
voltages are
removed for a short period of time. For boards, which are solely powered
through their USB-C port, like the Radxa Rock 5B, this results in an
machine
reset. This is currently worked around by not describing the FUSB302
in the
kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means

1. the USB-C port cannot be used at all
2. the board will be running via fallback supply, which provides limited
    power capabilities

In order to avoid the hard reset, this adds FUSB302 support to
U-Boot, so
that we react to the power-supply's queries in time. The code, which is
originally from the Linux kernel, consists of two parts:

1. the tcpm state machine, which implements the Type C port manager
state
    machine as described in the USB PD specification
2. the fusb302 driver, which knows about specific registers

Especially the first part has been heavily modified compared to the
kernel, which makes use of multiple delayed works and threads. For this
I used a priorly ported version from Rockchip, removed their hacks and
any states not necessary in U-Boot (e.g. audio accessory support).

Sorry for the delay in getting PATCHv3 ready.

Changes since PATCHv2:
  * Rebase to latest master (a70d991212c9)
  * Drop Wang Jie from Cc, since his address bounces
  * I did not add a test suite. I fully agree, that it would be nice
to have
    one, but it is also a lot of work. Just emulating a FUSB302 is
not enough,
    we also need to emulate the remote USB-PD device to make this
useful.
    Without that we would only test what happens when a
non-responsive USB-PD
    supply is attached and that is the boring, very simple path in
this code.
    On the other hand implementing an emulated USB-C PD remote side
more or less
    requires implementing another big state machine.
  * Add documentation for the 'tcpm' command (Simon Glass)
  * I also got asked to add more documentation for the feature in
general. I'm
    not really sure what is needed. At least Tim Harvey managed to
use it
    considering he got stusb4500 working on top of PATCHV2. If there
are more
    specific requests I can write something.
  * Just like PATCHv1, PATCHv2 received a 'Tested-by: Soeren Moch
',
    which I did not take over. This time the changes are a lot
smaller, but
    the different handling of timeouts might have broken something.
(On my end
    things still behave correctly of course, otherwise I wouldn't
have sent
    this series)


FWIW
I retested this v3 series on top of v2024.07. Everything still works
as expected on my rock-5b board with different USB-PD power supplies
(5V, 12V, 20V).

Tested-by: Soeren Moch 

One difference between patch versions 2 and 3 I can observe when
powering from a mini-PC (USB-C port) though:

*** Patch version v2:

U-Boot 2024.07-5-g2000ac570b (Aug 08 2024 - 16:20:40 +0200)

Model: Radxa ROCK 5 Model B
DRAM:  8 GiB
Core:  355 devices, 33 uclasses, devicetree: separate
MMC:   mmc@fe2c: 1, mmc@fe2d: 2, mmc@fe2e: 0
Loading Environment from nowhere... OK
In: serial@feb5
Out: serial@feb5
Err: serial@feb5
Model: Radxa ROCK 5 Model B
Net:   No ethernet found.
Hit any key to stop autoboot: 0
=> tcpm list
| Name    | Parent name | Parent uclass
@ seq
| usb-typec@22    | i2c@feac    | i2c @ 4 |
status: 0
=> tcpm dev usb-typec@22
dev: 0 @ usb-typec@22
=> tcpm info
Orientation: reverse
PD Revision: rev3
Power Role: sink
Data Role: device
Voltage:  5.000 V
Current:  3.000 A
=>

*** Patch version v3:

U-Boot 2024.07-7-g642d8a1c14 (Aug 08 2024 - 15:32:24 +0200)

Model: Radxa ROCK 5 Model B
DRAM:  8 GiB
Core:  355 devices, 33 uclasses, devicetree: separate
MMC:   mmc@fe2c: 1, mmc@fe2d: 2, mmc@fe2e: 0
Loading Environment from nowhere... OK
In: serial@feb5
Out: serial@feb5
Err: serial@feb5
Model: Radxa ROCK 5 Model B
fusb302 usb-typec@22: TCPM: PD transmit data failed: -110
Net:   No ethernet found.
Hit any key to stop autoboot: 0
=> tcpm list
| Name    | Parent name

Re: [PATHv11 26/43] configs/tbs2910_defconfig inc limit

[Sören Moch]

On 06.12.23 11:40, Maxim Uvarov wrote:

On Wed, 6 Dec 2023 at 13:06, Soeren Moch  wrote:

On 05.12.23 21:00, Maxim Uvarov wrote:

On Wed, 6 Dec 2023 at 00:25, Soeren Moch  wrote:

On 05.12.23 17:25, Maxim Uvarov wrote:

On Tue, 5 Dec 2023 at 21:49, Soeren Moch  wrote:

On 05.12.23 14:15, Maxim Uvarov wrote:

I think I solved the size issue on all the boards.

Key changes:
1. remove compilation of original ping.c and tftp.c
(tftp had also server code, so I will partially bring
it back.)

Interesting.
@Tom: Is there other server code in u-boot, that is
enabled by default (and can be used to reclaim code space)?
Fur sure I do not need u-boot to act as server for tftp
(maye nfs, others).


Maybe I need to be more clear about this. reference to code
from tftp.c and ping.c exist in net.c,
test/image/spl_load_net.c, test.dm/dsa.c
, test/dm/eth.c.
And even if that code is not used (replaced with lwip calls
to the same commands in my case) it adds additional size.
Even enabled LTO does not see
direct difference.

So 'server code' does not mean u-boot acting as network
server, you mean this code is referenced by something else?
And things in test do increase image size?


This was my question to understand possible options to save space.





2. LTO=y
3. CONFIG_LOGLEVEL=3 instead of 4.
4. CONFIG_CMD_DATE is not set
5. CONFIG_CMD_LICENSE is not set
6. CONFIG_CMD_PING (if 1-6 did not help).

And these changes were enough for CI tagrets to build.
I also tested that Raspberry PI 4B works fine (dhcp,
ping). Looking for other boards to test.

For example for this tbs2910 board changes are:

Disabling CMD_DATE is unfortunate. This can help to
debug RTC problems (already used it for this purpose).
And, if we are that close to the size limit, than maybe
we can get away for this series, but for sure will run
into trouble for every other small change to u-boot
core/driver code.

Regards,
Soeren


The problem is that for many targets the limit is 1MB.

For tbs2910 it is 383kBytes. And there was plenty of free
space when I introduced mainline u-boot support. But yes,
space got tighter over time.


Hm,
orig:
-rw-r--r-- 1 uboot uboot 371K Dec  5 19:54 u-boot.bin
lwip:
-rw-r--r-- 1 uboot uboot 380K Dec  5 19:55 u-boot.bin

Then if I just enable CMD_DATE:
u-boot.imx exceeds file size limit:
  limit:  0x5fc00 bytes
  actual: 0x60c00 bytes
  excess: 0x1000 bytes
make: *** [Makefile:1240: u-boot.imx] Error 1
make: *** Deleting file 'u-boot.imx'
uboot@3eebd85985c8:~/uboot-size$ ls -lh u-boot.bin
-rw-r--r-- 1 uboot uboot 382K Dec  5 19:58 u-boot.bin

So limit for your board is:
(gdb) p 0x5fc00/1024
$1 = 383

383k. Where do you see the space?

Here I do not understand what you want to ask.

As I wrote earlier, yes, tbs2910 limit is 383k, for u-boot.imx,
the number you tried to change in this patch to 408k, but this
change is not possible.

Without your changes there is some space left (not as much as 2014
when I introduced tbs2910 support in u-boot), but enough to make
further u-boot development with unavoidable small image size
increases possible. (size of v2024.01-rc4 u-boot.imx for tbs2910
is 375k).

Regards,
Soeren



Soeren, this patch which changes the limit will not be applied. I will
send another patch which modies defconfig and makes room for lwip stack.
If you want to keep CMD_DATE that is fine, probably we can disable EFI
for this board or something else.

Random changes in board configs are usually not helpful. In general
board maintainers know constraints of there boards and required features.

For tbs2910 I already tried hard (with help of Tom and others) to
decrease image size as much as possible. Only in supported network
protocols and features I see possible options for further code space
savings. Since network stacks seem to be your area of expertise, any
hints or proposals to remove something here are welcome. You already
mentioned 'server code' that  is probably not required for this board. I
would like to learn more about this.

Regards,
Soeren



BR,
Maxim.



BR,
Maxim.


U-Boot in some minimal configuration is about 500kb. But
U-boot with EFI, USB, Eth drivers,  MMC, RTC, and all the
commands is 900+ kb and very close to 1MB. Most of the new
features are enabled by default.

No. Tom does a very good job to ensure that there is no (not
much) addition

Re: [PATCH v2 15/16] tbs2910: revert prepare to synchronise device trees with linux

[Sören Moch]

On 22.10.22 23:59, Marcel Ziswiler wrote:

From: Marcel Ziswiler 

Now with all synchonised revert
"tbs2910: prepare to synchronise device trees with linux".

This reverts commit 50b229523bbc5511e1bace34df779f84950bf872.

Signed-off-by: Marcel Ziswiler 

Acked-by: Soeren Moch 

---

(no changes since v1)

  arch/arm/dts/imx6q-tbs2910-u-boot.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/imx6q-tbs2910-u-boot.dtsi 
b/arch/arm/dts/imx6q-tbs2910-u-boot.dtsi
index d48719e7d5..65ab052ac2 100644
--- a/arch/arm/dts/imx6q-tbs2910-u-boot.dtsi
+++ b/arch/arm/dts/imx6q-tbs2910-u-boot.dtsi
@@ -1,6 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0+

-&{/soc/bus@200} { /* AIPS1 */
+&aips1 {
u-boot,dm-pre-reloc;
  };

@@ -8,7 +8,7 @@
u-boot,dm-pre-reloc;
  };

-&{/soc} {
+&soc {
u-boot,dm-pre-reloc;
  };

Re: [PATCH 2/2] board: tbs2910: Convert to DM_SERIAL

[Sören Moch]

Hi Simon,

On 14.03.22 20:37, Simon Glass wrote:

Hi Soeren,

On Mon, 14 Mar 2022 at 13:22, Soeren Moch  wrote:


On 14.03.22 19:28, Tom Rini wrote:

On Mon, Mar 14, 2022 at 12:24:36PM -0600, Simon Glass wrote:

Hi Soeren,

On Mon, 14 Mar 2022 at 02:26, Soeren Moch  wrote:

... to get rid of the build warning.
Unfortunately we still need the board specific serial pin init code.
Otherwise the first boot messages over the serial console are lost.

Signed-off-by: Soeren Moch 
---
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Tom Rini 
Cc: Simon Glass 
Cc: u-boot@lists.denx.de

The whole purpose of DM is somewhat defeated when we still need board
specific initializations. Any ideas how we can get all boot messages
without board specific inits? 'u-boot,dm-pre-reloc;' in the uart device
tree node did not help.

You can put that in your serial driver, perhaps? Or in the initial SoC
init code?

Why should I do so? The whole point of DM is initializing devices from
DT. And when I wish to do so pre-relocation, it is advertised in DM to
add 'u-boot,dm-pre-reloc;' for this purpose. I tried, it did not work.
And this is nothing closely related to the serial driver itself, I just
want the pin setup running pre-relocation and not as late as it is
running now under DM_SERIAL.

If you have a pinctrl driver it will be used. I don't really
understand your problem.

My problem is that pin initializations come too late (just before the
"Core" boot message).
Apparently I have a pinctrl driver, otherwise the pin init would not be
done at all, I guess.

I also do not want to run this pin setup twice (first in board or SoC
code and again by DM_SERIAL later). Maybe I miss something obvious, but
duplication of the setup code cannot be a proper solution.

Well the pinctrl will be triggered before relocation and after, if
enabled. We could solve that but have not tried.

My problem is not runtime, if initialization is done twice from the same
code this is probably OK. In my setup pins are _not_ initialized before
relocation, when not done in board_early_init_f() "by hand", which I
would like to avoid since this results in code duplication.
Do I need to enable the before-relocation part somewhere? When yes, how
exactly? 'u-boot,dm-pre-reloc;' in the uart DT node (as documented) did
not work.

Another recent way (in -next) is to use events to monitor the
EVT_DM_PRE_PROBE event for the serial driver.

I can monitor the probe event, OK. But how can this solve my problem?
Again, maybe I miss something obvious, please tell me when I do so.

It's just the same thing every single imx platform is doing.


Sorry, I don't understand what you mean here. The reference platform for
my board is mx6sabresd. This is not converted to DM_SERIAL yet. Most (?)
imx boards use SPL, pin setup is different there.
I looked into imx boards with DM_SERIAL. They either removed the
board-specific setup code (which results in missing early boot messages:
u-boot version, board name, DDR size, ...) or they are playing tricks in
SPL (not the clean and easy solution that DM promises). Maybe I missed a
better reference for the DM_SERIAL conversion without SPL. Can you point
me to such board?

If you want to use pinctrl in SPL, you can do all of this cleanly. If
you have code-size constraints, then you may want to do something like
rockchip, where only specific peripherals are supported in pinctrl in
SPL.

I do not use SPL, only U-Boot proper.


You could look at firefly-rk3288 (or bob/coral/jerry) which I believe
is done fully with driver model.

I want a proper solution without SPL, see above.

Perhaps Tom has a better handle on the problem.

"Great." You are forcing everyone in DM conversions with deadlines. This
conversion does not work as documented. When asked for help you only
provide answers to different questions than what was asked. And you
conclude with "create your own solution or ask someone else", at least
this is as I understand this.

All this while DM conversions only bring additional work for maintainers
of existing boards, DM conversions always come with increased code size,
and only in the best case everything works like before.

On the other hand you complain about slow conversions and maintainers
that wait for the very end of the deadline. Do you see the relation?


So I ask you again, Simon. How is this DM_SERIAL conversion supposed to
be done properly? In general and especially for imx boards without SPL?
Or is all this as incomplete as it looks like? In this case the
conversion probably will again last until the end of the real deadline,
about 3 years from now. And it will be done as in this patch (with your
Reviewed-by blessing), papering over the fact that all the old code is
still active, only the build warning is silenced. Exactly what we want
to avoid, bigger code not better code. I hope we can clean this up in a
follow-up patch.

Regards,
Soeren


Regards,
Simon

Re: U-Boot atheros PHY support and cubox ethernet

[Sören Moch]

Hi Fabio,

On 24.06.20 22:29, Fabio Estevam wrote:
> Hi Soeren,
>
> On Wed, Jun 24, 2020 at 5:13 PM Soeren Moch  wrote:
>
>> Schematics are at
>> https://www.tbsdtv.com/download/document/tbs2910/TBS2910-Matrix-ARM-mini-PC-SCH_rev2.1.pdf
> Here is another patch for you to try:
> https://pastebin.com/raw/Dkipgq1n
Still no luck:


U-Boot 2020.07-rc5-00039-g4ff63383e3-dirty (Jun 24 2020 - 22:36:43 +0200)

CPU:   Freescale i.MX6Q rev1.2 at 792MHz
CPU:   Commercial temperature grade (0C to 95C) at 47C
Reset cause: POR
Model: TBS2910 Matrix ARM mini PC
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   vga
Err:   vga
Net:   eth0: ethernet@2188000
PCI:
PCI:   pcie phy link never came up
No such bus
starting USB...
Bus usb@2184000: usb dr_mode not found
Bus usb@2184200: USB EHCI 1.00
scanning bus usb@2184000 for devices... 1 USB Device(s) found
scanning bus usb@2184200 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
Matrix U-Boot> dhcp
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
Matrix U-Boot> mdio list
FEC0:
4 - AR8035 <--> ethernet@2188000
Matrix U-Boot>

Re: [PATCH v2][ 1/3] tbs2910: disable fuse command

[Sören Moch]

On 28.01.20 18:04, Denis 'GNUtoo' Carikli wrote:
> The fuse command is not needed for booting or during usual
> users interactions with u-boot.
>
> As that the resulting u-boot.imx image is already very
> close to the size limit, removing the fuse command shouldn't
> hurt.
>
> With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola
> GNU/Linux distribution, it shrinks the image from 392192 to
> 388096 bytes.
>
> Signed-off-by: Denis 'GNUtoo' Carikli 
The fuse command is useful for tbs2910, especially for 1.x board revisions.
So

NAK.

Soeren

Re: [U-Boot] tbs2910 not buildable

[Sören Moch]

Hi Stefano,

On 14.04.19 13:24, Stefano Babic wrote:
> Hi Soeren,
>
> On 14/04/19 12:46, Soeren Moch wrote:
>> Hi Stefano,
>>
>> On 14.04.19 11:52, stefano babic wrote:
>>> Hallo Soeren,
>>>
>>> after pulling from Tom and merging u-boot-imx, - next, your board is not
>>> buildable anymore. Better: it is buildable, but size exceeds:
>>>
>>>arm:  +   tbs2910
>>> +u-boot.imx exceeds file size limit:
>>> +  limit:  392192 bytes
>>> +  actual: 396288 bytes
>>> +  excess: 4096 bytes
>>>
>>> Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this
>>> board), solves the issue. I can do myself in this way or let me know
>>> what is your preferred way.
>>>
>> Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it
>> is supposed to provide a full PC environment. It supports booting from
>> SATA, and such disk may as well be partitioned with EFI. It is really
>> terrible to drop user visible features, just to support a new "driver
>> model" that is supposed to ease life for developers, but in fact is much
>> work and a real pain for maintainers of existing boards, and brings
>> exactly nothing for the board's users.
> I have explained my concerns in the past about footprint, too, but there
> is nothing I can do.
I know, therefore I cc'd Tom.
> This is the way we have to go on and we have to
> find solutions.
>
>> So much for that. Now to your question.
>>
>> Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more
>> important to get this series merged, because other boards also depend on
>> the SATA patches. We can readd EFI_PARTITION support later. For sure
>> there will be more patches in this development cycle.
>> But if you can wait a few hours, I will look for a better solution, or
>> send a formal patch for this CONFIG_EFI_PARTITION removal.
> Today is Sunday, I have also not expected you was fast to answer ;-)
>
> It is also fine for me to wait until tomorrow.
OK, I will send a patch for that.

Regards,
Soeren
> I just want to sent PR to
> Tom as soon as possible, because there are many developers waiting for
> the merge from -next. tbs2910 is the only board with issues from Travis,
> and I can confirm that it is still ok on u-boot-imx, next. Something new
> is slipped down between 2019.rc4 and 2019.04 and at the end had
> increased again the footprint.
>
> Thanks for checking this,
>
> Stefano Babic
>

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Sören Moch]

On 10.01.19 16:53, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
>> Hi Tom, Soeren,
>>
>> On 09/01/19 23:39, Tom Rini wrote:
> [snip]
>>>  Why default?  Well, "everyone"
>>> agrees that defaulting to EFI application support means the widest
>>> choice of out of the box software support.
>> I am unsure about this - just my two cents.
>>
>> I agree with you if we are talking about evaluation boards and / or
>> boards supposed to run different distros (or in any case, more flavour
>> of software).
>>
>> But there are a lot of "custom" boards (maintained in U-Boot) that runs
>> for a specific project and won't run any other kind of software. If a
>> device is a navigation system, a network controller, or whatever, it
>> will just do this job until its EOL.
>>
>> Specially for older boards, a new feature should not be activated as
>> default. At the beginning, police in U-Boot was to set just what should
>> be required in the bootloader, without setting what is not needed as
>> default. So default was off instead of on.
> So, part of what I'm taking away from all of this is that I really do
> need to see how many people I can bcc at once before gmail gets really
> mad at me,  Yes, there's a number of end-user devices we have support
> for in mainline that are intended to be re-used as the manufacturer
> intended.  Part of the Kconfig migration means that they can more easily
> remove stuff they don't want/need than before.  But there's also the
> repurposed boards, and lots of not really clear cut cases, such as the
> tbs2910 where while it's not my call, does fall into the "enable EFI
> loader support for your end users maybe?" category.  And in the end, I
> should have emailed off everyone with a gentle reminder to inspect and
> trim their configs.
>
My view on this:

The overwhelming majority of users use u-boot as _bootloader_, not as
their favorite toy to play around with every two month. Users want
stable software with bugfixes, not fancy new untested features. For a
lot of users it is a real pain if linux does not boot anymore. Often
u-boot updates are done from a running linux system. Often users don't
have access to serial adapters to re-animate bricked boards (e.g. they
are sold separately for tbs2910).

So I really prefer new features disabled on old boards. 'default y' may
be good to include modern features for new platforms. But for old boards
then include "# CONFIG_WHATEVER is not set" in defconfigs.

Let board maintainers do their job in testing new features and activate
them when properly tested on their platform and found useful. Recently a
lot of code is committed to u-boot by the original author without any
reviewed-by or tested-by tags. We should not force the testing effort on
ordinary users by activation of new features by default. Otherwise for
me the risk is too high to rendering user systems un-bootable just by
updating "stable" u-boot releases.

For me the real advantage of Kconfig is that interested users can
_enable_ new features easily, test this and maybe propose as new
defconfig to board maintainers. So there is no disadvantage for
experienced users, and no harm for users that only follow available
howtos and are not able to handle sudden changes in behavior.

Regards,
Soeren

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot