Mainlining advice for new (MStar/SigmaStar) ARMv7 SoC family

[Tom Rini]

On Wed, Jun 17, 2020 at 12:44:08AM +0900, Daniel Palmer wrote:

> Hi all,
> 
> I'm attempting to get initial support for MStar/Sigmastar's family of
> ARMv7 chips into Linux
> and I thought I should probably at least attempt to mainling the
> u-boot support while I'm at it.
> 
> I did some googling and couldn't find a "how to mainline a new SoC"
> guide for u-boot so if
> possible could I get some advice on how I should go about this.
> 
> Right now I have a very janky tree that can either piggy back the
> vendor's second stage
> bootloader (bootloader after bootrom) or on some of the chips produce
> an SPL that can
> run straight after the bootrom exits.
> 
> I need to chop it up into acceptable parts but I'm not sure how that would look.
> For Linux I'm attempting to get in a small patch set[0] that adds the
> initial device tree prefixes
> and then adds just enough machine specific bits to get to a shell from
> an initramfs.
> 
> For u-boot would enough to load a kernel very slowly via loady be a good target?
> As the platform is device tree based do I need to wait until my
> prefixes get accepted to even start?

Well, lets see.  It would be good to get the DTS stuff sorted out
upstream first, but so long a you keep U-Boot in sync, that's fine.
It's also fine to piggyback on a vendor prior stage if we can't yet (or
won't, period) be able to replace it.  Similar to how for Linux you're
aiming to start with UART and initramfs, UART and any drivers that
already exist because of shared / re-used IP blocks is a good first
step, and then add drivers on top.

-- 
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/20200618/f473a91b/attachment.sig>