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.