[maemo-leste] [PATCH] arm: Remove nokia_rx51 board
Tom Rini
trini at konsulko.com
Wed Jun 16 23:16:14 CEST 2021
On Wed, Jun 16, 2021 at 10:44:52PM +0200, Merlijn Wajer wrote:
> Hi Tom,
>
> On 16/06/2021 19:37, Tom Rini wrote:
>
> >>>>> 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.
> >
> > My advise is to provide a linkable but not runnable (or, only runnable
> > in QEMU, the problem is the fixed layout of the actual device flash,
> > right?) patch so that we can figure out how and what needs to be tuned
> > where so that we can see what to do about this platform.
> >
>
> It looks to me that there are at least two problems:
>
> * Size of the produced u-boot with additional features could be too large
> * Porting RX51 to DM_USB seemingly also requires porting RX51 to
> device-tree (since OF_CONTROL is required), adding additional complications.
>
> When you ask for patches, are you asking for patches that just enable
> DM_USB and stub functions to make the linking succeed (although it
> clearly won't result in a functional u-boot), or are you asking for
> patches that enable DM_USB and OF_CONTROL, and also port the device to
> device tree? To me it seems like you meant the former, but I'd like to
> confirm.
>
> Also, I believe Ivaylo and Pali are wondering if porting to DTS is a
> hard requirement for porting to DM_USB (since OF_CONTROL would be required)?
So, part of the high level answer here is that long term, yes, enabling
DM for everything is required. That may mean additional infrastructure
work, if we don't already have all of the knobs in place today to let
space constrained platforms like this continue to work. Does that mean
we _have_to_ have OF_CONTROL? Well, today we don't have platdata for
non-SPL/TPL. Saying we can't support this platform without adding as an
option and then enablig OF_PLATDATA for U-Boot itself is something to
bring up on the U-Boot mailing list and cc the relevant custodians.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210616/eb27618a/attachment.sig>
More information about the U-Boot
mailing list