[U-Boot] [linux-sunxi] Re: Basic A33 support including dram init available in my personal repo

[Vishnu Patekar]

Hello,
It's sensible work by Allwinner to release the dram code under GPLv2.

Now, we can have mainline u-boot support for A33 soon.

Hans,
Yes, I've very basic A33 dts created based on A23, still lot to do.

I'll send the u-boot patches soon. so that, you all can review it.

On Sun, Mar 8, 2015 at 5:33 AM, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
>
> On Sat, 07 Mar 2015 20:06:27 +0100
> Hans de Goede <hdegoede at redhat.com> wrote:
>
> > Hi,
> >
> > On 02-03-15 11:25, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 01-03-15 19:42, Vishnu Patekar wrote:
> > >> Allwinner A33 tablets comes with the libdram binary, fortunately I've
> > >> found the libdram code at
> > >> https://github.com/realthunder/a33_bootloader/tree/master/basic_loader/bsp/bsp_for_a67.
> > >
> > > Ah, that is both good and bad...
> > >
> > >> I've integrated it with mainline u-boot, still lot to do to post it to upstream
> > >
> > > Integrated sounds as if you've copied pieces of code from the bsp code you've found
> > > into mainline u-boot. That is a big no no (this the bad part). AFAIK the bsp code
> > > does not come with a GPL license header, and Allwinner does not want to release
> > > these bits under the GPL for whatever reasons, a lot can be said about this, but
> > > in the end currently the bsp code is not GPL licensed, so we cannot use it / copy
> > > from it. There can be no discussion on this, when you're submitting this upstream
> > > you must not have any literal copied code in the patch you're sending upstream.
> > >
> > > You can use non copyrightable information from the bsp sources like register
> > > names and the initialization algorithm (IANAL), but you must 100% write your own
> > > code!
> >
> > Ok, so something (to me) quite unexpected has happened and Allwinner has just
> > released what seems to be ALL there boot0 code under the GPL, it can found here:
> >
> > https://github.com/allwinner-zh/bootloader/tree/master/basic_loader/boot0
> > https://github.com/allwinner-zh/bootloader/tree/master/basic_loader/bsp
> >
> > Specifically interesting for the discussion at hand is:
> > https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/bsp/bsp_for_a33/init_dram/mctl_hal.c
> >
> > Which caries a GPL header now. This completely changes my story above, whatever
> > you have (or had, sorry) was fine. It should still be cleaned up a bit, but all
> > my worries about copy and pasting non GPL code are gone now.
>
> It is strange that this has caught you by surprise, because you had been
> informed about what is going on:
>
>     http://lists.denx.de/pipermail/u-boot/2015-March/207174.html
>
> Basically, we need to thank David and Vishnu for negotiating this with
> Allwinner (and this communication has been going on for some time
> already), which resulted in a reasonable solution in the end. You have
> also played your role well. My intervention was only needed to ensure
> that Vishnu does not get discouraged by your response, which originally
> sounded like only a single less than perfect solution was possible :-)
>
> Yes, we are kinda lucky to have discovered this apparently leaked A33
> dram code. I don't approve the actions of whoever is responsible for
> this leak. But we ended up in a situation where the "bad" guys
> (competitors?) have already got access to the code to learn all the
> "secrets", while the "good" guys (us) could not use the code because
> of the missing license notices. And Allwinner just made a rational
> decision how to deal with it (in the same way as this happened with
> the previous code leaks). Having also the A23, A83T and A80 dram
> code open sourced under the GPL license is very much appreciated.
> It means that U-Boot can get full support for A83T and A80 too.
>
> Special thanks to Vishu for not trying to hide the origin of the A33
> dram code. I particularly like full transparency and honesty in
> handling this case.
>
> I'm still not completely happy about the presence of magic numbers all
> over the place (for example, Rockchip sources for very similar dram
> controllers have proper named identifiers for the hardware register
> bitfields) and other code quality problems. In a prefect world, we
> would also get full documentation for the dram controllers and the
> errata lists. But even the current source code is enough to move
> from the dead point.
>
> --
> Best regards,
> Siarhei Siamashka