Re: [OpenWrt-Devel] Java compiler

[Dana Myers]

On 4/10/2020 1:48 PM, W. Michael Petullo wrote:

Has anyone tried to build a Java compiler package for OpenWrt? I am
investigating doing this. I see the lang/jamvm JVM, but no compiler
akin to devel/gcc or lang/golang. I have packaged a number of things,
but I suspect this will be a bit more of a challenge. Hence my question
here.


In a related context, I recently wrote:
-
I updated classpath and jamvm over 5 years ago to support a project I am no 
longer
involved with. Upstream jamvm has not changed in almost 6 years, with language
support frozen at Java 8. Upstream classpath has not changed in 8 years, with
language support frozen at Java 7. (My project was specifically compiled at 
v1.5).

jamvm depends on classpath; if classpath is removed, jamvm should be as well.
I am no longer in a position to actively maintain either of these packages.
-

So, Java support in OpenWRT arguably requires starting with the JVM and
making sure it supports a modern revision of the language. Then, either
updating classpath to a modern version or possibly adopting the classlib from
OpenJDK. With this done, you may be able to run Java classes compiled with
modern tools; IIRC, support for v1.5 compilation was removed from the
JDK several versions ago.

[ Also, My application pared-down classpath to just the necessary classes; even 
if
the OpenWRT platform in use has a lot of memory, classloading from flash
is _slow_. ]

Running JDK (javac) per se on OpenWRT strikes me as not being worth the effort.
Just getting the Java run-time environment modernized on OpenWRT is a
full-time job :-)

Cheers,
Dana


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches

[Dana Myers]

On 12/20/2018 7:54 AM, Alberto Bursi wrote:

So no, the 4/32 warning should stay and remain loud and clear so newbies won't 
be frustrated by low end devices.


Not sure what "newbie" means in this context. Though I suppose the
warning makes sense objectively.

Cheers,
Dana


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware platform?

[Dana Myers]

On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote:

>/On 2/22/2017 6:18 PM, L. D. Pinney wrote: />//>//>/spi-mt7621.c has bugs ... isn't very 
helpful. />//>//>/I am a bit surprised you're not already aware of the SPI issues. />//>//I 
am not surprised at all ... ALL of my MT76x8 devices have only a single
SPI-NOR Chip connected to the SPI.
On every device it works as intended ... load the OS.


Of course - that's surely why this hardware bug in the MediaTek SPI peripheral
escaped from the factory; they implement and document functionality (full-duplex
operation), and either didn't test it or didn't regard the bug as critical. The
critical use-case of the SPI port is to read the flash device, which is 
half-duplex,
but that's not the only documented use of the SPI port.

MediaTek documents the SPI port as a general peripheral (and provides
an additional select line), and there's a bug in the hardware.

Whenever you (or anyone) adds functionality to a device you can expect
problems.

Thanks, though this isn't relevant at all. I'm not *adding* functionality to 
the device.
There's a bug in the SPI controller that's exposed when you try to use it as 
documented.


In this case some device foreign to the actual device in question.
More specifically a device such as a RFID module or STM32.

This isn't the case at all. There's a bug in the MediaTek SPI controller 
completely
independent of what (if anything) is attached to it. Simply attempting to *send*
a byte in full-duplex mode results in corrupted bits coming out of the MediaTek
SPI Master-Out line. It has absolutely nothing to do with external devices. 
It's a
bug in the MediaTek controller.

This has been interesting bit of bikeshedding, but back to my original question.


If you have a working patch...You can start here :



https://lede-project.org/docs/guide-developer/the-source-code


I have a working patch. I know how to do a PR. I know how to RTFM :-)
Which brings us full-circle to my initial query...

My concern (as alluded to in the subject line) is that I have a patch that
I know for certain is required for the MT7688 and I've tested on the MT7688.
I don't have other MT76xx variants to  to verify the presence of the hardware
bug, so I'm reluctant  to generically apply the patch to spi-mt7621.c - my
question is how to apply this patch for only the mt7688 target.

However, the more I think about it, I strongly suspect this bug is present
on all variants of the MT76xx, so the patch should be generically applied;
I need to find confirmation; I'll try contacting MediaTek.

Thanks,
Dana  K6JQ






You can start here:
>//>/https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20 />//>/which links to another forum thread which contains this *very* informative />/posting: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12266 />//>/and suggested patch: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12299 />//>/which is the basis of the patch I'm using. />//>/Please describe the problem? />//>/berniwa does a much better job than me in the above-linked posting. />//>//>/Can I reproduce the same problem on one of my many MT76x8 devices? />/If so how? />//>//>/I've only seen reports of the issue on MT7688-based devices (LinkIt 7688, />/Omega2) />/and I personally have observed it on the Omega2. />//>/The easiest way to reproduce it is to attempt to send an SPI sequence />/starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll />/find />/the leading '1' bit is sent as a '0'. />//>/I'd be somewhat surprised if the same issue wasn't present on all devices />/which />/incorporate the MT7621 SPI peripheral given the likelihood that MediaTek />/reproduces the same logic on every chip that includes the peripheral. />//>/The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's />/patch addresses by breaking up a transfer as needed (keeping chip select />/asserted). />//>//>/The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel. />/The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different. />//>//>/Understood; I didn't say that MediaTek was using the *same* patch, but that />/this issue is present on all MT7688 devices and that MediaTek has />/incorporated />/a patch for it. The patch I'm using is for 4.4, of course. />//>/If you could confirm the presence of the issue on other MT7621-based SPI />/peripherals, that would address my initial inquiry indirectly if we could />/just />/patch all instances of the MT7621 SPI build :-) />//>/Cheers, />/Dana K6JQ />//>//>//>//>//>//>/On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-d

Re: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware platform?

[Dana Myers]

On 2/22/2017 6:18 PM, L. D. Pinney wrote:


spi-mt7621.c has bugs ... isn't very helpful.


I am a bit surprised you're not already aware of the SPI issues.

You can start here:

https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20

which links to another forum thread which contains this *very* informative
posting:

http://52.76.69.244/jforum/posts/list/30/3683.page#12266

and suggested patch:

http://52.76.69.244/jforum/posts/list/30/3683.page#12299

which is the basis of the patch I'm using.


Please describe the problem?


berniwa does a much better job than me in the above-linked posting.



Can I reproduce the same problem on one of my many MT76x8 devices?
If so how?


I've only seen reports of  the issue on MT7688-based devices (LinkIt 7688, 
Omega2)
and I personally have observed it on the Omega2.

The easiest way to reproduce it is to attempt to send an SPI sequence
starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll find
the leading '1' bit is sent as a '0'.

I'd be somewhat surprised if the same issue wasn't present on all devices which
incorporate the MT7621 SPI peripheral given the likelihood that MediaTek
reproduces the same logic on every chip that includes the peripheral.

The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's
patch addresses by breaking up a transfer as needed (keeping chip select
asserted).


The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel.
The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different.


Understood; I didn't say that MediaTek was using the *same* patch, but that
this issue is present on all MT7688 devices and that MediaTek has incorporated
a patch for it. The patch I'm using is for 4.4, of course.

If you could confirm the presence of  the issue on other MT7621-based SPI
peripherals, that would address my initial inquiry indirectly if we could just
patch all instances of the MT7621 SPI build :-)

Cheers,
Dana  K6JQ






On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <k...@comcast.net 
<mailto:k...@comcast.net>> wrote:

On 2/22/2017 4:27 PM, L. D. Pinney wrote:

Are you using https://github.com/OnionIoT/source 
<https://github.com/OnionIoT/source> onion-omega2 branch ?



I am not; I'm using https://github.com/lede-project/source 
<https://github.com/lede-project/source> (master branch)

However, I don't believe it makes any difference - spi-mt7621.c appears
to be identical in both and the same patch applies; and this isn't an
Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
Labs patched their LinkIt repo for this. A fix really belongs upstream.

Thanks -
Dana



On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k...@comcast.net 
<mailto:k...@comcast.net>> wrote:


I'm working with the Onion Omega2, which is based on an MT7688 SoC.
The MT7688 SoC is a variant of the MT76xx family; in particular, it
shares the same SPI peripheral. Support for SPI is in 
/drivers/spi/mt7621.c

However, there's  bugs with the SPI in the MT7688 which require a patch
to spi-mt7621.c - and I don't know if the same bugs are present in the
other MT76xx family members. It is possible the other MT76xx SoCs have
the same hardware issue (I'd be surprised if not) but I can only test
the MT7688 I have.

I think I want to patch the source file only when building only the 
MT7688
target, but I'm not sure how to do that or if it's supported.

So I'm looking for advice on how I might incorporate this patch so
that it is only applied when building ramips/mt7688.

Thanks,
Dana K6JQ
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
<https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>







___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware platform?

[Dana Myers]

On 2/22/2017 4:27 PM, L. D. Pinney wrote:

Are you using https://github.com/OnionIoT/source onion-omega2 branch ?



I am not; I'm using https://github.com/lede-project/source (master branch)

However, I don't believe it makes any difference - spi-mt7621.c appears
to be identical in both and the same patch applies; and this isn't an
Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
Labs patched their LinkIt repo for this. A fix really belongs upstream.

Thanks -
Dana



On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k...@comcast.net 
<mailto:k...@comcast.net>> wrote:


I'm working with the Onion Omega2, which is based on an MT7688 SoC.
The MT7688 SoC is a variant of the MT76xx family; in particular, it
shares the same SPI peripheral. Support for SPI is in 
/drivers/spi/mt7621.c

However, there's  bugs with the SPI in the MT7688 which require a patch
to spi-mt7621.c - and I don't know if the same bugs are present in the
other MT76xx family members. It is possible the other MT76xx SoCs have
the same hardware issue (I'd be surprised if not) but I can only test
the MT7688 I have.

I think I want to patch the source file only when building only the MT7688
target, but I'm not sure how to do that or if it's supported.

So I'm looking for advice on how I might incorporate this patch so
that it is only applied when building ramips/mt7688.

Thanks,
Dana K6JQ
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
<https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Howto/advice: Patch for variant of hardware platform?

[Dana Myers]

I'm working with the Onion Omega2, which is based on an MT7688 SoC.
The MT7688 SoC is a variant of the MT76xx family; in particular, it
shares the same SPI peripheral. Support for SPI is in /drivers/spi/mt7621.c

However, there's  bugs with the SPI in the MT7688 which require a patch
to spi-mt7621.c - and I don't know if the same bugs are present in the
other MT76xx family members. It is possible the other MT76xx SoCs have
the same hardware issue (I'd be surprised if not) but I can only test
the MT7688 I have.

I think I want to patch the source file only when building only the MT7688
target, but I'm not sure how to do that or if it's supported.

So I'm looking for advice on how I might incorporate this patch so
that it is only applied when building ramips/mt7688.

Thanks,
Dana K6JQ
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Adding host Java support to the buildbots

[Dana Myers]

On 1/2/2017 12:22 AM, Ralph Sennhauser wrote:

On Fri, 30 Dec 2016 06:52:32 -0800
Dana Myers <k...@comcast.net> wrote:


On 12/29/2016 11:50 PM, Ralph Sennhauser wrote:




Another alternative to hotspot on mips would be cacao, again with
openjdk classpath. Though jamvm certainly is a vaild pick.


Without revisiting my selection process from 3 years ago, I did look at the
various alternatives and picked JamVM, and it has proven more than adequate
for my needs. Same thing is true for GNU Classpath.

I needed support for what was historically called the "Connected Device 
Configuration,
Foundation Profile" and the combination of JamVM and Classpath met/meets my 
needs.
Keep in mind that the class of device running OpenWRT is likely to be very 
limited in
terms of memory, and headless as well.

In modern Java terms, I suppose this class of embedded Java use is most
consistent with the "General Connection Framework".


What encumbrance concerns do you have in mind? Debian also ships the
binaries as in openjdk-7-jdk.


Frankly, it was uncertainty on my part regarding embedded use under the
OpenJDK license. It may not be an issue at all; I was more comfortable with
GNU Classpath, it suited my needs, and had the longest history of use with
JamVM (increasing my confidence in stability). I didn't dig into the OpenJDK
licensing details with respect to embedded use.


I don't object to jamvm with gnu classpath, just that I was wondering
why you'd pick it over the alternatives. Basically it's adding java
support that is hardly usable this days apart of a few specialized
cases.


That sounds like a bit of an exaggeration there :-) There's no reason that
support for OpenJDK library and/or additional JVMs can't be integrated into
OpenWRT, though.

Cheers,
Dana
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Adding host Java support to the buildbots

[Dana Myers]

On 12/29/2016 11:50 PM, Ralph Sennhauser wrote:

Hi Dana

On Thu, 29 Dec 2016 12:30:37 -0800
Dana Myers <k...@comcast.net> wrote:


In reference to https://github.com/openwrt/packages/pull/3686

We've added OpenWRT support for:

* JamVM 2.0: Java JVM
* GNU Classpath 2.0: Java class library

There is no classpath 2.0


Right you are - serves me right for spewing version numbers off the top
of my head from something I initially did two years :-) It's classpath 0.99



* RXTX Java serial communications library

However, the build bots won't build these packages yet because
a host Java compiler is required. To build these packages, I
install:

The main reason to use jamvm with gnu classpath is you can bootstrap it
without a jdk, right? If you already require a host jdk why not go for
jamvm with the openjdk classpath to get full java support?


I don't understand the question about bootstrapping and host vs target JDK.
Host JDK is used specifically for javac to compile Java to bytecodes; target has
no dependency on JDK otherwise.

Classpath was, for many years, the only library supported by JamVM, is much
smaller than OpenJDK (valuable on resource-constrained systems) and remains
the default library supported by JamVM. For the purposes of my project from 
which
I contributed, Classpath is adequate and appears to avoid concerns about 
encumbrance
of the target builds/devices with OpenJDK. Most specifically, however, was the 
apparent
lack of support for MIPS32 which is a show-stopper for the AR71xx architecture 
I'm using.

If someone is interested in contributing OpenJDK, I'd be happy to consult.




  openjdk-7-jdk

(which also pulls in openjdk-7-jre and openjdk-7-jre-headless)

What needs to be done to add openjdk-7-jdk to the build bots?


Something like 'apt-get install openjdk-7-jdk' (if I recall correctly, still on 
coffee #1
here).

Cheers,
Dana
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Adding host Java support to the buildbots

[Dana Myers]

In reference to https://github.com/openwrt/packages/pull/3686

We've added OpenWRT support for:

* JamVM 2.0: Java JVM
* GNU Classpath 2.0: Java class library
* RXTX Java serial communications library

However, the build bots won't build these packages yet because
a host Java compiler is required. To build these packages, I
install:

openjdk-7-jdk

(which also pulls in openjdk-7-jre and openjdk-7-jre-headless)

What needs to be done to add openjdk-7-jdk to the build bots?

Thank you,
Dana

danak6jq@github
k...@comcast.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE

[Dana Myers]

On 12/25/2016 10:52 AM, Philip Prindeville wrote:

OpenBikeShed?


Love it! Though it's fair to observe that marketing (which this is at this 
point)
is pretty much 100% bike-shedding.

Cheers,
Dana
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE

[Dana Myers]

On 12/21/2016 6:01 PM, Stefan Monnier wrote:

So maybe it's a good idea to use the (still hypothetical, but hopefully
close) merge to advertise a rename which will both aim to carry-over the
brand recognition at the same time as it sends the message that it's
something "new and better" (i.e. keep the good brand recognition and
try to shed the bad one).


Much +1 here.

Keep in mind, who is the audience of the branding? Us 
(developers/contributors?) or
consumers (that aren't developers or early adopters)? I assert the real audience
is consumers of products that incorporate "the thing".

How do we communicate the unity of developers/contributors to a production
distro without losing the value of the "mother project"?

From a very high level, this is another Linux distro evolution. How do we
communicate that?

Cheers,
Dana
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] update tools/expat to v2.2.0; adds support for building on ARM64/aarch64

[Dana Myers]

I'm building OpenWRT on an Odroid C2 (ARM64); I discovered that expat
(currently v 2.1.0) fails to configure on aarch64 (ARM64). I updated
tools/expat/Makefile to use v2.2.0 and this resolved the issue.

Note this does not change the expat that's built+delivered to the
OpenWRT target; that can remain at 2.1.0, though I plan to ask
the maintainer to update it (or submit a patch myself).

Thanks,
Dana
k...@comcast.net

Signed-off-by: Dana H. Myers 
---
 tools/expat/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/expat/Makefile b/tools/expat/Makefile
index dfd5f28..93e0f74 100644
--- a/tools/expat/Makefile
+++ b/tools/expat/Makefile
@@ -8,10 +8,10 @@
 include $(TOPDIR)/rules.mk

 PKG_NAME:=expat
-PKG_VERSION:=2.1.0
+PKG_VERSION:=2.2.0

-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_MD5SUM:=dd7dab7a5fea97d2a6a43f511449b7cd
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
+PKG_MD5SUM:=2f47841c829facb346eb6e3fab5212e2
 PKG_SOURCE_URL:=@SF/expat

 HOST_BUILD_PARALLEL:=1
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel