Better way to upstream a single-board computer?

[Neil Armstrong]

Hi Lucas,

On 13/06/2023 12:02, Lucas Tanure wrote:
> Hi,
> 
> I have been trying to port Vim4 to Mainline for the past few weeks.
> Downstream branch:
>    https://github.com/khadas/linux/tree/khadas-vims-5.4.y
> 
> - First approach: The compatible string way
> In that 5.4 branches, clean the device tree to the bare minimum to
> have a serial console, sd-card mount and ethernet, and reduce the
> kernel config to only build the necessary modules.
> With those 2 in hand (minimum dts and config), I could port the
> necessary drivers for which the dts have compatible strings. I did
> manage to boot once a v6.3 kernel with that dts and config.
> But it would hang a few seconds after booting the kernel. And after a
> few days of trying to debug the problem without success, I decided to
> move to another approach.
> 
> - Second approach: The fat patch
> I compared a clean 5.4 branch and khadas 5.4 branch and generated a
> big fat patch with around 2.5 million lines, where when applied to
> clean 5.4, it would boot and work.
> I started to chop the fat patch to remove stuff that did not need to
> get vim4 working with only serial, ethernet and sd-card.
> I managed to reduce to 1.3 million lines the fat patch, but after
> that, things started to hang and crash, so I was unable to move on.
> At this point, I realized that 5.4 khadas was actually an
> Android12-5.4 branch with amlogic and khadas stuff.
> 
> - Thrid approch: The android fat patch
> I am doing the same thing as the second approach but using an
> android12-5.4-lts branch as the start, where the comparison shows me
> only the amlogic and khadas changes made.
> I am still going through this method, but it is promising. Right now,
> I have the fat patch with 0.9 million lines.
> My idea here is that when that fat patch becomes small enough, I can
> apply it to a clean 5.4 (no Android) to work it out more. And when
> that patch becomes something tinny, I could apply it on mainline,
> adjusting for the kernel version jump.
> 
> - Fourth approach: The rebase way (On hold)
> I could compare the android12-5.4-lts git log with the khandas-5.4 log
> and start to cherry-pick patches to a clean 5.4 (no Android), but from
> experience, I think that's going to take forever, and it would be very
> hard to apply patches as they refer to an Android branch, not
> mainline.
> 
> The intermediate goal is to have a patch on top of the mainline that
> boots vim4, no matter how ugly. With that in hand, I can start
> re-structuring and getting ready for upstream.
> 
> Now my question for the community:
> Is there a better way to port a board to the mainline when you only
> have an old kernel that boots?

The way I personally use and most Linux developers use is the iterative
way, start from vanilla upstream linux and add small features after
each others while upstreaming at the same time.

First a basic console boot, then pinctrl, resets, clocks, mmc, ...
and then keep the "multimedia" stuff when you have basic providers
functional (clocks, reset, pinctrl, power domains).

So first, upstream the initial bindings for the SoC & board, and a minimal
DT with only UART & CPU0 without nothing else. (Like is done for S4)

Starting from the vendor kernel is a loss of time because Amlogic
does a lot of incompatible changes from upstream and you will spend
a lot of time reverting their changes to mimim upstream.

Neil

> 
> Thanks
> Lucas Tanure
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic