All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
To: Tom Rini <trini@konsulko.com>
Cc: "Pali Rohár" <pali@kernel.org>,
	maemo-leste@lists.dyne.org, u-boot@lists.denx.de,
	"Merlijn Wajer" <merlijn@wizzup.org>
Subject: Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board
Date: Wed, 16 Jun 2021 20:25:28 +0300	[thread overview]
Message-ID: <d50fd277-a7a3-c8b8-0a29-a0ddd011f465@gmail.com> (raw)
In-Reply-To: <20210616121313.GS9516@bill-the-cat>

Hi,

On 16.06.21 г. 15:13 ч., Tom Rini wrote:
> On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
>> On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
>>> Hi,
>>>
>>> On 15.06.21 г. 15:34 ч., Tom Rini wrote:
>>>> On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
>>>>> Hi,
>>>>>
>>>>> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
>>>>>> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
>>>>>>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
>>>>>>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
>>>>>>>>
>>>>>>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>>>>>>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
>>>>>>>>>> Remove it.
>>>>>>>>>
>>>>>>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>>>>>>>>>
>>>>>>>>> I was waiting waiting half of year because other developers did not
>>>>>>>>> react to issues which were introduced and neither to patches which I
>>>>>>>>> sent (+ trying to remind open issues). And also I was waiting another
>>>>>>>>> half of year until other N900 related patches were merged. So the whole
>>>>>>>>> slowdown was not caused by me, why it is taking so long.
>>>>>>>>>
>>>>>>>>> Now there is still one N900 DM related patch waiting for review. I'm
>>>>>>>>> converting code step by step.
>>>>>>>>>
>>>>>>>>> So the ball is not on my side.
>>>>>>>>
>>>>>>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
>>>>>>>
>>>>>>> I don't see any open patches from you that look related to enabling
>>>>>>> DM_USB on the platform.  If you want to disable USB on the platform for
>>>>>>> now instead, that's fine too.
>>>>>>
>>>>>
>>>>> I tried to migrate the latest master to DM_USB, but unfortunately the
>>>>> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
>>>>> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
>>>>> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
>>>>> less than 256k of storage space for the u-boot, the produced binary cannot
>>>>> be used on n900 the same way current (no DM_USB) binary is used.
>>>>>
>>>>> As I see it, there are not much options left - u-boot on N900 is not SPL, so
>>>>> we can't use OF_PLATDATA, which in turn always links libfdt.
>>>>> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
>>>>> the board to be converted to DT and this is way bigger change.
>>>>>
>>>>> Please advice on how to proceed.
>>>>
>>>> Please post your WIP patches, thanks.
>>>>
>>>
>>> Sorry, I am not sure I understand what patches you want me to post:
>>>
>>> WDT patch has already been sent couple of months ago -
>>> https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
>>> Do you want it to be rebased and resend?
>>>
>>> DM_USB, I just started writing one and I immediately hit the OF_CONTROL
>>> requirement. Enabling OF_CONTROL requires a full blown migration to DT,
>>> which is a huge task and not really equal to "Please update the board to use
>>> CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
>>>
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> DWARF error: could not find abbrev number 3998
>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
>>> <artificial>:(.text+0x5672): undefined reference to
>>> `ofnode_read_u32_default'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> <artificial>:(.text+0x568c): undefined reference to
>>> `ofnode_read_u32_default'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
>>> <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
>>> undefined reference to `dm_scan_fdt_dev'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
>>> undefined reference to `dm_scan_fdt_dev'
>>>
>>> Fixing those requires enabling of OF_CONTROL and this in turn means the
>>> board must be migrated to DT, unless I am missing something. That's why my
>>> "please advice..." stance.
>>
>> Please post the patches that bring you to the above link errors, yes,
>> thanks.
> 
> To be clearer, finish up a patch that completes the migration but is too
> large to install on the hardware so that others can take a look.
> 

I am not sure I understand that - a patch that completes the migration 
to DM_USB cannot be done ATM as the binary does not link without 
OF_CONTROL. And I am not going to enable OF_CONTROL as this means I will 
have to migrate everything to DT. That's why I enable DM_USB only - see 
reply to the other mail.

Thanks,
Ivo

  reply	other threads:[~2021-06-16 17:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19  1:26 [PATCH] arm: Remove nokia_rx51 board Tom Rini
2021-05-19 13:27 ` Pali Rohár
2021-05-19 14:27   ` Oleh Kravchenko
2021-05-19 15:03     ` Pali Rohár
2021-05-19 15:52   ` Tom Rini
2021-05-21 14:44     ` Tom Rini
2021-05-21 21:36       ` Pali Rohár
2021-05-21 22:26         ` Tom Rini
2021-06-15  5:40         ` [maemo-leste] " Ivaylo Dimitrov
2021-06-15 12:34           ` Tom Rini
2021-06-16  6:02             ` Ivaylo Dimitrov
2021-06-16 11:52               ` Adam Ford
2021-06-16 11:55                 ` Pali Rohár
2021-06-16 12:10               ` Tom Rini
2021-06-16 12:13                 ` Tom Rini
2021-06-16 17:25                   ` Ivaylo Dimitrov [this message]
2021-06-16 17:37                     ` Tom Rini
2021-06-16 20:44                       ` Merlijn Wajer
2021-06-16 21:16                         ` Tom Rini
2021-06-16 21:03                       ` Ivaylo Dimitrov
2021-06-16 21:12                         ` Tom Rini
2021-06-16 21:16                           ` Pali Rohár
2021-06-16 21:20                             ` Tom Rini
2021-06-16 21:35                               ` Pali Rohár
2021-06-17  7:18                           ` Ivaylo Dimitrov
2021-06-17 18:21                             ` Tom Rini
2021-06-16 17:21                 ` Ivaylo Dimitrov
2021-05-19 19:06 ` Pavel Machek
2021-05-19 20:02   ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d50fd277-a7a3-c8b8-0a29-a0ddd011f465@gmail.com \
    --to=ivo.g.dimitrov.75@gmail.com \
    --cc=maemo-leste@lists.dyne.org \
    --cc=merlijn@wizzup.org \
    --cc=pali@kernel.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.