Introductions and Allwinner documentation update

[Simos Xenitellis]

Hi All,

After the recent thread about interview questions to Allwinner,

https://groups.google.com/d/topic/linux-sunxi/OMe3pcilb3Y/discussion

I got an email from Kevin (Allwinner, Manager at Linux kernel development group) and Sugar (Allwinner, Linux kernel development group) that they will provide technical support to the community directly. 

I cc: both of them in this mail.

One of the important issues is that of the documentation and the availability of official documentation for the Axx range of Allwinner SoCs. So, I asked for that and got a reply that

1. Allwinner has set up a team to deal with those documents.

2. It will take a bit of time to produce the documents, and the first delivery is expected in September.

3. It will include a. user manual, b. datasheet and c. schematics

4. From them on, once a document is ready, it will be released as soon as possible.

I think this is good news regarding the documentation, and I am looking forward to the first delivery.

The other issue is that of "mainlining", getting Allwinner chipset support in the latest version of the Linux kernel. There is a wiki page for that, at http://linux-sunxi.org/Linux_mainlining_effort

There are several drivers that need work, and I think it is best to start off with something small.

I had a chat with Jon and he suggested (among others) LRADC.

Regarding the LRADC, there is a patch by Hans de Goede,

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/thread.html#222516

This patch was sent for inclusion to the mainline, but was not accepted yet.

There is an older discussion here with comments on what to change,

https://groups.google.com/d/topic/linux-sunxi/Xq-egaBfzwA/discussion

Would that be a good starting point? If so, click on the URL above and continue the discussion.

Jean-Luc published today his interview with Allwinner (Ben-El Baz, Marketing Manager) at 

http://www.cnx-software.com/2014/08/21/interview-with-allwinner-regarding-their-linaro-membership/

(and also posted the link in another thread).

In the comments at Jean-Luc's interview you can see Ben replying, and he is willing to help.

I think it is a positive interview and there is interest in Allwinner to work with the community and get the latest version of the Linux kernel to support the SoCs. It is a learning experience for them and I hope we start solving all those pending issues.

What I find important is to start first with small but important issues so that they get completed quickly, and we can figure out what works well in this effort, and what we need to do better.

It is a great opportunity, let's make the most out of it!

Simos

[jons...@gmail.com]

My suggestion was to pick something small and then work through the
process of mainlining the driver. The main purpose is to get
Allwinner used to process of submitting a driver for review and then
making the needed changes to get it accepted into mainline.

Some small drivers would be.. LRADC, touch panel, high speed timer.
Medium sized would be the camera driver. But any driver works.

>
> Regarding the LRADC, there is a patch by Hans de Goede,
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/thread.html#222516
> This patch was sent for inclusion to the mainline, but was not accepted yet.
>
> There is an older discussion here with comments on what to change,
> https://groups.google.com/d/topic/linux-sunxi/Xq-egaBfzwA/discussion
>
> Would that be a good starting point? If so, click on the URL above and
> continue the discussion.
>
>
> Jean-Luc published today his interview with Allwinner (Ben-El Baz, Marketing
> Manager) at
> http://www.cnx-software.com/2014/08/21/interview-with-allwinner-regarding-their-linaro-membership/
> (and also posted the link in another thread).
>
> In the comments at Jean-Luc's interview you can see Ben replying, and he is
> willing to help.
>
> I think it is a positive interview and there is interest in Allwinner to
> work with the community and get the latest version of the Linux kernel to
> support the SoCs. It is a learning experience for them and I hope we start
> solving all those pending issues.
> What I find important is to start first with small but important issues so
> that they get completed quickly, and we can figure out what works well in
> this effort, and what we need to do better.
>
> It is a great opportunity, let's make the most out of it!
> Simos
>

> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Jon Smirl
jons...@gmail.com

[Luc Verhaegen]

First and foremost, the many GPL violations have to get resolved.

Luc Verhaegen.

[Luc Verhaegen]

Oh, and the lack of boot0 code for A23 is holding support for it back on
u-boot. DRAM has so far never appeared in any documentation, so without
boot0 code, no u-boot support.

Luc Verhaegen.

[jons...@gmail.com]

And just exactly how is this supposed to happen when Allwinner doesn't
own the IP and their IP license prevents release of the
code/documentation? It might be more productive to pursue the actual
companies causing the problem like ARM Inc withholding Mali. A first
step here would be to determine if code is being withheld that
Allwinner has the ability to release.

One case might be the NAND controller driver. It is unclear if that is
Allwinner's IP or if it is licensed. uboot release is likely this
same issue.

I'd like to see CedarX code released but there is no GPL violation
there because CedarX has not been released into a GPL environment. I
also don't see that the HawkviewISP library is a violation either
since it is also in user space. But I'd still like to see code for it
released.

We all know about Mali and release of Mali is not in Allwinner's control.

Is there source code for other kernel drivers being withheld?

>
> Luc Verhaegen.

[Maxime Ripard]

Hi,

On Fri, Aug 22, 2014 at 07:59:33PM +0300, Simos Xenitellis wrote:

> Hi All,
>
> After the recent thread about interview questions to Allwinner,
> https://groups.google.com/d/topic/linux-sunxi/OMe3pcilb3Y/discussion
> I got an email from Kevin (Allwinner, Manager at Linux kernel development
> group) and Sugar (Allwinner, Linux kernel development group) that they will
> provide technical support to the community directly.
> I cc: both of them in this mail.

Hi Kevin, Shuge :)

>
> One of the important issues is that of the documentation and the
> availability of official documentation for the Axx range of Allwinner SoCs.
> So, I asked for that and got a reply that
> 1. Allwinner has set up a team to deal with those documents.
> 2. It will take a bit of time to produce the documents, and the first
> delivery is expected in September.
> 3. It will include a. user manual, b. datasheet and c. schematics
> 4. From them on, once a document is ready, it will be released as soon as
> possible.
>
> I think this is good news regarding the documentation, and I am looking
> forward to the first delivery.

Very good. Thanks a lot to the three of you for getting this
done. This is a very nice step forward.

> The other issue is that of "mainlining", getting Allwinner chipset support
> in the latest version of the Linux kernel. There is a wiki page for that,
> at http://linux-sunxi.org/Linux_mainlining_effort
> There are several drivers that need work, and I think it is best to start
> off with something small.
> I had a chat with Jon and he suggested (among others) LRADC.
>
> Regarding the LRADC, there is a patch by Hans de Goede,
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/thread.html#222516
> This patch was sent for inclusion to the mainline, but was not accepted yet.
>
> There is an older discussion here with comments on what to change,
> https://groups.google.com/d/topic/linux-sunxi/Xq-egaBfzwA/discussion
>
> Would that be a good starting point? If so, click on the URL above and
> continue the discussion.

This would be very nice to have some code coming from you guys. I
agree with Jon that you should start with some drivers simple enough
so that you focus on getting used to the mainlining process without
much interference from the technical side. Off the top of my head, I
guess A31's GPADC or PWM drivers (the suggested LRADC, touch panel and
high speed timers are already supported or worked on). Or, in the
LRADC or touch screen case, porting those drivers to the A31/A23 if
the IP changed.

That could also be the addition of a new board (the A23 development
board maybe?)

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Maxime Ripard]

On Fri, Aug 22, 2014 at 09:17:08PM +0200, Maxime Ripard wrote:
> > The other issue is that of "mainlining", getting Allwinner chipset support
> > in the latest version of the Linux kernel. There is a wiki page for that,
> > at http://linux-sunxi.org/Linux_mainlining_effort
> > There are several drivers that need work, and I think it is best to start
> > off with something small.
> > I had a chat with Jon and he suggested (among others) LRADC.
> >
> > Regarding the LRADC, there is a patch by Hans de Goede,
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/thread.html#222516
> > This patch was sent for inclusion to the mainline, but was not accepted yet.
> >
> > There is an older discussion here with comments on what to change,
> > https://groups.google.com/d/topic/linux-sunxi/Xq-egaBfzwA/discussion
> >
> > Would that be a good starting point? If so, click on the URL above and
> > continue the discussion.
>
> This would be very nice to have some code coming from you guys. I
> agree with Jon that you should start with some drivers simple enough
> so that you focus on getting used to the mainlining process without
> much interference from the technical side. Off the top of my head, I
> guess A31's GPADC or PWM drivers (the suggested LRADC, touch panel and
> high speed timers are already supported or worked on). Or, in the
> LRADC or touch screen case, porting those drivers to the A31/A23 if
> the IP changed.
>
> That could also be the addition of a new board (the A23 development
> board maybe?)

Oh, and something else you could do, even though you did it a bit in
the past, is to review the patches that are sent.

It might seem a bit backward, but it usually help to understand how
the review usually goes. And that would be really helpful, since you
are obviously the most knowledgable about your SoCs.

[Luc Verhaegen]

Why do you assume that i am talking about Mali? Where did that come
from?

libnand is allwinner code, because we have seen an earlier version of
it. We need to see all versions of it. We know that our older libnand is
killing newer nand contents. I am wasting my time playing with livesuit
on tracking that down now.

CedarX includes GPLed code, the symbols list clearly proves that. But
let me go dig that out _again_ and properly stick it in the wiki, as, as
usual, no-one else seems to bother.

As for libisp, that appeared in the kernel as well, so let me go dig
that out completely as well.

These are things that, whether Allwinner owns them or not, simply cannot
ignored, and it is up to allwinner to resolve them.

For those who hadn't bothered to look on the wiki:
http://linux-sunxi.org/GPL_Violations
I _will_ now go do the legwork there as well.

Luc Verhaegen.

[Hans de Goede]

Hi,

On 08/22/2014 06:59 PM, Simos Xenitellis wrote:
> Hi All,
>
> After the recent thread about interview questions to Allwinner,
> https://groups.google.com/d/topic/linux-sunxi/OMe3pcilb3Y/discussion
> I got an email from Kevin (Allwinner, Manager at Linux kernel development
> group) and Sugar (Allwinner, Linux kernel development group) that they will
> provide technical support to the community directly.
> I cc: both of them in this mail.

Hi Kevin, Shuge,

I think it is great that Allwinner wants to get more involved in
upstream sunxi support.

As one of the 2 custodians (maintainers) for the upstream u-boot
support for sunxi devices, I would like to ask Allwinner to also
get more involved in upstream u-boot support. Ideally Allwinner
would switch to using upstream u-boot entirely, including using
a standard u-boot SPL, rather then chainloading an older u-boot
fork through boot0 and boot1.

I can understand that completely switching to upstream u-boot
will take time, and that you may need some additional features
in upstream u-boot before you can switch. In the mean time it
would be great if you could help us extend the existing sunxi
support in upstream u-boot. Currently we support sun4i, sun5i
and sun7i. We would love to also support sun6i and sun8i (and
the A80).

We already have some limited sun6i and sun8i support in the linux-sunxi
u-boot-sunxi git repository. The biggest stumbling block keeping
us from adding support for sun6i and sun8i is the lack of code
to initialize the DRAM controller. It would be a big help for
us if you could share the boot0 code for sun6i and sun8i with
us, either under an open license, or with an explicit permission
notice for copy and pasting parts of that code and releasing the
result under a GPLv2+ license.

If you've any questions about or suggestions for upstream
sunxi u-boot support please send a mail to me and Ian Campbell
(the other sunxi custodian, whom I've added to the CC).

Regards,

Hans


p.s.

Note that even though I'm using my company's email address for this,
that I do my sunxi u-boot / Linux work on a personal title.

[Enrico]

Il giorno venerdì 22 agosto 2014 18:59:56 UTC+2, Simos Xenitellis ha scritto:

Hi All,

After the recent thread about interview questions to Allwinner,

https://groups.google.com/d/topic/linux-sunxi/OMe3pcilb3Y/discussion

I got an email from Kevin (Allwinner, Manager at Linux kernel development group) and Sugar (Allwinner, Linux kernel development group) that they will provide technical support to the community directly. 

I cc: both of them in this mail.

One of the important issues is that of the documentation and the availability of official documentation for the Axx range of Allwinner SoCs. So, I asked for that and got a reply that

1. Allwinner has set up a team to deal with those documents.

2. It will take a bit of time to produce the documents, and the first delivery is expected in September.

3. It will include a. user manual, b. datasheet and c. schematics

4. From them on, once a document is ready, it will be released as soon as possible.

I think this is good news regarding the documentation, and I am looking forward to the first delivery.

Hi Kevin and Sugar,

documentation about the A10/A20 tv decoder (tv in) would be great.
I'm one of the maintainers of the meta-sunxi openembedded layer, you can contact me directly.

Enrico
 

[Henrik Nordström]

fre 2014-08-22 klockan 19:45 +0200 skrev Luc Verhaegen:

> First and foremost, the many GPL violations have to get resolved.

Lets try to look forward instead. Discussions about GPL violations
rarely get anywhere positive.

What should the environment look like around Allwinner products built
from mainline kernel + u-boot + system?

What are we missing to get there?

What is required to sustain such environment in a healthy state for both
the community and Allwinner?

Regards
Henrik

[Marius Cirsta]

  Agreed but I see respecting the GPL as a first sign of a company "growing up" if you will. You'll never catch Samsung with GPL violations that it doesn't resolve so if Allwinner wants up there with the big boys ( and I think it is getting there ) these issues need to be resolved. If Allwinner does not own the code it needs to get permission from those that do to make it GPL or just find ways around it like Mali, PowerVr which is not ideal at all but ... it's legal.
  Anyway I get frustrated with closed source and GPL violations too but let's try and be constructive here, at least the attitude at Allwinner seems to be changing in the right direction. 

[ditma...@gmail.com]

Am Sonntag, 24. August 2014 22:33:28 UTC+2 schrieb Henrik Nordström:

> ...

> What are we missing to get there?

> What is required to sustain such environment in a healthy state for both
>
> the community and Allwinner?

I think we should fokus on feature that prevent users from taking the mainline. So the KMS Video is a must have to run the kernel as a simple gui server. That will attrac more people to use mainline !

[Simos Xenitellis]

I have put the points in this thread on the wiki, at
http://linux-sunxi.org/AllwinnerUpstream

Feel free to refine.

Simos

[Henrik Nordström]

sön 2014-08-24 klockan 17:02 -0700 skrev Marius Cirsta:

> Agreed but I see respecting the GPL as a first sign of a company
> "growing up" if you will.

There is two ways to "grow up".

a) Trying to do the right thing and gradually learn how.

b) Getting sued when not doing it.

Path 'a' is much preferred, but all the big players you mention have
already tried 'b' repeatedly and some even figured out that 'a' is
better approach.

But to explain my earlier comment. There is parts in the current SDK
which will take quite a effort to get "GPL cleaned", and the bulk of it
have very limited interest mid/long term for the community or is
positioned in the category "need to find a way around GPL".

Regards
Henrik

[Sugar]

Hi all,

Yes, I understand those problems. Allwinner plan to open physical logic
layer code, but datasheet about nand controller is also not opened. And I
can offer some help to you, when you develop it.

> CedarX includes GPLed code, the symbols list clearly proves that. But
> let me go dig that out _again_ and properly stick it in the wiki, as, as
> usual, no-one else seems to bother.
>

The newest version have deleted those symbols, will exclude FFmpeg code. We
will open CedarX source code, except hardware-related on A80 SDK, also will
offer some docs about hardware-lib. But it would be a few months later.

> As for libisp, that appeared in the kernel as well, so let me go dig
> that out completely as well.
>
> These are things that, whether Allwinner owns them or not, simply cannot
> ignored, and it is up to allwinner to resolve them.

We will resolve these probelms step by step.

>
> For those who hadn't bothered to look on the wiki:
> http://linux-sunxi.org/GPL_Violations
> I _will_ now go do the legwork there as well.
>
> Luc Verhaegen.

> .
>
NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it.

[Sugar]

Hi Hans,

On 2014/8/23 21:34, Hans de Goede wrote:
> Hi,
>
> On 08/22/2014 06:59 PM, Simos Xenitellis wrote:
>> Hi All,
>>
>> After the recent thread about interview questions to Allwinner,
>> https://groups.google.com/d/topic/linux-sunxi/OMe3pcilb3Y/discussion
>> I got an email from Kevin (Allwinner, Manager at Linux kernel development
>> group) and Sugar (Allwinner, Linux kernel development group) that they will
>> provide technical support to the community directly.
>> I cc: both of them in this mail.
>
> Hi Kevin, Shuge,
>
> I think it is great that Allwinner wants to get more involved in
> upstream sunxi support.
>
> As one of the 2 custodians (maintainers) for the upstream u-boot
> support for sunxi devices, I would like to ask Allwinner to also
> get more involved in upstream u-boot support. Ideally Allwinner
> would switch to using upstream u-boot entirely, including using
> a standard u-boot SPL, rather then chainloading an older u-boot
> fork through boot0 and boot1.

In my personal opinion, I also very very agree it.

>
> I can understand that completely switching to upstream u-boot
> will take time, and that you may need some additional features
> in upstream u-boot before you can switch. In the mean time it
> would be great if you could help us extend the existing sunxi
> support in upstream u-boot. Currently we support sun4i, sun5i
> and sun7i. We would love to also support sun6i and sun8i (and
> the A80).

Thanks your works. I will try my best to offer some help to upstrem
u-boot. If you have any questions, you can free contact me.

>
> We already have some limited sun6i and sun8i support in the linux-sunxi
> u-boot-sunxi git repository. The biggest stumbling block keeping
> us from adding support for sun6i and sun8i is the lack of code
> to initialize the DRAM controller. It would be a big help for
> us if you could share the boot0 code for sun6i and sun8i with
> us, either under an open license, or with an explicit permission
> notice for copy and pasting parts of that code and releasing the
> result under a GPLv2+ license.

Sorry, I do not have the relevant code. I will tell these things to
my colleagues. They will discuss and decide whether to open source code
about DRAM or not.

>
> If you've any questions about or suggestions for upstream
> sunxi u-boot support please send a mail to me and Ian Campbell
> (the other sunxi custodian, whom I've added to the CC).
>
> Regards,
>
> Hans
>
>
> p.s.
>
> Note that even though I'm using my company's email address for this,
> that I do my sunxi u-boot / Linux work on a personal title.

[Luc Verhaegen]

On Tue, Sep 02, 2014 at 09:07:22PM +0800, Sugar wrote:
> Hi all,
>
> On 2014/8/23 3:54, Luc Verhaegen Wrote:
>>
>> libnand is allwinner code, because we have seen an earlier version of
>> it. We need to see all versions of it. We know that our older libnand is
>> killing newer nand contents. I am wasting my time playing with livesuit
>> on tracking that down now.
>>
> Yes, I understand those problems. Allwinner plan to open physical logic
> layer code, but datasheet about nand controller is also not opened. And I
> can offer some help to you, when you develop it.

Ok, wait and see.

>> CedarX includes GPLed code, the symbols list clearly proves that. But
>> let me go dig that out _again_ and properly stick it in the wiki, as, as
>> usual, no-one else seems to bother.
>>
> The newest version have deleted those symbols, will exclude FFmpeg code.

This is simply not credible. You could have just renamed those functions
and tables. If this is what Allwinner claims is the solution to all
problems, then i will once again have to go burn a load of my time and
verify that the code is actually quite different this time round.

So really, just stating "We fixed it now" is not cutting it. Allwinner
will have to do way more to clear its name.

> We
> will open CedarX source code, except hardware-related on A80 SDK, also will
> offer some docs about hardware-lib. But it would be a few months later.

Ok, wait and see to what extent Allwinner will make things right here.
But as said, the copy-pasting of LGPL code will require way more than
the simple statement "we removed it now".

>> These are things that, whether Allwinner owns them or not, simply cannot
>> ignored, and it is up to allwinner to resolve them.
> We will resolve these probelms step by step.

Yes, we expected that this would not be solved immediately in one big
swoop.

> NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it.

Please get rid of this notice when posting to our ml, that legalese
really does not match an open mailing list for an open source project :)

Also, I flagged your posts through, but please take a minute to
subscribe to our mailing list:
http://linux-sunxi.org/Mailing_list#Subscription

Thanks,

Luc Verhaegen.

[Luc Verhaegen]

On Tue, Sep 02, 2014 at 09:37:53PM +0800, Sugar wrote:
> Hi Hans,

>
>> We already have some limited sun6i and sun8i support in the linux-sunxi
>> u-boot-sunxi git repository. The biggest stumbling block keeping
>> us from adding support for sun6i and sun8i is the lack of code
>> to initialize the DRAM controller. It would be a big help for
>> us if you could share the boot0 code for sun6i and sun8i with
>> us, either under an open license, or with an explicit permission
>> notice for copy and pasting parts of that code and releasing the
>> result under a GPLv2+ license.
> Sorry, I do not have the relevant code. I will tell these things to
> my colleagues. They will discuss and decide whether to open source code
> about DRAM or not.

There is no legal requirement for Allwinner to release this code. This
code is of course boot0, as the mdfs code in the kernel is GPLed and
must be released. The lack of this functionality in u-boot is however
seriously hampering the support of the affected SoCs, and Allwinner has
little option but to solve this. Its open source involvement will just
not be credible otherwise.

How this gets solved is up to Allwinner. Releasing Boot0 code is
probably going to get the quickest results. Getting just register
information (like what is missing in the user manuals) should also solve
this problem, although it might require some extra help from Allwinner
to get things going. Ideally, we get all of the above: code, register
information, and a technical contact to help us fill in the blanks.

Luc Verhaegen.

[Henrik Nordström]

tis 2014-09-02 klockan 21:37 +0800 skrev Sugar:

> Sorry, I do not have the relevant code. I will tell these things to
> my colleagues. They will discuss and decide whether to open source code
> about DRAM or not.

At this stage I think it's more relevant to try to get the DRAM
controller reasonably documented. Even just a list of registers and
their bits is helps greatly. We can fill in some blanks, and ask for
clarification on specific details when there is doubt. At least the
A10/A13/A20 DRAM controllers.

I am not asking that Allwinner provide perfect documentation or drivers,
only that we work together to collect the information the community
(where Allwinner is one part) needs for developing and maintaining
support for the range Allwinner SoCs in mainline u-boot and kernel.

Source code helps somewhat, but source code like what is in boot0/boot1
is only of limited help. While such source code gets us over the initial
hurdle of at all booting the CPU, it still leaves too many unknowns for
maintaining and unifying code. These bits of code needs to be maintained
by the community for years to come and unified across different
generations based on mostly the same DRAM controller with modifications.

Regarding NANDC my request is mostly the same. I do not request that
your NAND FTL like block driver is fully open sourced, or even that
Allwinner writes another driver which can be open sourced if it can't.
But we do need to have reasonable register descriptions to make use of
the NAND controller no matter if the driver is written by Allwinner or
other members of community. But luckily at the moment I think we have
learnt most bits of the NAND controller in A10/A13/A20 etc and main
culpit is now to get Linux and u-boot main NAND framework up to level
for using it proper. Note that I haven't looked at all at what the NAND
controller looks like in the later SoC generations.



And one little detail to keep in mind for business side of things. Every
kernel or u-boot piece that includes binary-only components is a problem
for the Open Source community as these those components can not be used
without violating the license of u-boot or kernel.

Both kernel and u-boot are GPLv2 licensed, which in essense means you
are allowed to use the code almost as you wish without restrictions as
long as you provide the source code of any additions or modifications
you make to the code. That's really all the license is about.
Binary-only additions is not allowed.

Regards
Henrik