Android port for RISC-V

[vithurson subasharan]

Hi all,
Any news on android port for risc-v?
Thanks,
-regards,
-Vithurson

[Lee Courtney]

+1

[lkcl]

Vithurson, hi.

Android is something that google forced onto the world, pissing off many people in the software libre community (including its own primary developer) by rewriting core GPL software libraries that had existed for decades, as dangerously unprotectable Apache Licensed software.

The result was that ignorant Corporations then assumed that just because these android libraries were Apache licensed, the GPL'd linux kernel source, the GPL'd u-boot source, and many other applications including busybox and ffmpeg could be sponged off of for free and the GPL License blatantly ignored.

This has caused no end of problems and cost the free software community a hell of a lot of money that they are NOT EVEN BEING PAID.

Spongeing at its absolute worst, and google in its utter delusion blithely thinks it is doing the world a favour.

This hypocrisy, of replacing the entirety of standard GNU libraries yet not doing the same for the linux OS and uboot has only just been addressed by google with their new OS, announced last week.

This new OS even has a completely new kernel, nothing to do with the linux kernel, at all.

My point is: the initiative to create android was by google, it is driven by google's revenue and desire to make money from advertising, and if they cannot see a way to make money from a RISCV port of android, then YOU will need to be the one to do the port, yourself.

If you (or anyone) is thinking of waiting for google or any other company with deep pockets to do it, do not hold your breath.

That having been said, if there is truly a large interest in an android port to RISCV, this is going to be the place to make that interest known, and to set up a collaboration to track it.

Just like debian, fedora, and other OSes, it needs *someone* to actually drive the development.

ICubeCorp managed to do a full android port to their IC3128 processor, and that included replacing gcc with a port of the alternative c compiler from SGI, so it cannot be that hard, it will simply require people to actually take the initiative and get on with it instead of waiting for google or some other corporation.

L.

[Jorg Brown]

Re: "dangerously unprotectable Apache Licensed software", if I understand you correctly, you're saying that software not licensed under the FSF CopyLeft license is dangerous... so would you say that RISC-V itself falls into the "dangerously unprotectable" category?

-- Jorg

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/00d92620-8185-4890-8086-fcebb1130011%40groups.riscv.org.

[lkcl]

On Tuesday, May 14, 2019 at 12:00:06 AM UTC+8, Jorg Brown wrote:
> Re: "dangerously unprotectable Apache Licensed software", if I understand you correctly, you're saying that software not licensed under the FSF CopyLeft license is dangerous...

Harmful would be a better word. Costing a lot of money, causing harm to users, and so on.

> so would you say that RISC-V itself falls into the "dangerously unprotectable" category?

The question as-is makes no sense, unless you are referring to the RISCV Trademark, which, from my experience with Trafemark Law, the RISCV Foundation is in danger of losing by failing to respond consistently and persistently to questions that result in delay (part of a key stringent criteria that is required for invalidation of a Trademark).

Invalidation of a Trademark is extremely difficult, yet the RISCV Foundation is well on track to achieving that, if they continue to ignore my enquiries.

Other than that, the question is very hard to answer as-is, because it appears yo be conflating several different topics.

Do you mean RISCV software? If so, which software? Kernel, uboot, OSes, tests, user applications, proprietary applications, which do you mean?

Do you mean RISCV hardware designs whose RTL source is released under Apache or BSD Licenses?

Were you referring to the Trademark itself? That is certainly not Apache licensed.

I do appreciate that it is commonplace these days to ask simple short questions, however a little extra context would save the person that you are asking the question of some considerable effort trying to reverse engineer the intent.

Your question took seconds to write, working out what you meant has cost me 20, at 12:30am.

L.

[Bruce Hoult]

On Mon, May 13, 2019 at 8:46 AM lkcl <luke.l...@gmail.com> wrote:

> Android is something that google forced onto the world, pissing off many people in the software libre community (including its own primary developer) by rewriting core GPL software libraries that had existed for decades, as dangerously unprotectable Apache Licensed software.

There is nothing wrong with independent implementations of
standardised interfaces, with different licenses. The BSDs instead of
Linux, for example.

If companies are simply using and modifying GPL software such as the
kernel and not distributing the source, as required by the license,
then that is bad.

> My point is: the initiative to create android was by google, it is driven by google's revenue and desire to make money from advertising, and if they cannot see a way to make money from a RISCV port of android, then YOU will need to be the one to do the port, yourself.
>
> If you (or anyone) is thinking of waiting for google or any other company with deep pockets to do it, do not hold your breath.

This I agree with. If you want it enough, find the time and funding to
get it done.

> ICubeCorp managed to do a full android port to their IC3128 processor, and that included replacing gcc with a port of the alternative c compiler from SGI, so it cannot be that hard, it will simply require people to actually take the initiative and get on with it instead of waiting for google or some other corporation.

Porting a Dalvik-based interpretive VM and the rest of Android on top
of it (and the existing Linux kernel) to RISC-V would not be
difficult, as these things go.

But that's Android as of four years ago.

Porting ART with its native code compilation to RISC-V would be a
major exercise -- maybe a five or ten person-year project, on top of
the work required for a Dalvik-based Android.

(I was in a team at Samsung that worked on Dalvik and ART porting and
enhancements)

[Jorg Brown]

OK, here's some more context.

As I understand it, I can use the RISCV architecture , including RTL, in my own designs, and sell those designs, without having to provide the source code for my changes.

But CopyLeft is all about me having to provide source code for my derivative works.

So when I see you saying that software not licensed under the FSF CopyLeft license is harmful, it seems incompatible with you having anything to do with RISC-V.

Hence my curiosity.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/f7d0b1ea-8206-4c84-aed2-8e40df1cbb8e%40groups.riscv.org.

[lkcl]

On Tuesday, May 14, 2019 at 10:11:59 PM UTC+1, Jorg Brown wrote:

OK, here's some more context.

As I understand it, I can use the RISCV architecture , including RTL, in my own designs, and sell those designs, without having to provide the source code for my changes.

that's only if the RTL is under an Apache or BSD style license.  which the authors, as copyright holders, have the right to choose to do.

some people choose to release hardware designs - including RISC-V implementations - under the GPL and LGPL software license.  this makes a lot of sense particularly in the context of FPGAs.

 

But CopyLeft is all about me having to provide source code for my derivative works.

that's a fundamental misunderstanding due to seeing the "action that needs to be taken" rather than understanding the "why the action needs to be taken". 

the GPL and LGPL are about protecting people from harmful exploitation.

 

So when I see you saying that software not licensed under the FSF CopyLeft license is harmful,

or any other viral license that requires the source code to be provided *and guarantees the right to reproduce and modify the software*

 

it seems incompatible with you having anything to do with RISC-V.

Hence my curiosity.

got it, thanks for the clarificaition.

as you can see above, it appears to be quite common to release hardware RTL under BSD or Apache style licenses.  it is a conflation to assume that this is the only possible license under which to release hardware RTL.

our team for example is, for the most part, releasing hardware RTL source under the LGPLv2+.

hardware is however very very different, because it's not like you can modify the silicon ASIC!  however it is important for our project to *require* that anyone who makes modifications of our product to run on softcore (FPGAs) provides their modifications to others.

this so that we are not solely and exclusively the ones doing the work.

if we released the hardware RTL under an Apache or BSD license, hypothetically, all of our time and effort could be sponged off of and exploited, by a Corporation taking our design, enhancing it significantly, putting it into silicon, making a shed-load of money... and then failing to give us any money in recognition of the hard work that we've put in.

this would result in our *SPONSORS* having to shell out to have the features REPLICATED that the unethical Corporation had already done.

so there are two very different reasons why software licenses are used (regardless of whether it's hardware RTL source or software source):

* a large Corporation with deep pockets (google), or an extremely well-funded Foundation (RISC-V was funded initially by DARPA) will use permissive licenses to kick-start commercial enterprise.  those commercial enterprises will then be entirely free and clear to pathologically exploit end-users for profit, and because of that profit, which is fed back into the large Corporation (or the extremely well-funded Foundation), the cycle of opportunities for unethical exploitation is sustained [1].

* a *small* group that is *not* well funded, and has to utilise *creative intelligence* as a substitute for financial brute force, will deploy a *viral* license as a way to leverage Copyright Law to ensure that their goals and aims propagate, and that everyone, world-wide, benefits from the results.  whilst exploitation *can* still occur, it can occur due to either genuine mistakes (ignorance of Copyright Law), blatant violations (mostly China), or in the case of LG (and Tivo), Lawyers find a workaround.

hope that helps.

l.

[1] several people in the free software community are forced to spend months if not years reverse-engineering android products.  mostly smartphones and tablets.  they don't get paid to waste their time in this fashion.  sometimes it's even their own source code that they're forced to reverse-engineer from binary form.

[Samuel Falvo II]

On Mon, May 13, 2019 at 9:00 AM Jorg Brown <jorg....@gmail.com> wrote:

Re: "dangerously unprotectable Apache Licensed software", if I understand you correctly, you're saying that software not licensed under the FSF CopyLeft license is dangerous... so would you say that RISC-V itself falls into the "dangerously unprotectable" category?

Beware the "RISC-V is an implementation" trap; the RISC-V Instruction Set Architecture documents are just standards.  They're paper proclamations with the intent of ensuring software compatibility between different implementations.  These standards are BSD licensed; implementations of the standard(s) need not be, however.

To that end, the RISC-V ISA is not (and was never intended to be) protectable in the same manner as GPLed works (or, as would perhaps be more apropos for the ISA sepcs, GFDL).  Companies have been routinely encouraged to explore alterations to the ISA (as evidenced by the uncharacteristically large amount of space reserved for 3rd party extensions).  There is no contractual requirement that says these companies have to release their creations back to the community.

--

Samuel A. Falvo II

[Guoyin Chen]

please refer below link which have those code to support riscv64 in Android 10. 

https://lists.riscv.org/g/sig-android/topic/riscv_android_github_repo/86478716?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,86478716,previd=1634907322554533698,nextid=1621599154185391021&previd=1634907322554533698&nextid=1621599154185391021