Re: [Tinkerphones] Mikrophone

[H. Nikolaus Schaller]

> Am 08.12.2023 um 18:22 schrieb Paul Boddie :
> 
> On Friday, 8 December 2023 15:40:45 CET H.  Nikolaus Schaller wrote:
>> Indeed an interesting approach. But I don't get the benefits. If it is about
>> secure (i.e. end-to-end encrypted) voice and text communication, this can
>> equally securely be done by an open source application running on the app
>> module of two identical devices (which could even be off the shelf). It
>> would also follow the idea to use an unsecure communication
>> channel.
> 
> I think the essence of the motivation for this approach is that the 
> smartphone 
> environment is complicated, opaque and inscrutable (Android or Linux running 
> on an SoC with lots of unaudited functionality) where applications could be 
> doing all sorts of bad things.

Well, if you put an encryption layer above all these unaudited things in the 
application
processor and the worst case can be a denial of service by the unaudited 
components.
It is like you can use https over an untrusted ethernet connection and 
internet... You
only have to trust your https engine. If you use openssl+wget for that task you 
can
audit this shielding layer doing end-to-end encryption without need for a new 
hardware
architecture.

So you can write an Android app that does this encryption by itself. At least 
for
text messaging (provided no rogue component taps the key strokes - but this
is fully auditable in an architecture like the Openmoko devices were).

> Meanwhile, the core telephony environment is 
> simpler, transparent and separated and protected from the untrustworthy 
> smartphone environment.

Well, that is not different from the cellular modem architecture with just an AT
command interface, a data channel and an I2S interface for audio is doing.
Except that you can't dial by it directly.

> Thus, the user can treat the smartphone environment like a sandbox, falling 
> back to the core environment where they need to be sure that nothing is 
> interfering with their communications. It is, I suppose, a bit like the way 
> that Ctrl-Alt-Delete on Windows NT is meant to bring the system to a known 
> state, ensuring that the user is typing their credentials into a dialogue 
> that 
> really is operated by the system and not some rogue program.
> 
> I don't know how mainstream smartphone architectures address various related 
> needs to what this project is addressing. For example, things like emergency 
> calls and alerts should be handled at a lower level than some kind of "app", 
> and yet the introduction of emergency alert systems that do not work with 
> many 
> existing smartphones (the one in Norway and other countries, for instance) 
> suggests that regulatory oversight of such things has been softened.

Well, they usually either have a separate modem subsystem which does all
dialing incl. calling 911. This subsystem contains all radio control protocols
and has to be certified. Everything else is considered an "application 
processor"
and not part of the certification.

To get this certificaition the modem subsystem must run on a separate processor
or the operating system must be audited that everything runs in a safe and
shielded task or thread.

This is likely be the reason why you can't buy Qualcom or Mediatek processors
with integrated wireless functionality. But you can buy radio modules which
contain such a processor and just provide some AT command set. These
are precertified.

> 
>> The only thing he has secured a little more is the display, touch and
>> microphone/speaker. But at the moment he wants to allow a bluetooth headset
>> there is an intrusion vector.
> 
> I imagine that all such add-ons might be untrusted in this scheme.
> 
>> Anyways thanks for making us known to our community.
> 
> No problem! It provides some inspiration and guidance, I suppose.

Indeed.

Best regards,
Nikolaus
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Mikrophone

[H . Nikolaus Schaller]

Hi Paul,

> Am 07.12.2023 um 19:02 schrieb Paul Boddie :
> 
> Hello,
> 
> Here's another phone project, one funded by NLnet, that attempts to partition 
> functionality between different units:
> 
> https://mikrophone.net/
> https://nlnet.nl/project/mikroPhone/

That is a cool name!!!

> 
> Unlike various "privacy-enhanced" products seen previously, however, this one 
> separates core telephony from smartphone functionality, as opposed to trying 
> to control (or simply disconnect) smartphone access to the network. There are 
> still some familiar characteristics, like the separate cellular modem (in the 
> form of the popular SIMCom and Quectel modules) and the use of a dedicated 
> microcontroller for some aspects of the device.
> 
> Unlike other designs where the microcontroller does some kind of 
> bootstrapping 
> exercise related to privacy or "purity", or where mundane functions have been 
> delegated to it, here it is apparently providing a featurephone environment. 
> Indeed, there are two microcontrollers: a primary RISC-V device and a 
> secondary ESP32 device for Wi-Fi and Bluetooth. See this repository directory 
> for an indication of what is going on in the primary microcontroller:
> 
> https://git.majstor.org/mikroPhone/tree/fw/fe310/phone
> 
> For the smartphone functionality, it appears that the project is going to 
> follow the lead of other designs and use an i.MX 8M device. This is 
> supposedly 
> going to run Linux or Android, and it seems that the idea is to give only the 
> microcontroller or the smartphone functionality access to the screen, keypad 
> and communications facilities at any given time.
> 
> Obviously, a single SoC could provide partitioned environments for core 
> telephony and smartphone functionality, with less powerful cores even doing 
> the work of microcontrollers if appropriate. Using an SoC-level device would 
> probably make the core functionality easier to develop and more 
> comprehensive, 
> as well as being more easily extensible. But perhaps the core functionality 
> is 
> regarded as something that does not need to be developed further or, indeed, 
> be much more than what we were all using back in the glory days of Nokia and 
> Ericsson.
> 
> Anyway, it hopefully provides an opportunity to reflect on the way these 
> kinds 
> of products are designed and the choices their designers have made.

Indeed an interesting approach. But I don't get the benefits. If it is about
secure (i.e. end-to-end encrypted) voice and text communication, this can
equally securely be done by an open source application running on the app
module of two identical devices (which could even be off the shelf).
It would also follow the idea to use an unsecure communication
channel.

The only thing he has secured a little more is the display, touch and
microphone/speaker. But at the moment he wants to allow a bluetooth headset
there is an intrusion vector.

Anyways thanks for making us known to our community.

Best regards,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] FOSDEM 2023

[H. Nikolaus Schaller]

Hi,
it looks as if I am not going (it is scheduled for 4 & 5 February 2023).

BR,
Nikolaus

> Am 01.11.2022 um 07:48 schrieb Andreas Kemnade :
> 
> Hi,
> 
> On Tue, 27 Sep 2022 10:40:23 +0200
> "Dr. Michael 'Mickey' Lauer"  wrote:
> 
>> I don’t know about you, but I’m extremely excited
>> about an in-person-FOSDEM 2023. Is anyone of you
>> going? Perhaps even Nikolaus? Would love to catch up,
>> maybe we can arrange a meeting like in „the old times“.
>> 
> at the moment the plan is that I go there.
> 
> Regards,
> Andreas
> ___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] FOSDEM 2023

[H. Nikolaus Schaller]

Hi Mickey,
while it is a good idea, I have no plans to go to FOSDEM.

Best,
Nikolaus


> Am 27.09.2022 um 10:40 schrieb Dr. Michael 'Mickey' Lauer :
> 
> I don’t know about you, but I’m extremely excited
> about an in-person-FOSDEM 2023. Is anyone of you
> going? Perhaps even Nikolaus? Would love to catch up,
> maybe we can arrange a meeting like in „the old times“.
> 
> Best,
> 
> Mickey.
> 
> ___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [OHSW.org] [Tinkerphones-Stammtisch] Happy New Year - and a better new year

[H. Nikolaus Schaller]

> Am 17.09.2022 um 15:33 schrieb David Boddie :
> 
> On Sun Sep 4 22:03:38 CEST 2022, H. Nikolaus Schaller wrote:
> 
>> But as far as I see all of them are absolute niche an none of them got the
>> same attractivity and general public attention as the original Openmoko got
>> back in 2007. Well, it is like sending people to the moon for the second
>> time. Nice, still challenging technology. But no breakthrough any more. No
>> revolutionary approach. Smaller media coverage.
> 
> Linux on a phone isn't an interesting topic in itself any more, and even the
> phones where the software is open have practical limitations on what you can
> run. The idea of a phone where you can "hack" on the OS isn't as appealing
> as one where you can write your own apps, especially when most of the effort
> on the OS is directed towards a narrow stack of software.
> 
> Maybe those involved with OpenMoko could say something about the excitement
> around the original phone. Were people excited about the OS, or were they
> simply excited about the idea of a phone where you could run your own
> software?

My main excitement was about having a real Computer with a real OS (i.e. some
UNIX flavour and not some crippled wannabe) in your pocket.

So the Sharp Zaurus series made me very excited for such a pocket computer.
It was portable, had keyboard and display and Linux. And some connectivity 
through
a WLAN PCMCIA card.

After some years as data rates of mobile networks became higher it was a more
or less obvoius step to integrate phone and wireless internet into such a 
device.

Better screens made removing the keyboard an option. And voila: the smartphone
with some UNIX inside was about to be born. Helping this idea to get attraction 
was
one of the factors to become one of the first (non-core-team) supporters of the
OpenMoko idea (AFAIR the Neo1973 was announced 6 weeks before the iPhone 1).

BR,
NIkolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [OHSW.org] [Tinkerphones-Stammtisch] Happy New Year - and a better new year

[H. Nikolaus Schaller]

Hi Josua,
nice to hear from you!

Well, it really became quiet on all relevant mailing lists [1]. It looks as if 
there is no critical mass any more
for topics that had been interesting in the past 15 years. I.e. OpenMoko, 
QtMoko, GTA04 etc. or people
have moved to different media. Well, 15 years is a long time and people usually 
have changed priorities in
their live during such a time frame.

And there are similar projects like we had done back then with newer means. 
E.g. Libre, PinePhone, ShiftPhone etc.
They have set up their own community tools.

But as far as I see all of them are absolute niche an none of them got the same 
attractivity and general public
attention as the original Openmoko got back in 2007. Well, it is like sending 
people to the moon for the second
time. Nice, still challenging technology. But no breakthrough any more. No 
revolutionary approach. Smaller
media coverage.

So I have added some more mailing lists (even if this is some duplication) and 
let't see who else answers
on which list and expresses interest.

[1]: https://lists.goldelico.com

> Am 01.09.2022 um 08:18 schrieb Josua Mayer :
> 
> \o/ Good day to you all!
> 
> Am 22.11.2021 um 21:10 schrieb H. Nikolaus Schaller:
>> What we did have was a video conference in May this year with ca. 9 
>> participants.
>> There was a wish to have another meeting after the holiday season but nobody 
>> did organise something.
> 
> Hi Nikolaus!
> Yes indeed. I was busy with personal challenges back then, and was content 
> with the break ...
> Now however I would be interested to organise another of those meetings if 
> there is any interest!
> 
>> Interestingly it was on a different list: 
>> https://lists.goldelico.com/pipermail/open-hard-software-event/2021-May/thread.html
>> 
>> So it appears as if we have two lists for more or less the same purpose...
> 
> It seems we may want to advertise on more lists, or treat them as one?
> Not sure how others feel about it, but I imagine with the general lack of 
> chatter it might be okay.
> 
> Any suggestions where to start a new thread for planning?
> I do admit to having lost overview of the lists ...
> 
> e.g. ohsw list + tinkerphones community + gta04-owners
> 
> br
> Josua
> 

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Strategies for sustainable phones

[H. Nikolaus Schaller]

Hi Paul,
for e-paper displays Andreas has worked a lot on improving and trying to
upstream the epdc driver for i.MX6.

And we have Letux OS and kernels running on some Kobo / Tolino readers.

Yes, they are not at all power hungry... So they can potentially be used as
a basis for "dumb smartphones" :)

With that I mean reduced in some aspects (display colors, lack of high speed
video capabilities) but full power (e.g. memory capacity giving flexibility of
standard Linux) in others.

Technology is available (e.g. chips, pcb design, radio modules, displays, 
software).
Maybe also people wanting to pay for it as your crowd-funding examples seem
to demonstrate. What is lacking is some group willing to work on something.
And some leader wanting to make it a success.

BR,
Nikolaus

> Am 21.03.2022 um 17:36 schrieb Paul Boddie :
> 
> Hello,
> 
> Sorry to bring up an old thread, but I would probably only end up repeating 
> myself in a new thread, anyway! See here for the quoted message in the list 
> archive:
> 
> https://lists.goldelico.com/pipermail/community/2019-September/002046.html
> 
> On Monday, 23 September 2019 16:28:46 CET Paul Boddie wrote:
>> On Saturday 21. September 2019 15.48.50 H. Nikolaus Schaller wrote:
>>> 
>>> Yes, we thought about it - but where are the real users?
>>> 
>>> There is for example hyped LightPhone2 but I don't see that it is a useful
>>> device. Minimizing functions can also go too far.
>> 
>> The stupid Web site for the LightPhone needs all my computer's CPU and half
>> of its RAM. I guess nobody will be viewing it on a LightPhone2. But I guess
>> this illustrates my point about ever-expanding hardware requirements for
>> mundane things.
> 
> So, today I came across a new article about low-end phones that mentioned the 
> Light Phone:
> 
> "Not smart but clever? The return of 'dumbphones'"
> https://www.bbc.com/news/business-60763168
> 
> It focuses mostly on the quality of life aspects of rejecting smartphones and 
> their associated culture of distraction, which is something that even has its 
> own Wikipedia article:
> 
> https://en.wikipedia.org/wiki/Problematic_smartphone_use
> 
> Obviously, the Light Phone 2 chooses a fairly extreme approach, although not 
> nearly as extreme as its predecessor which had no screen at all. This was 
> considered earlier...
> 
>> As for that device itself, it takes the interesting but troublesome idea of
>> using e-ink or e-paper displays for something that people might expect to
>> support animated or rapidly updated content. Apart from the use-cases of
>> reading e-books or showing one's boarding pass barcode at the airport
>> security gates, people struggle to consider things that are compelling
>> enough for people to want one (other than the fashion aspect of having
>> something different).
> 
> Having seen e-readers used for interactive applications, I don't think that e-
> paper is a bad idea inherently (if you can avoid sensitive information being 
> persistently visible), and there are seven-colour screens broadly available 
> now, but user expectations need to be managed. It is interesting to read a 
> bit 
> more about the design considerations when they followed up the first 
> screenless model with the e-ink model:
> 
> https://medium.com/the-light-phone/why-a-screen-eca598f37159
> 
> Coincidentally, I was recently reviewing coverage of the Psion MC notebook 
> computer that was launched in 1989:
> 
> https://en.wikipedia.org/wiki/Psion_MC_series
> 
> That was an ambitious product which had a high-resolution monochrome LCD 
> screen without a backlight, a touchpad, and which used flash memory for 
> storage. Although it was never likely to appeal to laptop power users, 
> particularly as screen technology improved, it had a battery life of 60 hours 
> or more and was fondly remembered by journalists and writers (as were more 
> modest machines like Amstrad's NC series).
> 
> It seems like software availability is a perennial problem, though. The 
> strategy for Light Phone appears to involve developing specific applications:
> 
> https://support.thelightphone.com/hc/en-us/articles/360031128671-Tool-Availability-Status
> 
> Despite some focus on ethical issues, I find it interesting that the voice-to-
> text feature uses some cloud service (with assurances made about privacy 
> concerns) and that a possible ride-sharing application might partner with 
> Lyft 
> or Uber. I wonder how many users of this device don't just get their 
> smartphone out for much of their needs.
> 
> Being based on Android, users could obviously obtain a much broader range of 

Re: [Tinkerphones] Looking for a hardware engineer...

[H. Nikolaus Schaller]

Hi,


> Am 15.02.2022 um 23:03 schrieb Bill Woodcock :
> 
> …with experience bringing something phone-scale or smaller through 
> production, for an open hardware project.
> 
> If anyone’s interested, let me know.  It’s a noncommercial project, we don’t 
> have a ton of money, but we’ll be doing a production run of ~50,000, so it 
> might be interesting for someone who wouldn’t otherwise get to work on a 
> project with a large unit count.
> 
> Get in touch if you’re interested and qualified, and I can talk details.

Well, 50k units is a lot which needs a mature production line flexible enough 
to produce one week of this and one week of that.

If you are interested, I could bring you in contact with the EMS (Electronics 
Manufacturing Service) that has produced half of the OpenPandora devices, 
started to build the GTA04A5 boards when we had to stop the project and is 
currently producing the Pyra handhelds (amongst many other projects). They are 
located in Germany.

One factor that is not clear to me is where the boards should be shipped to. 
Therefore the best would be if you can find an EMS near your main location. 
This has the benefit of short distance if something goes wrong and you can talk 
to them...

BR and good luck,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Article about Crowdfunding and Open Hardware

[H. Nikolaus Schaller]

> Am 30.01.2022 um 17:12 schrieb David Boddie :
> 
> I only recently read this article which seems to have flown under the radar
> when it was published:
> 
> https://www.linux-magazine.com/Issues/2020/231/Risky-Business
> 
> I was going to mention it in two of the places where the projects mentioned
> are discussed but it might have been interpreted as provocation. I hadn't
> heard of Keyboardio before, but my taste in keyboards isn't that expensive.
> 
> It's certainly a difficult discussion to have about transparency and
> openness, so I though that the analysis was interesting.

Indeed!

Just some thoughts while reading:

"dangers of crowdfunding and of backing unproven open hardware"

contains a contradiction in itself... How can something become proven without 
funding by someone taking the risk of failure? And, products are being polished 
by a process of discussing with real users. So it is a hen&egg problem to have 
proven hardware before starting crowdfunding. It would be VC funding plus 
normal sales.

"But what if Purism, or some other company in the same position, collapses 
financially and is unable to deliver on its promises, even with the best of 
intentions? "

Yes, I know. With the GTA04A5 the GTA04 project did collapse financially... 
When we were hit by unexpected production issues. Here, the best intentions and 
transparency did not help.

"Transparency is a mark of sincerity and helps backers to trust the 
crowdfunding project."

It does not only help backers but also the project originators to sleep well, 
even if the project failed.

BTW: I know some of the guys and most of the projects mentioned... Some even 
asked me to participate in running their project. On one hand I had plans for 
an OMAP5 based "GTA15" but it was too risky for me to run such again, 
especially in competition to the upcoming Librem5 and PinePhone. And I had 
different personal goals and limitations.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Dual personality systems (was Re: ZeroPhone site offline)

[H. Nikolaus Schaller]

> Am 10.01.2022 um 22:51 schrieb Paul Boddie :
> 
> On Monday, 10 January 2022 02:27:15 CET Jonas Smedegaard wrote:
>> Quoting Paul Boddie (2022-01-09 23:40:08)
>>> 
>>> The AR100 processor in the Allwinner SoCs appears to be used as a kind
>>> of microcontroller without memory management unit, at least from what
>>> I can understand from that wiki page, so running vanilla Linux would
>>> be out of the question. But there are other things it could presumably
>>> be asked to do.
>> 
>> It was my understanding that the AR100 was unusable for running Linux -
>> until I read that wiki page, which to me seems to explicitly mention
>> running linux on it - in the very section header, ever:
>>> Mainline Kernel Support
>> 
>> I am not knowledgeable in this low-level stuff though, so I take your
>> word for it.
> 
> I wouldn't know without really taking a look at it. However, it sounds like 
> the Linux support would be comparable to what has been done (or attempted) 
> with the Ingenic auxiliary cores (AUX and MCU),

I just want to add that the OMAP processors have similar facilities.
All of them have some sort of DSP and the OMAP5 comes with
"two Cortex-M4 processors for low-power offload and real-time control".

> meaning that the additional 
> core is supported by a Linux driver which allows code to be transferred to 
> the 
> core and then run. This is obviously different from actually running a kernel 
> on such a core: even the driver supporting the core is external to it, merely 
> offering the mechanism to control it.

AFAIR there were attempts (or success) to run uCLinux on the OMAP5
subcores. Since they lack MMU it is a little limited.

But do these nice things solve any real world problem?

If we can't get a nice and working and well accepted stack on the main
processor - how would a SoC specific subcore help? It adds fragmentation
is not available everywhere, difficult to debug etc.

BR,
Nikolaus


___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

> Am 06.01.2022 um 00:59 schrieb Paul Boddie :
> 
> On Monday, 3 January 2022 20:12:32 CET H. Nikolaus Schaller wrote:
>> 
>> It happened several times during development of the GTA04 that people
>> said: nice but look you can buy this or that. Instead of helping getting
>> GTA04 better and making it a success.
> 
> Maybe if the FSF encouraged investment in the hardware that 
> runs the Free Software, everyone else would be better off: hardware would get 
> designed and made, software developers would be involved in that process and 
> not have to reverse-engineer proprietary devices, and maybe those involved 
> would also get paid for their time.

It is a very good question what whould happen if s/Software/System/ would be 
applied...

Some examples:

Free System Foundation
Free System Foundation Europe
Free/Libre Open Source Systems
Free and Open Source Systems
Free and Open Source Systems Developers' European Meeting
etc.

BR,
Nikolaus
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

> Am 05.01.2022 um 16:46 schrieb Dr. Michael Lauer :
> 
> Hi Radek,
> 
>> If i was doing software for open phone i'd make basic monolithic telephony
>> 
>> app (calls, SMS) that works directly with the modem, with one HW hardcoded.
>> 
>> No plugins no frameworks just keep it simple.
> 
> This!
> 
> When I envisioned the system architecture of Openmoko, I tried to be a nice
> citizen with regards to existing components and versatility — otherwise I
> would not have started with DBus as the „collaboration API“ in the first 
> place.
> 
> While this was great for education and empowering people to write cool custom
> dialers and components in all kinds of languages, it severely increased the 
> complexity,
> latency, etc.
> 
> If I were to do this behemoth of a software stack like freesmartphone.org 
> again, it
> would look pretty similar to what you just said. A monolithic
> component that takes care about the „features“ of the phone – period. If at 
> all, with
> _very few_ – well defined – extension points for other software to „plug in“.

Well, CoreTelephony is such a monolithic component (wrapper)...

Note that it does not define how its internals are implemented.

It could run on a separate processor using some shared memory communication
or whatever is efficient. This allowed Apple have if from iOS 4 to iOS 15 and 
even
macOS 10.10 and later.

Sometimes I have the feeling that we are repeating the mistakes that Apple
didn't make right from the beginning 15 years ago :) Or in other words we are
not good enough in simply copying what is good.

Also note that some modem chips/modules would have a direct interface to
a microphone and a speaker. So everything would just be about controlling
the modem+audio subsystem. I.e. translating method calls to AT commands.

Indeed no reason for complexity.

> 
> In fact, now that I have a new programming language darling, I’d even love to
> do such a stack again from scratch…

Well my programming language darling is more than 35 years old and I did
already write a lot of such a stack from scratch:

https://git.goldelico.com/?p=mySTEP.git;a=tree;f=CoreTelephony

Unfortunately nobody did care about. Me as well :)

Maybe I should care more in the future since two big issues have been
solved:

a) mySTEP can now be compiled to run equally well on Debian Jessie up
to Buster (potentially beyond) and multiple SoC architectures
b) and a nasty memory management bug has been solved.

What I also should mention: it can (did) run on the LetuxOS version for
the PinePhone. But was not useable because there is no official modem
driver upstream and I wasn't able to integrate the downstream version.
So I simply could not turn the Modem on and check for AT commands.
 
> but time-wise/financially I can’t afford to do something
> like that any more :-(

The same for me :(

It was financially interesting when Openmoko started but nowadays
it has shrinked to an interesting hobby (eating too much time).

BR,
NIkolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

Hi all,

> Am 05.01.2022 um 01:28 schrieb Paul Boddie :
> 
> On Tuesday, 4 January 2022 19:30:38 CET H. Nikolaus Schaller wrote:
>>> Am 04.01.2022 um 18:34 schrieb Paul Boddie :
>>>> It’s extremely sad that after all these years with all our technological
>>>> advancements and choice of free software projects, getting the very
>>>> basic task – solid and reliable phone calls with tolerable
>>>> audio quality and battery life – right, still seems to be unachieved.
>>> 
>>> Yes, we're back to the featurephone here! Maybe it needs doing after all.
>> 
>> Well, not really.
>> 
>> Making good phone calls does not require to reduce a device to feature
>> phone level.
> 
> I wasn't being totally serious, but with regard to software, delivering a 
> robust featurephone experience would be a start, even if it is on something 
> which is capable of more.

back to the original question I looked around a little and it appears that
anyone could (have) plug(ed) togehter some "zerophone":

* RasPi Zero (W)
+ 4G/3G LTE HAT Modul für Raspberry Pi - e.g. 
https://www.rasppishop.de/4G-LTE-HAT
+ eInk display - e.g. 
https://www.rasppishop.de/27-Zoll-eInk-Display-fuer-Raspberry-Pi-GPIO

Well, what is missing is a 0-9#* keypad and buttons and a battery solution.

Another aspect is why I have written "(have) plug(ed)" - those components
are notavailable nowadays...

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

> Am 04.01.2022 um 18:34 schrieb Paul Boddie :
> 
>> It’s extremely sad that after all these years with all our technological
>> advancements and choice of free software projects, getting the very
>> basic task – solid and reliable phone calls with tolerable
>> audio quality and battery life – right, still seems to be unachieved.
> 
> Yes, we're back to the featurephone here! Maybe it needs doing after all.

Well, not really.

Making good phone calls does not require to reduce a device to feature
phone level.

QtMoko was a nice example. It did work really well on GTA04 incl. phone calls.
And Replicant 4.2. Both did have good audio quality and everything.

And the kernel was the best one we ever had: 3.7-neilplusplus.

It is still archived: https://projects.goldelico.com/p/gta04-kernel/
And the most feature complete kernel was 3.12 although not as good
as 3.7.

But it wasn't possible to merge all good aspects of those kernels into
a single one back then.

What also forced us to move to newer kernels was
a) upstreaming - they did no longer accept code developed for 3.7 or 3.12
and reworking patches to become upstream compatible takes more work
than initially developing them and testing that they do what is expected

b) GTA04A5 - had changed some hardware (WiFi and sensors) and that was
too difficult to add (backport) to these old kernels

Unfortunately there was also no breakthrough on reestablishing a working
build-setup for QtMoko. Several contributors worked hard on it
but we never reached a level productivity where it was just a git clone+make
or apt-get source + debuild for anyone who wanted to join efforts.

Basically the concapt was simple:
* untangle QtMoko into really separate debian packages
* add proper debian build scripts (instead of having a single big 2-days
  Makefile needing to set up a virtual machine)
* place sources and binaries on some server
* arrange that kernel and user-space are more in sync

But I also have good news. Just these days I finally fixed a deeply
buried memory leak in QuantumSTEP which made devices unuseable
because all applications were oom-killed after ca. 1 hour.

Since QuantumSTEP follows the ideas of separate debian packages
it is easy to work on this or that. E.g. make the phone dialer work
again (btw. internally it will be compatible to the CoreTelephony.framework
from Apple).

And, not to forget that Andreas has written Simple-gsm-gui which is
just a debian package waiting to be installed on all LetuxOS devices
(well, not all have modem or are supported by AT commands).

So in summary it does not need much to get phone calls working - if
we have hardware and a kernel that supports modem + audio. Independently
how many features (just address book or up to messengers, browser, navigation,
games etc. the remaining software has).

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

Hi Paul,

> Am 03.01.2022 um 18:43 schrieb Paul Boddie :
> 
> On Sunday, 2 January 2022 22:01:51 CET H. Nikolaus Schaller wrote:
>> 
>> you have probably pinpointed the most important aspect of all discussions.
>> 
>> We have no high-quality power management in any of the devices...
>> We spend (spent) a lot of time to make it work, get hardware out just
>> to get the same feedback as you have cited above.
>> 
>> We (as the OpenMoko and GTA04 community) have faced it. I think also
>> the Librem 5 has. And the Pinephone you have cited.
>> 
>> What should be different?
>> - well it needs a team dedicated at making hardware reliable and improve
>>  power efficiency
>> - this needs a lot of insights into hardware and good doscumentation
>> - and - maybe - a stable basis to work on
>> - there should also not be fragmentation between several groups
>>  having multiple desktops to choose from is good, but having multiple
>>  power managements?
> 
> To what extent do you think Linux itself is part of the problem here? We both 
> know that it can be frustrating to adapt Linux to the realities of various 
> devices, and then there is the matter of getting modifications adopted in the 
> mainline. None of this is a particularly efficient process, and so doing 
> things "the right way" doesn't really fit in with getting a product to work 
> well, unless you have lots of resources, of course.
> 
> It seems to me that, as you say, you need people with experience who have 
> access to decent documentation, working at the lowest level of the software 
> stack, making sure that the hardware is functioning properly. All of that is 
> hard enough without a bunch of other people telling you that they just 
> decided 
> to rework the APIs and that you have to change your code to follow suit, or 
> without weird regressions or deprecations that have been introduced elsewhere.
> 
> I've presumably mentioned the use of L4Re to test the Letux 400 and other 
> MIPS-based hardware on this list. One significant reason for doing so is to 
> just eliminate all the noise from "Linux" when familiarising myself with the 
> hardware and exploring how it works. And once one does that, one wonders why 
> there can't just be a layer dealing with the hardware in a proper component-
> based architecture with things like documented interfaces and all the things 
> that people have learned from object-oriented programming over the last few 
> decades.

That is a very good question. On one hand Linux makes it possible to get
90% of things where there are no resources to get them coded, debugged,
security checked, stabilized etc. For example the whole networking stack.
Or MMC/SDIO. Or CPU startup and so on. And keep it in sync with user-space
distributions.

It would be impossible to start a new kernel project without being even slower
than with Linux. If I look at the deltas LetuxOS has not upstreamed it is less
than 0,5% of the total Linux code which we have touched at all.

L4Re is a nice project - but if it does not support all sorts of peripherals
and user-spaces and that for a multitude of hardware components it may
need more work to get a high quality system out of it which users would like
to see.

But there would be a different strategy which I have rejected for more than 10
years: just pick a Linux kernel, stick with it and just fix things. And accept
that it is ageing and becoming incompatible. I have rejected this because
if the kernel becomes really too old it takes months or years to pick another
kernel and get it to the same level because forward-porting private changes
is usually not easy.

Maybe the Linux community has recognised that as well and there are LTS
kernels. I just learned that v4.4 is even a Super-LTS i.e. will be there for
more than 10 years.

And, interesting fixes are backported. If possible even to 4.4. So that it
receives security fixes etc.

But if we would invest a lot of work on e.g. better power management for
a device. Would you work on 4.4. or linux-rc with this general process
in mind?

So I always come back to better work on linux-rc to fix and improve things,
and backport (which is usually easier than forward-porting). Although I then
have to fight against maintainers and internal API changes. But Ican also get
support. It happened several times that I just had to ask on the mailing
lists and in a half day there was a patch with a fix that I just had to test.

> 
>> This raises an interesting question: can a loosely organised open source
>> community ever fulfill these user's expectaions? Or does it need a
>> commercial effort following a plan, an agenda, doing scrum etc. having
>> enough resources and not waiting for volunteers? This does not ex

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

> Am 02.01.2022 um 21:33 schrieb Paul Boddie :
> 
> On Wednesday, 29 December 2021 10:15:45 CET H. Nikolaus Schaller wrote:
>> 
>> Next question: are there enough interested developers for writing free
>> software?
>> 
>> And one more thing to consider is the power demand of a non-phone-processor.
>> Especially the ∏02 needs much more energy or must be heavily underclocked
>> (if that is possible at all).
>> 
>> Even the N900 upstream kernel is wrestling with power management of the
>> good old omap3.
>> 
>> The key feature of a featurephone over a smartphone is that it can
>> run 100 hours or more in standby but wake up immediately. And all that
>> coming in a small and lightweight case with big buttons and display.
>> 
>> This combination of requirements is very difficult to achieve with
>> off-the-shelf components.
> 
> Sorry to rewind back to this, but reading a selection of comments about the 
> PinePhone is certainly enlightening in this context:
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/
> 
> It seems to me that some of the issues that are mentioned above, plus various 
> issues previously mentioned about the Openmoko devices, still seem to be 
> present even in today's initiatives. For example:
> 
> "Got one because my husband is very into Linux and wanted to see if it could 
> replace my 6 year old Samsung but I can kind of live with the slowness but 
> the 
> battery level is so unreliable and drains quickly."
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5434
> 
> "I was using the pinephone as a daily driver, and was even using XFCE/PMOS as 
> my os for a while. Then went to Manjaro and just recently (4 days ago) bought 
> a new Android (Motorola G Power 2021) specifically because of the battery 
> life."
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5445
> 
> "I’ve used my PPs in convergence format with a cooling fan to dissipate the 
> heat when a monitor is connected. I’m hoping the Pro as promised will be 
> safer 
> to use."
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5474
> 
> "If the battery life would improve I’d love to use it as a daily driver but I 
> just don’t see me getting a 12 hour day with it off charger. Plus last time I 
> popped a sim in it(admittedly awhile back now) it didn’t handle receiving 
> calls when screen was off very well."
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5476
> 
> "The biggest blocker to actually using the Pinephone for me has been buggy 
> hardware and incomplete drivers (or drivers that must work around buggy 
> hardware). Particularly the USB-C support for video-out and power 
> negotiation. 
> If USB-C, sound, display, wifi, & bluetooth were all hardware with reliable, 
> upstream kernel support then the Pinephone would be immediately usable for me 
> for many daily tasks and a fun playground to experiment with. Unfortunately 
> both Pinephone models that I’ve purchased have hardware issues and have been 
> largely shelved — they don’t work as a phone (which is expected) nor do they 
> work as a tiny Linux computer (which is not expected and disappointing)."
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5479
> 
> "Even though I was able to get my Pine Phone Community Edition up and 
> running, 
> I abandoned any notion of using it regularly due to reports from callers who 
> reported hearing very distorted and poor sound when I used this device. It 
> seems that problem is because the mic and speaker are located too close to 
> each other."
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5484
> 
> "Main issues are critical low battery life (I think it is bug in SW, since it 
> stayed longer before), not receiving non-GSM notifications when the phone is 
> in sleep mode (like jabber, whatsapp etc – because the wifi is disconnected) 
> and also the GSM SW support is not perfect – sometimes I miss a call or sms."
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5513
> 
> "microphone not working on receiving calls, too slow, I cannot pick up the 
> call in time in time"
> 
> https://www.pine64.org/2021/12/29/pinephone-community-poll/#comment-5519
> 
> "The Pine64 developers and the community need to put more focus onto making 
> the PinePhone perform the most basic of mobile phone tasks, Like making and 
> receiving phone calls, using headphone earpieces, receiving and sending SMS, 
> phonebook. The basic essential 

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

A happy new year to everybody!

Hi Paul,
as usually a very insightful contribution and well written so that it is 
difficult
to add something...

> Am 30.12.2021 um 18:32 schrieb Paul Boddie :
> 
> On Wednesday, 29 December 2021 10:15:45 CET H. Nikolaus Schaller wrote:
>>> Am 28.12.2021 um 20:40 schrieb Martin :
>>> 
>>> On 2021-12-28 19:35, Dr. Michael Lauer wrote:
>>>> That’s a pity. In particular with the recent Pi Zero 2 design that
>>>> could’ve been a pretty sweet alternative feature phone.
>>> 
>>> My main problem with the ZP was the extremely small display.
>>> I'm just too old to be able to read it without magnifying glass.
>>> Apart from that it was a very cool phone!
>> 
>> Indeed, it was a nice and good idea for its time.
> 
> I must admit that I was worried about the choice of Raspberry Pi hardware, 
> given the proliferation of different models with different characteristics 
> (as 
> you discovered a while ago, Nikolaus), meaning that extra caution is required 
> even when basing a design on a particular device. And I am also not enamoured 
> by the way the Raspberry Pi initiative operates.
> 
> But I think it was a nice idea to take something that already existed and to 
> adapt it in this way. A long time ago, the Gumstix products were used as the 
> basis for a phone-like project in a similar way:
> 
> https://web.archive.org/web/20100127031815/http://www.gizmoforyou.net/site/
> shop/flow-g1-5.html
> 
> Obviously, there are still going to be challenges with the physical design of 
> a device, whether it can be used and accepted, but my impression was that the 
> ZeroPhone was the first step along a particular path, so it is unfortunate 
> that perhaps that path is no longer navigable. I hope that Arsenijs is still 
> in a position to pursue such things or is at least finding something else 
> that 
> is rewarding to pursue.

There are other "Capes" or "Hats" or how they are called adding WWAN modules
or displays. So basically it should be possible to just plug something similar
together from the RasPi ecosystem.

> 
>> But to be curious: what would you do with a feature phone nowadays?
>> If there is a browser it is crap. Games? Banking? Navigation? Messenger?
>> My mother-in-law has one, just in case she must do a phone call.
>> There is one more: receiving SMS for banking or 2-factor authentication.
> 
> I think society has to reconsider how technology should be used to get things 
> done. One interesting example is this:
> 
> http://www.tbray.org/ongoing/When/202x/2021/12/27/Small-Utopia
> 
> There is a kind of consumerist mentality which starts out with people buying 
> new and shiny things, and then the mechanisms of society require everyone to 
> buy those gadgets. And instead of making the technology fit the processes, it 
> is the other way round.

Indeed. There are more and more blinkenlights everywhere and artificial
intelligence e.g. in my car or smartphone making me aware of things I don't
want to know and making it difficult to create a mental model of the connection
between something I want and how to tell it the machine. So these technologies
have a tendency to make me not the owner of the machine...

> 
> Hence the remarks in that article about a convenient user experience that 
> lacks a lot of the traits of the modern technological experience, these 
> traits 
> mostly amounting to frivolous visual "design" and the tendency to want to 
> monetise everything through surveillance. Although Web technologies have 
> given 
> people flexibility, the last two or so decades have seen the indulgence of 
> wasteful and even harmful practices in delivering technological solutions.
> 
> That this is typically excused by references to technological progress just 
> shows how little things have changed since everyone accused Microsoft and 
> Intel of conspiring to make everyone upgrade their computer every couple of 
> years. Sadly, this means that unless we recognise the fundamental social 
> dynamics of this phenomenon and encourage sustainable and considerate use of 
> technology, we will continue to see the latest smartphone being mandated for 
> a 
> lot of people's participation in matters of commerce, governance and even 
> access to education and healthcare.
> 
>> Next question: are there enough interested developers for writing free
>> software?
> 
> This is where the Free Software Foundation and others simply fail to deliver. 
> We've mentioned the "Ethical Tech Giving Guide" before:
> 
> https://www.fsf.org/givingguide/v12/
> 
> Where are we now with that? The recommendations are to find s

Re: [Tinkerphones] ZeroPhone site offline

[H. Nikolaus Schaller]

> Am 28.12.2021 um 20:40 schrieb Martin :
> 
> On 2021-12-28 19:35, Dr. Michael Lauer wrote:
>> That’s a pity. In particular with the recent Pi Zero 2 design that could’ve
>> been a pretty sweet alternative feature phone.
> 
> My main problem with the ZP was the extremely small display.
> I'm just too old to be able to read it without magnifying glass.
> Apart from that it was a very cool phone!

Indeed, it was a nice and good idea for its time.

But to be curious: what would you do with a feature phone nowadays?
If there is a browser it is crap. Games? Banking? Navigation? Messenger?
My mother-in-law has one, just in case she must do a phone call.
There is one more: receiving SMS for banking or 2-factor authentication.

Next question: are there enough interested developers for writing free software?

And one more thing to consider is the power demand of a non-phone-processor.
Especially the ∏02 needs much more energy or must be heavily underclocked
(if that is possible at all).

Even the N900 upstream kernel is wrestling with power management of the
good old omap3.

The key feature of a featurephone over a smartphone is that it can
run 100 hours or more in standby but wake up immediately. And all that
coming in a small and lightweight case with big buttons and display.

This combination of requirements is very difficult to achieve with
off-the-shelf components.

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] No video on Pandora after letux kernel boot

[H. Nikolaus Schaller]

> Am 02.12.2021 um 19:23 schrieb H. Nikolaus Schaller :
> 
> Hi Grond,
> 
>> Am 01.12.2021 um 05:23 schrieb Grond :
>> 
>> On Thu, Nov 25, 2021 at 10:05:17AM +0100, H. Nikolaus Schaller wrote:
>>> Hi Grond,
>>> 
>>> 
>>>> Am 25.11.2021 um 01:16 schrieb Grond :
>> [snip]
>>>> 
>>>> Hmm. That's odd. I was able to get kernels to boot (both the ones that
>>>> came from the makesd script and my own custom-built ones), but the only
>>>> way I was able to tell that anything was running was the heartbeat LED
>>>> flashing. The LCD screen was never initialized.
>>> 
>>> Some ideas:
>>> - use letux_defconfig (omap2plus_defconfig is incomplete)
>>> - kernel may not find the modules in /lib/modules
>> 
>> I did use letux_defconfig. The issue seems to have been the pvrsrvkm
>> module.
> 
> Yes.
> 
>> 
>>> 
>>>> I've ordered a Pandora
>>>> serial adapter to try and debug the problem, but in the meantime, what
>>>> kernel did you get to boot? I built and tried letux-5.4.160
>>>> (7c7255c3463641b8f699472f9114b0435dbfe707) and whichever 5.4.160 kernel
>>>> is currently installed via makesd (probably the same git revision).
>>> 
>>> I just did build 5.4.161 (13796081373dda954bb3bb59403fc70708cbbcff).
>>> 
>>> It gets stuck for ca. 20 seconds and later reports a NULL pointer issue in
>>> the pvrsrvkm. But after a minute I get a display.
>> 
>> I also ran into a null-pointer deference issue in pvrsrvkm. However, in
>> my case it was causing the LCD not to get used (because when I
>> blacklisted pvrsrvkm, the LCD came up exactly as expected). It's also
>> worth mentioning that the LCD was actually getting initialized, however
>> the pvrsrvkm issue was somehow keeping the kernel from running a console
>> on the framebuffer (the key error message was
>> "detected unhandled fb_set_par error").
> 
> Ah, I think it is only if we compile the pvrsrvkm 1.17. It is configured by 
> default
> for all ARM versions. Maybe the omap3530 version is broken while omap4 and
> omap5 works better.

Please try to change defconfig to 1.14.366696

> 
>> 
>>> 
>>> Maybe you can try 5.15.y? There, the pvrsrvkm issue is solved.
>> 
>> This also worked quite well. Though the fact that kernels can only be
>> booted with DTBs from their own build is definitely a trap for the
>> unwary :)
> 
> Well, there is a rule that DTBs should never be changed since they
> describe hardware... And hardware is always the same.
> 
> But in practise there are differences in how the description looks like
> or drivers may fix bugs by adding and handling new properties. So
> an old DTB doesn't fix it...
> 
>> 
>>> 
>>> But there is a known bug with the bandgap sensor inside the omap3530 (600 
>>> MHz).
>>> And something about an I2C bus timeout which hasn't been seen on dm3730 (1 
>>> GHz)
>>> based devices. 
>>> 
>> 
>> Is there any more detail on these issues anywhere?
> 
> Basically I see after a while:
> 
> ti-soc-thermal 48002524.bandgap: eocz timed out waiting high
> 
> and / or (not directly related)
> 
> [ 2061.283721] omap_i2c 4806.i2c: timeout waiting on XUDF bit
> 
> The first one may be a Silicon bug - at least what the OMAP maintainer
> thought. He recommended to turn it off. On the other hand I know
> that it did work quite well in kernels at least before 4.0.
> 
> The second one comes from i2c3 where the bq27500 fuel gauge and the nubs
> are connected to. In fact for me the nubs stop working as soon as this
> message appears.
> 
> It may be either a protocol or a speed error. Or something in the drivers
> of these chips which make them block the bus. Or even a power management
> issue in the bandgap and i2c controllers on the omap3530 SoC.
> 
> In both cases I have planned (but not found time) to experiment with
> different older kernels to find out in which kernel release it appeared
> first. Then we may have to git bisect to understand. This is quite 
> time-consuming...
> 
> BR,
> Nikolaus
> 
> ___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] No video on Pandora after letux kernel boot

[H. Nikolaus Schaller]

Hi Grond,

> Am 01.12.2021 um 05:23 schrieb Grond :
> 
> On Thu, Nov 25, 2021 at 10:05:17AM +0100, H. Nikolaus Schaller wrote:
>> Hi Grond,
>> 
>> 
>>> Am 25.11.2021 um 01:16 schrieb Grond :
> [snip]
>>> 
>>> Hmm. That's odd. I was able to get kernels to boot (both the ones that
>>> came from the makesd script and my own custom-built ones), but the only
>>> way I was able to tell that anything was running was the heartbeat LED
>>> flashing. The LCD screen was never initialized.
>> 
>> Some ideas:
>> - use letux_defconfig (omap2plus_defconfig is incomplete)
>> - kernel may not find the modules in /lib/modules
> 
> I did use letux_defconfig. The issue seems to have been the pvrsrvkm
> module.

Yes.

> 
>> 
>>> I've ordered a Pandora
>>> serial adapter to try and debug the problem, but in the meantime, what
>>> kernel did you get to boot? I built and tried letux-5.4.160
>>> (7c7255c3463641b8f699472f9114b0435dbfe707) and whichever 5.4.160 kernel
>>> is currently installed via makesd (probably the same git revision).
>> 
>> I just did build 5.4.161 (13796081373dda954bb3bb59403fc70708cbbcff).
>> 
>> It gets stuck for ca. 20 seconds and later reports a NULL pointer issue in
>> the pvrsrvkm. But after a minute I get a display.
> 
> I also ran into a null-pointer deference issue in pvrsrvkm. However, in
> my case it was causing the LCD not to get used (because when I
> blacklisted pvrsrvkm, the LCD came up exactly as expected). It's also
> worth mentioning that the LCD was actually getting initialized, however
> the pvrsrvkm issue was somehow keeping the kernel from running a console
> on the framebuffer (the key error message was
> "detected unhandled fb_set_par error").

Ah, I think it is only if we compile the pvrsrvkm 1.17. It is configured by 
default
for all ARM versions. Maybe the omap3530 version is broken while omap4 and
omap5 works better.

> 
>> 
>> Maybe you can try 5.15.y? There, the pvrsrvkm issue is solved.
> 
> This also worked quite well. Though the fact that kernels can only be
> booted with DTBs from their own build is definitely a trap for the
> unwary :)

Well, there is a rule that DTBs should never be changed since they
describe hardware... And hardware is always the same.

But in practise there are differences in how the description looks like
or drivers may fix bugs by adding and handling new properties. So
an old DTB doesn't fix it...

> 
>> 
>> But there is a known bug with the bandgap sensor inside the omap3530 (600 
>> MHz).
>> And something about an I2C bus timeout which hasn't been seen on dm3730 (1 
>> GHz)
>> based devices. 
>> 
> 
> Is there any more detail on these issues anywhere?

Basically I see after a while:

ti-soc-thermal 48002524.bandgap: eocz timed out waiting high

and / or (not directly related)

[ 2061.283721] omap_i2c 4806.i2c: timeout waiting on XUDF bit

The first one may be a Silicon bug - at least what the OMAP maintainer
thought. He recommended to turn it off. On the other hand I know
that it did work quite well in kernels at least before 4.0.

The second one comes from i2c3 where the bq27500 fuel gauge and the nubs
are connected to. In fact for me the nubs stop working as soon as this
message appears.

It may be either a protocol or a speed error. Or something in the drivers
of these chips which make them block the bus. Or even a power management
issue in the bandgap and i2c controllers on the omap3530 SoC.

In both cases I have planned (but not found time) to experiment with
different older kernels to find out in which kernel release it appeared
first. Then we may have to git bisect to understand. This is quite 
time-consuming...

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] No video on Pandora after letux kernel boot

[H. Nikolaus Schaller]

Hi Grond,


> Am 25.11.2021 um 01:16 schrieb Grond :
> 
> On Sat, Nov 20, 2021 at 10:48:41AM +0100, H. Nikolaus Schaller wrote:
>> Hi Grond,
>> 
>>> Am 19.11.2021 um 23:36 schrieb Grond :
>>> 
>>> 
>>> Hi.
>>> 
>>> Having recently encountered a slew of software incompatibility issues on
>>> my Pandora related to it's ancient (3.2) kernel, I thought I give the
>>> letux kernel a try as I'd heard it could at least boot on the Pandora.
>> 
>> Yes, just tested yesterday...
>> But with some Letux OS Debian.
>> 
>> What I do not know if it boots well with the original OS.
>> 
> 
> Hmm. That's odd. I was able to get kernels to boot (both the ones that
> came from the makesd script and my own custom-built ones), but the only
> way I was able to tell that anything was running was the heartbeat LED
> flashing. The LCD screen was never initialized.

Some ideas:
- use letux_defconfig (omap2plus_defconfig is incomplete)
- kernel may not find the modules in /lib/modules

> I've ordered a Pandora
> serial adapter to try and debug the problem, but in the meantime, what
> kernel did you get to boot? I built and tried letux-5.4.160
> (7c7255c3463641b8f699472f9114b0435dbfe707) and whichever 5.4.160 kernel
> is currently installed via makesd (probably the same git revision).

I just did build 5.4.161 (13796081373dda954bb3bb59403fc70708cbbcff).

It gets stuck for ca. 20 seconds and later reports a NULL pointer issue in
the pvrsrvkm. But after a minute I get a display.

Maybe you can try 5.15.y? There, the pvrsrvkm issue is solved.

But there is a known bug with the bandgap sensor inside the omap3530 (600 MHz).
And something about an I2C bus timeout which hasn't been seen on dm3730 (1 GHz)
based devices. 

> 
>>> 
>>> Unfortunately, it seems that there is something wrong with the git
>>> server HTTP(S) server instance running on git.goldelico.com. I've tried
>>> both cloning the repo from the URL given on the project page
>>> (https://git.goldelico.com/letux-kernel.git) and adding it as a remote
>>> to my existing kernel source trees. In both cases it gets stuck with the
>>> message "Fetching objects: 2" printed to the terminal, and never
>>> completes, even after an hour or two (though it does continue to consume
>>> bandwidth the whole time).
>> 
>>> 
>>> I have managed to download the letux kernel source from both the github
>>> mirror and over git protocol via git://git.goldelico.com/gta04-kernel.git
>>> without issues (although I have also encountered similar problems with
>>> downloading from the later source in the past). But I thought I'd send a
>>> problem report to this mailing list, as I suspect that the maintainer(s)
>>> of git.goldelico.com are subscribed and might not have encountered this
>>> issue before.
>> 
>> Well, this is more or less expected. The git repo has grown to almost 3GB
>> and the server has a 10 MBit/s connection - and serves other things as well.
>> 
>> So it takes at least 40 minutes to fetch all the raw files through http
>> before git starts to do something. An upgrade to 40 MBit/s is planned to
>> come soon.

The upgrade happened on this monday so speed should be higher now.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Problems with git.goldelico.com?

[H. Nikolaus Schaller]

Hi Grond,

> Am 19.11.2021 um 23:36 schrieb Grond :
> 
> 
> Hi.
> 
> Having recently encountered a slew of software incompatibility issues on
> my Pandora related to it's ancient (3.2) kernel, I thought I give the
> letux kernel a try as I'd heard it could at least boot on the Pandora.

Yes, just tested yesterday...
But with some Letux OS Debian.

What I do not know if it boots well with the original OS.

> 
> Unfortunately, it seems that there is something wrong with the git
> server HTTP(S) server instance running on git.goldelico.com. I've tried
> both cloning the repo from the URL given on the project page
> (https://git.goldelico.com/letux-kernel.git) and adding it as a remote
> to my existing kernel source trees. In both cases it gets stuck with the
> message "Fetching objects: 2" printed to the terminal, and never
> completes, even after an hour or two (though it does continue to consume
> bandwidth the whole time).

> 
> I have managed to download the letux kernel source from both the github
> mirror and over git protocol via git://git.goldelico.com/gta04-kernel.git
> without issues (although I have also encountered similar problems with
> downloading from the later source in the past). But I thought I'd send a
> problem report to this mailing list, as I suspect that the maintainer(s)
> of git.goldelico.com are subscribed and might not have encountered this
> issue before.

Well, this is more or less expected. The git repo has grown to almost 3GB
and the server has a 10 MBit/s connection - and serves other things as well.

So it takes at least 40 minutes to fetch all the raw files through http
before git starts to do something. An upgrade to 40 MBit/s is planned to
come soon.

I do not know the details but the git protocol seems to be more clever in
knowing what to transfer first but is less robust for network interruptions.

This is why we mirror to github. This allows our server to just upload
the changes.

Anyways thank you very much for your report (since we do not regularily
look on the whole setup as a user does).

> 
> On a happier note, I look forward to trying out the letux kernel on my
> Pandora. If there are any tests/investigations that I can perform,

Yes, everything :) Most things are working except sound. There is no
proper driver setup.

WLAN just got a modification so that it will continue to work with future
kernels where the SDIO driver will be replaced.

> please let me know. If I make progress in getting new functionality
> running, I will make sure to send a patch this way.

That would be great! If you have contributions, then please also subscribe
and send to https://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

> 
> Thanks to all for putting in the effort to keep old devices like mine
> running,

it is a lot of fun and pleasure to do so.

BR,
Nikolaus
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] LetuxOS: new updates

[H. Nikolaus Schaller]

Hi all,
it is quite a while that there was an update what is going on.
So a lot of topics have been collected.

a) new Kernels letux-5.15-rc4!

Kernel development has progressed and we now have
letux-5.15-rc4. It is running quite stable now.

b) PVR SGX DDK 1.14 is working again!

There was an incompatibility introduced from upstream
that did break the DDK 1.14 somewhere between letux-5.6
and letux-5.10.

It has been possible to track and fix it as coming from
an untested and forgotten wrong compile fix in letux-5.8-rc1:

https://git.goldelico.com/?p=letux-kernel.git;a=commit;h=617b1dbbf2675c7108b47004d5971324cb1d9d5a

Now, the DDK 1.14 works again on omap3, 4 and 5.

DDK 1.17 unfortunately can't be tested because the
user-space binaries have dependencies that are
laying somewhere between Debian Buster and Bullseye.
I.e. Buster is too old and Bullseye too new.
To make it work again on Bullseye it would be required
to backport some package (I do not remember which
one but it can be researched).

PVR SGX on jz4780 is still a construction site since
we have no matching user-space code. Some idea very
long ago was to use qemu-arm on the mips machine to
run the arm-user-space. At least for testing if the
firmware can be loaded.

c) LetuxOS has got support for Raspi Zero and Zero W!

Thanks to Andreas Kemnade and David Boddie for support
(they gave the important hint that RasPi Zero uses an ARMv6
while all other devices have an ARMv7) it is now possible
to create an µSD that boots on the RasPi Zero or Zero W
with Debian Stretch (armel! only armel!).

The same µSD also works on RasPi 3B+ but there we can use
armhf.

How to install (for example):

makesd -vr stretch -vk latest raspi0 -r minimal

If you like you can enable boot logs by two sed commands
(also work on other RasPi):

sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" /media/letux/boot/bootcode.bin
sed -i -e 's/quiet/ignore_loglevel/' /media/letux/boot/cmdline.txt 

Note that the Resulting system is pretty slow if you ever
had a comparison to some Cortex A15 (Pyra) or Quad Core
(RasPi 3B+).

But still it is useable but of course not inteded for
High Performance Computing.

The reason for the low speed is that it is a low clock
frequency single core processor limited by memory bandwidth.

By the way, Bluetooth also works. Just

apt get install letux-firmware-brcm80211

WLAN ist also configured but wlan-scan does not report anything :(

To access the device, either use the FTDI console header
or some RNDIS/Ethernet gadget (root@192.168.0.202) on the
OTG USB port, exactly like for GTA04 or other LetuxOS devices.

And finally, even HDMI works.

Really interesting for an 5-10$ controller board.

One final note about other RasPi models. It is untested but
the raspi0 setup should also work on Raspi 1, 2 and 3.
Preferred for all Raspi 3 is to use makesd raspi3b+

RasPi 4 is not supported since it needs a different kernel.

d) Some older kernel builds are partially broken!

There was an issue in the build scripts so that the module.tgz
was overwritten by the version for Replicant. So beware if
you install some kernel binary from the downloads server between
ca. June and end of August.

All current builds have been checked and fixed.

e) Kobolino EPD driver!

Thanks to Andreas Kemnade (again!), we have a new
EPD driver that works really well - except two issues:
* screen is rotated by 90 degrees
* it must be compiled by CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
  or there are redrawing glitches

This has to be studied further

f) CI20 (jz4780) gets HDMI support!

The driver is in the upstreaming process and reviewers had
interesting questions. These allowed to simplify the code
and even improve monitor support (I had two that were a quite
flaky but now it seems to work fine).

So it will need one or two more review rounds and then
hopefully it will be accepted by upstream maintainers.

g) Debian rootfs server tree reorganized!

The debian rootfs server got/will get a new structure
by adding a hierarchy level based on the year:

https://download.goldelico.com/letux-debian-rootfs/?C=M;O=D

Currently, there is just 2021 but the plan is to manually
(or automatically) sort the older revisions into new subdirectories.

There will be (symbolic) links with "speaking" names, like

stretch-armel-lxde.tbz

which means a Debian stretch rootfs for armel architecture
and preconfigured to include lxde.

There is also the "lastest" release which is currently
Bullseye.

This is done to simplify control of makesd to install
what you want to have... makesd got new options:

makesd -A mipsel -vr buster debian -r minimal

translates into "buster-mipsel-minimal.tbz"

Also note that bootloader and kernel and rootfs have
separate "version" options, i.e. -vb, -vk and -vr
so that you can for example take a mature and robust stable
bootloader with the latest kernel and a specific debian
release.

Please note that I have tried to debootstrap Debian Bookworm
and

Re: [Tinkerphones] LetuxOS for Rasi-Zero-W?

[H. Nikolaus Schaller]

> Am 09.09.2021 um 16:01 schrieb David Boddie :
> 
> On Thursday, 9 September 2021 14:18:50 CEST H. Nikolaus Schaller wrote:
> 
>> But in the meantime I got another hint: maybe the same reason why the SD
>> size limits exist.
>> 
>> Pi 0, 1, 2 use an ARMv6 while the others (except Pi 4) use ARMv7.
> 
> I assumed you already knew about that. :-)

Well, I knew but wasn't aware... When I started the GTA04 project long long ago
(before RasPi 1 was even announced) with OMAP3 it was already ARMv7...
The GTA02 was likely ARMv6 but I never compiled anything for it.

> 
> I think 2 uses an ARMv7 core:
> 
> https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications

Ok, may be slightly different than my assumptions.

> 
>> This finally explained to me why there is kernel.img and kernel7.img...
>> It is not strictly necessary to have two kernel builds and it turned out
>> that changing the letux_defconfig from
>> 
>> # CONFIG_ARCH_MULTI_V6 is not set
>> CONFIG_ARCH_MULTI_V7=y
>> CONFIG_ARCH_MULTI_V6_V7=y
>> 
>> to
>> 
>> CONFIG_ARCH_MULTI_V6=y
>> CONFIG_ARCH_MULTI_V7=y
>> CONFIG_ARCH_MULTI_V6_V7=y
>> 
>> makes the kernel start on both :) Well, there are differences
>> (single core vs. quad core, different memory size etc.) but this
>> is taken care of by device tree and kernel.
>> 
>> But it fails running the Debian rootfs binaries (at least the
>> one I have tried so far). The same µSD plugged into the 3b+ boots
>> and runs fine.
>> 
>> So there must be something special in Raspbian or Debian for ARMv6.
> 
> My understanding was that Raspbian was initially a complete rebuild of Debian
> for ARMv6.
> 
> According to the Debian Wiki:
> 
>  "Raspberry Pi OS builds a single image for all of the Raspberry families,
>   so you will get an armhf 32-bit, hard floating-point system, but built for
>   the ARMv6 ISA (with VFP2), unlike Debian's ARMv7 ISA (with VFP3) port."
> 
> [https://wiki.debian.org/RaspberryPi]
> 
> So it's likely that stock Debian binaries won't run on a Pi Zero.

Ok, that would explain a lot...

I did check what debian-architectures reports on Raspbian and it was
indeed armhf.

Let's see what we can do with this for LetuxOS.

What I got from some experiments of Debian Stretch binaries on Raspbian
is SIGSEGV and not SIGILL.

Hm. Is there an ARMv7 emulator for ARMv6? Or a patch for missing
instructions? Or I just build and install armel rootfs packages for

https://download.goldelico.com/letux-debian-rootfs/?C=M;O=D

And makesd needs a simple flag to switch its macros for Raspi.
This will not optimally handle VFP of course, but should work
for standard stuff.

So with this a more general LetuxOS4Pi is close.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] LetuxOS for Rasi-Zero-W?

[H. Nikolaus Schaller]

Hi David,
thanks for responding!

> Am 09.09.2021 um 13:57 schrieb David Boddie :
> 
> On Mon, 30 Aug 2021 18:42:47 +0200, H. Nikolaus Schaller wrote:
>> Does anyone on this list have experience with
>> building and running mainline kernels for the
>> Raspi-Zero?
> 
> Not really. I only used the Raspbian distribution when running Linux.
> 
> Just looking at the rpi site, I found this note:
> 
>  "Because of a hardware limitation in the Raspberry Pi Zero, 1 and 2, the
>   boot partition on the SD card must be 256GB or less otherwise the device
>   will not boot up."
> 
> [https://www.raspberrypi.org/documentation/computers/getting-started.html#sd-cards]

Ok, interesting to know.

> I imagine that's not a problem for you, but I thought it might be worth
> mentioning.

Wll, LetuxOS uses two partitions. One for the boot system an the other for
rootfs. The boot partition created by makesd is usually 5% of the total µSD.
I.e. with a 32GB SD it is 1.6GB. Obviously this is far too much for the handful
of boot files, but also far below the limit.

Maybe I should add some option to makesd which can limit a partition size
to the smaller of the -s percentage and a given maximum.

> Have you tried booting on other models of the Pi, apart from the Zero-W and
> 3B+?

I do not have other variants to test with. If anyone has and wants to test,
please raise your hands and I can describe what to do. Generally it would
be a nice goal if LetuxOS would support all RasPi devices...

But in the meantime I got another hint: maybe the same reason why the SD size
limits exist.

Pi 0, 1, 2 use an ARMv6 while the others (except Pi 4) use ARMv7.

This finally explained to me why there is kernel.img and kernel7.img...
It is not strictly necessary to have two kernel builds and it turned out
that changing the letux_defconfig from

# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y

to

CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y

makes the kernel start on both :) Well, there are differences
(single core vs. quad core, different memory size etc.) but this
is taken care of by device tree and kernel.

But it fails running the Debian rootfs binaries (at least the
one I have tried so far). The same µSD plugged into the 3b+ boots
and runs fine.

So there must be something special in Raspbian or Debian for ARMv6.

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] ANN: LetuxOS on RasPi 3B+

[H. Nikolaus Schaller]

Hi Arsenijs,
I hope you are well and still reading this list.

> Am 13.01.2019 um 19:35 schrieb Pičugins Arsenijs :
> 
>> What about QtMoko for the ZeroPhone? Well, it uses
>> a PiZero and not RasPi3B+ but why not adapt things
>> as needed? The foundation is here now.
> 
> Let me know if you need any hardware, I can supply
> a phone or two at FOSDEM. I'm currently working on
> all the remaining pre-crowdfunding state and bringing
> the software up to standards, so I can't really allocate
> development time, but I'm available for discussions,
> explanations and help as needed.

Well, I now have got an RasPi 0W and some time to play with.
So I am trying to support it by LetuxOS as well.

For Raspbian images it is no problem - just swapping
the µSD is sufficient...

But when taking the RasPi 3B+ image the bootloader
finds and loads everything but the Kernel is not starting.

So which kernel did you use? Raspbian or some upstream?
Do you have an idea what the reasons might be?

BR and thanks,
Nikolaus


___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] LetuxOS for Rasi-Zero-W?

[H. Nikolaus Schaller]

Hi,
I am experimenting to get LetuxOS running on the
Raspi-Zero-W. It already works on the Raspi-3B+
for long time and basically the setup should be
cross-compatible.

I.e. it should be possible to swap the µSD card
between both. At least it "simply works(TM)" with
some Raspbian µSD - but not with my LetuxOS build.

It turns out that kernel+device-tree are not
being uncompressed and starting.

What I could not yet find out is if the mainline
kernel generally has a problem on Raspi-Zero (and
needs patches not upstream). Or if my build process
needs some tweaks because the 0W has subtle
differences to the 3B+ which manifest during kernel
uncompress (there was something like that with
the Letux 400 where the built-in U-Boot can't
uncompress a modern and big uImage).

Another observation is that the device tree binaries
are quite differently sized between Raspbian and
the LetuxOS build - and can not be swapped.

Does anyone on this list have experience with
building and running mainline kernels for the
Raspi-Zero?

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Someone in Germany thinking about a Featurephone based on simple Linux

[H. Nikolaus Schaller]

Hi,

> Am 03.08.2021 um 16:55 schrieb Paul Boddie :
> 
> On Tuesday, 3 August 2021 11:12:58 CEST H. Nikolaus Schaller wrote:
>> Hi,
>> I just came across this post (in German):
>> https://www.mikrocontroller.net/topic/522691
> 
> My German is far from sufficient to appreciate this post, and my knowledge of 
> Norwegian doesn't make it convenient enough to really digest the content, but 
> it sounds like the idea is to retread the path that various projects have 
> taken over the years, providing classic mobile functionality (without "app" 
> stores and browsers) on a Linux platform. Testing my browser history yielded 
> these projects:
> 
> http://www.davidhunt.ie/piphone-a-raspberry-pi-based-smartphone/
> 
> https://www.crowdsupply.com/arsenijs/zerophone
> https://zerophone.github.io/newsletter/
> 
> I know that the ZeroPhone creator was following this list at one point, so 
> maybe he has some perspectives on this kind of thing. Although I was 
> skeptical 
> about the ZeroPhone to start with, I was looking forward to seeing the end 
> result. I still think that these projects are a nice idea, but the economics 
> are awkward if not prohibitive, and the compromises that arise from using off-
> the-shelf boards risk making the resulting devices fairly unattractive.

Indeed, such projects can not be run under standard economic goals. But
for tinkerers and hobbyists there is more reward from learning how it is to
be done and having something unique that buying something locked down off
the shelf, even if the latter is cheaper. It is all about price / performance
and "performance" can have different factors.

> Also, I think the software issues are hugely underestimated, particularly 
> when 
> Linux is brought in as some kind of solution when it is merely a starting 
> point, often for a long and punishing process of developing the necessary 
> functionality to make such products viable, as I am sure Nikolaus will agree, 
> given that we have discussed this elsewhere often enough!

Yes, we are still not back at the GTA04 power management level of the v3.12
kernel although much has been upstreamed up to v5.14-rc3.

And QtMoko is still a ruin to be resurrected...

BR,
Nikolaus
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] Someone in Germany thinking about a Featurephone based on simple Linux

[H. Nikolaus Schaller]

Hi,
I just came across this post (in German): 
https://www.mikrocontroller.net/topic/522691

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] LetuxOS: new updates

[H. Nikolaus Schaller]

Hi,
and again just a small step:

v5.14-rc3 is here.

And, I have started to work with Paul to upstream the jz4780/ci20
hdmi drviers. There was some request by maintainers to use the
"component framework" but all our attempts to modify the driver
break it so far.

If you have questions or suggestions for the future of LetuxOS
please just state them.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] LetuxOS: new updates

[H. Nikolaus Schaller]

Hi,
what is new this week?
Not much or a lot - depending on how you view it.

a) kernel 5.14-rc2 is built

and as usually a lot of stable / longterm kernels.
See: https://projects.goldelico.com/p/gta04-kernel/

b) i386/x86 version of LetuxOS kernel and debian images

I recently got an ACEPC T11 which is a small Z8350 based
machine - quite similar in number and type of interfaces
to a RasPi 3 or 4. Main difference is that it comes with
a case, i.e there is no RasPi Cape connector. But it has
an SCSI slot inside so there is room for a big HDD or SSD.

What I managed is to pull a bootloader/grub.cfg from a
Debian live stick and place it into our LetuxOS repository.

A fix to makesd allows to

DEV=/dev/$some_usb_stick makesd -v latest x86 -r minimal

Well, only after cross-compiling a kernel for i386 and
debootstrapping some root file system.

The main challenge was to make the kernel find the usb
memory stick for booting... The first working kernel was
one where all =m CONFIGs were replaced by =y. This made
the kernel binary include all required device drivers plus
thousands of others. But it did now find the USB memory
as roots.

I have switched back many subsystems to =m because drivers
are rarely needed and can be loaded on demand, but there
are certainly some strange things inside. For example booting
stalls for 20 seconds waiting for some RAID device.

Anyways, starting with letux-5.14-rc2 there is now a build
for i386:

https://download.goldelico.com/letux-kernel/latest-i386/

You may note that there is also an amd64 kernel package
but it is the same 32 bit kernel because I have to update
my cross-compiler first to include 64bit gcc and libs.

I hope you appreciate this work and maybe we can get
some desktop Replicant 4.2 running one day. Or QtMoko
and QuantumSTEP.

This would be close to the final dream of a single
distribution for desktop, notebook, tablet, smartphone,
SBC and embedded controller. No fihting with missing
packages here or there, different configs, strange
workarounds by device distribution maintainers etc.

Thats it for this week. Hopefully more next week.
I plan to look again into the SGX driver for the Pyra
which was reported to have failed with v5.8-rc1 and later.

BR,
Nikolaus
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Selling My GTA04 Smartphone + Accessories. UK

[H. Nikolaus Schaller]

Hi,

> Am 18.07.2021 um 23:25 schrieb maillist_tinkerpho...@aross.me:
> 
> Had a go at making a external 18650 battery adapter. snag is it needed 
> software change to work with dumb li-ion cells instead of the special gta04 
> cells. so it got shelfed. was not pocket size anyway xd.

I still have a bag of original HF08 batteries and despite being 10 years since 
production they are usually good.

What is not good is that it is nowadays almost impossible to ship them anywhere 
at reasonable cost. Regulations for shipping LiIon have been tightened and even 
a single small battery with short circuit protection is dangerous good.

BR,
Nikolaus
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Inferno on Letux 400 Minibook

[Dr. H. Nikolaus Schaller]

Yes on my Unit trackpad is an usb device. Only the two mouse Buttons Go to gpio.

On The Road

> Am 03.06.2021 um 15:31 schrieb David Boddie :
> 
> On Tue Jun 1 09:06:43 CEST 2021, H. Nikolaus Schaller wrote:
> 
>> We have almost all peripherals working in Letux kernel so that can be some
>> inspiration hot to address the devices.��
> 
> Did you get the trackpad to work? It looks like it should be handled via the
> PS/2 controller, but I'm having trouble getting the controller to talk to it.
> 
> I send commands via the controller but it always responds with a resend (FE)
> byte.
> 
> The programming manual suggests that mouse support is not implemented, but
> then how would the trackpad work?
> 
> David
> ___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Inferno on Letux 400 Minibook

[H. Nikolaus Schaller]

Hi David,
cool!

What I have just finished is a new RS232 console adapter for the Letux 400.

Unfortunately it works only on my (light green) sample device because the
later ones are missing the 4 pin PicoBlade connector in the battery bay. It
could be retrofitted but means opening the device and unfortunately the 
instructions
on Kwaak are lost. I remember that it was quite tricky to deinstall the display
hinge to get to the backside of the processor board.

Anyways, if anyone needs such an adapter I could provide kits or assembled
units.

BR,
Nikolaus


> Am 01.06.2021 um 17:36 schrieb David Boddie :
> 
> The code I wrote to support simple microSD card reading on the Ben NanoNote
> worked almost without modification on the Minibook.
> 
> I seem to remember that I ran into complications on the NanoNote, but perhaps
> the larger screen will be useful for diagnosing them.
> 
> The repository can be found here:
> https://gitlab.com/dboddie/inferno-os/-/tree/minibook
> 
> David___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Inferno on Letux 400 Minibook

[H. Nikolaus Schaller]

Hi David,


> Am 31.05.2021 um 17:49 schrieb David Boddie :
> 
> With a lot of help from Paul, I have been looking at running Inferno on the
> Letux 400 - see the attached picture.
> 
> I started with Paul's L4 port for the Ben NanoNote to get up and running
> because the supplied U-Boot sets up the framebuffer, making it easier to
> debug problems.
> 
> Ultimately, the size of the screen and the type of keyboard on the NanoNote
> make it less than ideal to debug and test on, so I used Paul's L4 work and
> my existing code to get things working on the Letux 400 as well. He also
> helped me to debug the LCD setup, making it possible to start looking at
> supporting the keyboard and other peripherals.

We have almost all peripherals working in Letux kernel so that can be some
inspiration hot to address the devices.

> One of the problems I encountered with the NanoNote was related to floating
> point emulation, so I hope that the larger screen on the Minibook makes it
> easier to print diagnostic information when things go wrong.

Indeed :)

BR and thanks for letting us know about your breakthrouh,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Librem 5

[H. Nikolaus Schaller]

> Am 13.02.2021 um 22:42 schrieb David Boddie :
> 
> On Sat, 13 Feb 2021 20:28:01 +0100 Dr. Michael Lauer wrote:
> 
>> When I was younger, I could understand the ?fixation? on getting things into
>> mainline ? now, with more years on my back, I believe things would have
>> turned out differently if we were to follow the path of most commercial
>> developers ? which is, freezing the kernel at one point of time to allow
>> the rest of the folks to move forward without a moving target.
>> 
>> Later on, perhaps, submit stuff upstream, jump to another mainline kernel
>> (if necessary), rinse and repeat.
> 
> I agree. The focus on mainlining everything is above and beyond what the
> license requires.

Indeed the wish for upstreaming is not triggered by license but by practical 
needs.

One factor is that the more code is not part of mainline the more resources
are needed to maintain these non-mainline parts and e.g. take care of memory
leaks, security flaws etc. If they are mainline, the whole community takes
care of this and this saves resources of the project.

> 
> It's great if someone can check out the latest kernel and build it for a
> device, but some patches are never going to get upstream. Also, if your users
> need additional stuff to get a working device, having a buildable mainline
> kernel is of limited use.
> 
> Upstreaming everything is also an overhead that most projects can't afford
> unless you want to tie your features to the release schedules of your
> dependencies. One option is to get your upstreams on-board with your plans,
> but that's also a drain on resources. You also have to give up some control,
> which can be a difficult thing to accept.

The other problem of not following mainline is that it makes a project much 
faster
obsolete than it needs to be. Most users want to be able to install the latest
and greatest on their hardware, even if they do not need it... But they decide
for or against projects on that basis.

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Librem 5

[H. Nikolaus Schaller]

Hi Mickey,

> Am 13.02.2021 um 20:28 schrieb Dr. Michael Lauer :
> 
>> But app developers (like those developing QtMoko) did expect 100% which we
>> even have not achieved many years after the active development of QtMoko 
>> ended.
> 
> Not just app developers, also middleware. In fact, the whole userland is 
> depending on a 100%
> functioning kernel – otherwise it’s just no fun anymore.
> 
> When I was younger, I could understand the „fixation“ on getting things into 
> mainline – now, 
> with more years on my back, I believe things would have turned out 
> differently if we were
> to follow the path of most commercial developers – which is, freezing the 
> kernel at one point
> of time to allow the rest of the folks to move forward without a moving 
> target.

IMHO the solution is to do both. Try to get things upstream (so that we don't 
have to
maintain them any more if there are upstream modifications to include files or 
function
names etc) *and* try to work on a freezed kernel release.

Fortunately, this has become much easier easier than in v3.x times. Now there 
are longterm
stable releases and it is not that difficult to pull in upstream patches and 
combine them
with non-upstream stuff to make a really good and stable kernel while still 
participating
on security fixes and other backports that are done by the kernel community.

LetuxOS currently defines v5.4 as the current "stable" basis [1] which is not a 
moving target.
It works well on most hardware and isn't missing much. Even the old 
replicant-4.2 boots and
can be used for almost everything by using a slightly modified kernel variant.

v5.10 is the next long term kernel. Unfortunately it has some regressions and 
replicant still
fails boot to a user-interface (which is very difficult to debug). But it will 
come one day.

But generally there is no excuse not to do middleware development :)

> 
> Later on, perhaps, submit stuff upstream, jump to another mainline kernel (if 
> necessary), rinse
> and repeat.

The problem we see with ignoring mainline movements is that there is a too big 
gap between
such long-term kernels like v4.19 and v5.10. This makes it really difficult to 
find out what
the regressions are and how to cure them. This means sticking with only one 
major kernel
release (let's say v4.19) works only for commercial developers who are able and 
want to offer
new hardware let's say every 1-2 years and then abandon all the old stuff.

Unfortunately community hardware like GTA04 or Librem 5 or PinePhone need to 
stay much
longer alive so that nobody would be happy if we stick too long with old 
kernels only...

So IMHO the strategy is to run multiple kernel variants. Fortunately, this is 
not as much
additional work as it looks like. This is generally manageable.

The bigger problem is to understand some subtle behaviour of hardware and 
kernel when it
comes to power management. And it needs permanent evaluation if it is broken by 
some changes.

This has become too much work for volunteers... So power management of the 
GTA04 is nowadays
not better (if not worse) than with the old good 3.12 kernel. But a recent 
kernel is much
faster and more secure and adds new functions and even enables new user-space 
features.

Difficult choice if we aim at optimal power management *and* optimal 
functionality+security :)

BR,
Nikolaus

[1]: https://projects.goldelico.com/p/gta04-kernel/
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Librem 5

[H. Nikolaus Schaller]

> Am 13.02.2021 um 15:28 schrieb Jonas Smedegaard :
> 
> Quoting H. Nikolaus Schaller (2021-02-13 14:53:00)
>> 
>>> Am 13.02.2021 um 11:52 schrieb Jonas Smedegaard :
>>> 
>>> Quoting michael spreng (2021-02-13 10:45:18)
>>>> In December I received my librem5 phone and now had some time to try 
>>>> it out. It seems to work reasonably well, can make phone calls and 
>>>> messages. Though there is no support yet for the camera.
>>> 
>>> Seems camera support saw progress for the low-level driver part as 
>>> recent as yesterday: 
>>> https://source.puri.sm/Librem5/linux-next/-/merge_requests/309
>>> 
>>> User-level access to camera seems tracked here: 
>>> https://source.puri.sm/Librem5/Apps_Issues/-/issues/6
>>> 
>>> Using the camera from sripts seems possible since 2 months (but possibly 
>>> specific to certain revision of the phone, or maybe the devkit): 
>>> https://source.puri.sm/Librem5/linux-next/-/merge_requests/255
>>> 
>>> The phone ships with the more stable "amber" release of PureOS.  Geeks 
>>> might wanna explore the in-progress "byzantium" release instead, to get 
>>> and play with bleeding edge changes: 
>>> https://developer.puri.sm/Librem5/Development_Environment/Phone/Troubleshooting/Reflashing_the_Phone.html
>>> 
>>> 
>>>> Though programs not adapted for the phone screen are rather weird, 
>>>> like vlc.
>>> 
>>> A geeky way to locate _some_ adaptive apps is to look for packages 
>>> depending on libhandy-1-0 (or libhandy-0.0-0).  That only covers GTK 
>>> apps, though - I am unaware if any such package-level indicators exist 
>>> for Qt-based apps like VLC.
>>> 
>>> The user-friendly way is to use the appstore, which shows only adaptive 
>>> apps - and yes, there are only very few so far...
>> 
>> I am sure this will change.
> 
> If by "this" you mean availability of adaptive apps,

yes.

> then I agree: Seems 
> to me there is enough momentum - e.g. multiple vendors reusing code from 
> each other, all tied to mainline Linux
> 
> 
>> Our GTA04 history shows that the basics must work and then come apps. 
>> Unfortunately it is a sisyphos work to make the basics work and keep 
>> them running... So manpower to keep pace with upstream kernel releases 
>> is key.
>> 
>> The main reason why we were (are) stuck with QtMoko and Replicant 
>> is that the kernel is still not in a perfect shape like people need
>> so that they can focus on improving their apps. And in the meantime
>> nobody knows any more how to rebuild QtMoko and Replicant from scratch
>> on a recent build system.
> 
> Seems to me the failure is directly tied to getting code pushed 
> upstream.
> 
> Obviously when upstream project is dead (as is the case for QtMoko) 
> there is no way to upstream - apart from taking over as upstream.  And I 
> guess over-the-fence upstreams like Qt and Google can be painful to push 
> changes to (e.g. require copyright assignment), but I am not familiar 
> with the details of those.
> 
> Purism evidently invest in pushing code to mainline Linux and u-boot 
> (and other projects higher up the stack as well).  Time will tell if 
> they push enough, and if there continues to be enough momentum.

Indeed.

For the fate of the GTA04, the team pushing code became smaller and smaller
over time because there is less and less reward from doing. So momentum
was lost.

So if I look back the past 10 years of pushing GTA04 fixes to kernel.org we
always had been between 95 and 98% upstreamed. But never got beyond. Rather
we spent more and more time of fixing upstream regressions in that parts that
upstream maintainers didn't like.

But app developers (like those developing QtMoko) did expect 100% which we
even have not achieved many years after the active development of QtMoko ended.
Still we can demo the old QtMoko and Replican 4.2 stuff un latest upstream
kernels but they are not good enough for daily use.

And pushing something upstream to kernel.org needs more than volunteers can
provide. I think the latest statistics I did see is that less than 20%
of upstream kernel contributors are volunteers. The majority is payed
by big enterprises (cloud and SaaS providers, semiconductor industry).

Let's hope the Purism business model allows to keep this running.

My key learning is that quality of the overall system is key. Not the
hardware or the kernel or the user-space alone. Everything must fit
together to give users a smooth experience. And that is too much for
small initiatives.

> 
> I am optimistic.

+++

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Librem 5

[H. Nikolaus Schaller]

> Am 13.02.2021 um 11:52 schrieb Jonas Smedegaard :
> 
> Quoting michael spreng (2021-02-13 10:45:18)
>> In December I received my librem5 phone and now had some time to try 
>> it out. It seems to work reasonably well, can make phone calls and 
>> messages. Though there is no support yet for the camera.
> 
> Seems camera support saw progress for the low-level driver part as 
> recent as yesterday: 
> https://source.puri.sm/Librem5/linux-next/-/merge_requests/309
> 
> User-level access to camera seems tracked here: 
> https://source.puri.sm/Librem5/Apps_Issues/-/issues/6
> 
> Using the camera from sripts seems possible since 2 months (but possibly 
> specific to certain revision of the phone, or maybe the devkit): 
> https://source.puri.sm/Librem5/linux-next/-/merge_requests/255
> 
> The phone ships with the more stable "amber" release of PureOS.  Geeks 
> might wanna explore the in-progress "byzantium" release instead, to get 
> and play with bleeding edge changes: 
> https://developer.puri.sm/Librem5/Development_Environment/Phone/Troubleshooting/Reflashing_the_Phone.html
> 
> 
>> Though programs not adapted for the phone screen are rather weird, 
>> like vlc.
> 
> A geeky way to locate _some_ adaptive apps is to look for packages 
> depending on libhandy-1-0 (or libhandy-0.0-0).  That only covers GTK 
> apps, though - I am unaware if any such package-level indicators exist 
> for Qt-based apps like VLC.
> 
> The user-friendly way is to use the appstore, which shows only adaptive 
> apps - and yes, there are only very few so far...

I am sure this will change. Our GTA04 history shows that the basics
must work and then come apps. Unfortunately it is a sisyphos work
to make the basics work and keep them running... So manpower to
keep pace with upstream kernel releases is key.

The main reason why we were (are) stuck with QtMoko and Replicant 
is that the kernel is still not in a perfect shape like people need
so that they can focus on improving their apps. And in the meantime
nobody knows any more how to rebuild QtMoko and Replicant from scratch
on a recent build system.

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Librem 5

[H. Nikolaus Schaller]

> Am 13.02.2021 um 10:45 schrieb michael spreng :
> 
> Hi
> 
> Some time ago there was a discussion if any librem5 have shipped, so I
> thought I would write a bit about mine:
> 
> In December I received my librem5 phone and now had some time to try it
> out. It seems to work reasonably well, can make phone calls and
> messages. Though there is no support yet for the camera. It has a
> console which is preinstalled, ant apt install just works, nice. Though
> programs not adapted for the phone screen are rather weird, like vlc.
> But console ones is no problem, which is nice.
> 
> Now let's see if it is as long lived as the gta04

Yes, I hope so...

> 
> best regards
> Michael
> ___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Anyone with a Pinephone reading here?

[H. Nikolaus Schaller]

Hi,

> Am 29.01.2021 um 19:11 schrieb H. Nikolaus Schaller :
> 
> Hi,
> I am trying to get the PinePhone modem working in the LetuxOS kernel and need 
> someone to discuss.
> 
> There is a modem-power driver here: 
> 
>   
> https://megous.com/git/linux/commit/?h=modem-5.11&id=8c92fd271f11384361fae5fda13ef35195279843

just a short status report. Thanks to the help of someone from the community
I was able to integrate the modem manager an make it work.

> but it is quite complex and not very general and mixes several functions. I 
> also tried these scripts:
> 
>   https://megous.com/dl/tmp/modem.txt
> 
> With no success to get an USB interface or /dev/ttyS3 (assuming that it is 
> uart3) working.
> 
> And we have our own modem power driver (tested for GTA04 and Pyra) which I'd 
> prefer to extend:
> 
>   
> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/wwan-v2

So I can now start to find out why it didn't work with our GTA04 driver.

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] Replicant 4.2 with LetuxOS kernel 5.10

[H. Nikolaus Schaller]

Hi all,
I played a little on the GTA04 with Replicant 4.2 and the
latest letux-5.10.10-replicant kernel [1].

It starts up to a console shell but then the boot process stops.

It appears as if the 'zygote' process tries (or succeeds)
to launch the 'system_server' process but then exits.

root@android:/ # uname -a
Linux localhost 5.10.10-letux-replicant #4842 SMP PREEMPT Sat Jan 30 08:46:17 
CET 2021 armv7l GNU/Linux
root@android:/ # ps 

USER PID   PPID  VSIZE  RSS WCHANPC NAME
root  1 0 388260   0001  S /sbin/init
root  2 0 0  0 0001  S kthreadd
root  3 2 0  0 0001  I rcu_gp
root  4 2 0  0 0001  I rcu_par_gp
...
root  9311  2 0  0 0001  I 
kworker/0:0-events_power_efficient
root  10201 2 0  0 0001  I kworker/0:1H
root  10908 2 0  0 0001  I kworker/0:1-events
root  11171 1 279452 48620   S zygote
system11175 11171 287408 23116   D system_server
root  11188 1937  1132   400     R ps
root@android:/ # [ 8034.207000] init: untracked pid 11171 exited
[ 8034.288116] init: untracked pid 11175 exited

There is an overview of the Android boot process [2], but 
there is no mechanism to debug...

The same user-space works fine with letux-5.4.92-replicant, so it
is some kernel incompatibility.

Any hints and help are welcome,
Nikolaus

[1]: 
https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-5.11-rc5-replicant
[2]: https://medium.com/@voodoomio/what-the-zygote-76f852d887d9


___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] Anyone with a Pinephone reading here?

[H. Nikolaus Schaller]

Hi,
I am trying to get the PinePhone modem working in the LetuxOS kernel and need 
someone to discuss.

There is a modem-power driver here: 


https://megous.com/git/linux/commit/?h=modem-5.11&id=8c92fd271f11384361fae5fda13ef35195279843

but it is quite complex and not very general and mixes several functions. I 
also tried these scripts:

https://megous.com/dl/tmp/modem.txt

With no success to get an USB interface or /dev/ttyS3 (assuming that it is 
uart3) working.

And we have our own modem power driver (tested for GTA04 and Pyra) which I'd 
prefer to extend:


https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/wwan-v2

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] Happy New Year - and a better new year

[H. Nikolaus Schaller]

Dear all,
I wish you a happy and better new year.

We have got some funding by a generous community member in December so
that technical operation of the community resources is secured for
a while.

So please make use of these lists if you think they are still valuable.
And please share your ideas and wishes and expectations.

Best wishes and stay safe,
Nikolaus Schaller

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] How many Librem 5 and Pinephones have been sold?

[H. Nikolaus Schaller]

Hi Rainer,

> Am 03.11.2020 um 23:24 schrieb Rainer Dorsch :
> 
> ...according to
> 
> https://www.reddit.com/r/PINE64official/comments/eip86r/
> how_many_brave_heart_units_sold_until_now/
> 
> around 3K brave heart edition pine phones.
> 
> The according to
> 
> https://en.wikipedia.org/wiki/PinePhone
> 
> there have been 3-4 (did the postmarket OS edition ship already?) more 
> editions.
> 
> Assuming similar average numbers as for brave heart (which is an assumption 
> with uncertainty) I would expect in the order of 10k-20k devices in total.

That is approximately the same as OpenMoko were sold.

Any info about Librem 5?

> 
> Regards
> Rainer
> 
> Am Dienstag, 3. November 2020, 17:37:53 CET schrieb H. Nikolaus Schaller:
>> and shipped?
>> 
>> Is there any information about this? Some blog / forum info?
>> 
>> BR and thanks,
>> hns
>> 
>> ___
>> Community mailing list
>> Community@tinkerphones.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/community
>> http://www.tinkerphones.org
> 
> 
> -- 
> Rainer Dorsch
> http://bokomoko.de/
> 
> 
> ___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] How many Librem 5 and Pinephones have been sold?

[H. Nikolaus Schaller]

and shipped?

Is there any information about this? Some blog / forum info?

BR and thanks,
hns

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Mailing list about low levels of Linux on cellphones

[H. Nikolaus Schaller]

Hi Pavel,

> Am 09.09.2020 um 00:56 schrieb Pavel Machek :
> 
> Hi!
> 
> It seems there is quite a lot of efforts porting kernel to various
> cellphones.

Yes, and it is sisyphos work to get it 100% into mainline... Most
projects I know about are at 99,5%.

> 
> Librem 5 and PinePhone have their own hardware, people around Maemo
> Leste work with Nokia N900 and Droid 4, there's group working with
> Sony cellphones, there are postmarketOS people and there are probably
> groups I don't know about.

And there is Openmoko and successors (GTA04, Pyra, GTA15).

> I believe some coordination would be useful, so we end up with
> compatible solutions for various problems.

IMHO the main problem we all share is power management.

> 
> It would be also good to know how ther hardware is progressing. I'd
> really like to have phone I could use as a _phone_, running mainline
> kernel. So far N900 with original Maemo is closest I could get. 
> 
> Would it be possible to create a mailing list on vger.kernel.org?

Hm. My experience with asking for creating an openpvrsgx mailing list
at vger.kernel.org was like asking the sun to shine during night.

In the end we did set up our own mailing list and github project:

https://lists.openphoenux.org/mailman/listinfo.cgi/openpvrsgx-devgroup
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx

What I can offer is to run a similar list. You may remember that
OpenPhoenux was the continuation of the OpenMoko community mailing lists
having the same focus as you describe above.

> Probably phones@ or phone-devel@? I believe it would be useful to
> cover hardware-dependend pieces of the phone stack (ofono,
> modemmanager) as well as kernel.

I am fine with either.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] LetuxOS for PinePhone

[H . Nikolaus Schaller]

Hi,
I was able to spend half a day to fix several issues and now the latest 
letux-5.6.y
and letux-5.7.y kernels are working again on the PinePhone. And even 
letux-5.8-rc3
boots.

Working is:
* boot
* Display with backlight
* heartbeat LED
* iio sensors (accelerometer, gyro, light)
* /dev/input/touchscreen and /dev/input/accel
* vibra (/dev/input/rumble) - so we can play MokoMaze :)
* WiFi
* USB-C port for charging (not sure if reliable) and ethernet gadget

It appears that not working is:
* Sound (aplay -L is empty)
* WWAN and telephone module
  (maybe I have to configure something or it needs to be powered on)
* Bluetooth (on 5.6 it says it can't find the firmware - maybe I just
  haven't installed it correctly and on 5.7 it does not respond to anything)
* power management / suspend
* detection of USB-C cable unplugging by usb stack
* battery backup RTC

Although v5.6 is EOL I will force build an update so that there will be
soon prebuilt binaries for or makesd tool.

To summarize my impressions, this is what we always have dreamed of as a
successor of the GTA04. Doing coding on bootloader, kernel or user-space
level feels almost familiar (including that private trees work much better
than pure kernel.org). But also no special tricks by vendors who want to
lock us out.

It's just too bad *we* haven't been able to get to where PinePhone is
from hardware side. Anyways, PinePhone deserves our respect and support.

BTW: it is not more difficult to get QtMoko or Replicant ported to
the GTA04 or PinePhone. It could even be possible to use the same
rootfs image and just have different kernels...

So if you own a PinePhone, please help to make LetuxOS on PinePhone
better.

BR and thanks,
Nikolaus

[project]: https://projects.goldelico.com/p/gta04-kernel/
[latest patches]: 
https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-5.6.y


___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] QuantumSTEP on PinePhone

[H. Nikolaus Schaller]

Hi,
after fixing the kernel build and some small config issues I was able to start 
QuantumSTEP on the PinePhone.
A problem is the capacitive touch screen (finger sensitive) which is not 
optimal for positioning the X11
mouse pointer. But it simply works. One just has to make a µSD card, insert and 
power on.

A photo is here: https://twitter.com/goldelico/status/1231991630594478083

If anyone on these lists happens to own a PinePhone:

1. download makesd: http://projects.goldelico.com/p/gta04-makesd/
2. run DEV=/dev/sdb /usr/local/bin/makesd -v latest pinephone -r quantumstep - 
assuming your SD-card reader is /dev/sdb
3. insert the µSD and power-on
4. use an USB cable an ethernet gadget driver to ssh into the device 
(root@192.168.0.202)
5. apt-get update && apt-get upgrade - to get some fixes

Note this is a demo system with low priority on security and being bug free...
So you should not yet expect it to be a good and robust Phone GUI (like 
Replicant or QtMoko).

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] LetuxOS on PinePhone

[H. Nikolaus Schaller]

Hi,
I have a first image that I can 'makesd' on a fresh µSD:

makesd -u
DEV=/dev/sdb makesd -v latest pinephone -r quantumstep

It is not yet useable since it doesn't initialize X11 (there is no
proper setup for the Allwinner SoC). And, there is no tty on
the serial console. Just a login: blinking on the screen.

I have to find out why before I can start to fix the setups
and make a video...

Attached is a boot log.

BR,
Nikolaus



U-Boot SPL 2019.04-01010-g97c65687fd (Apr 26 2019 - 23:05:26 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.1(debug):v2.1-109-gc3e4e088
NOTICE:  BL31: Built : 23:03:52, Apr 26 2019
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x40893e0, model: SoPine with baseboard
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE:  BL31: PMIC: Detected AXP803 on RSB.
INFO:PMIC: AXP803: dcdc1 voltage: 3.300V
INFO:PMIC: AXP803: dcdc5 voltage: 1.200V
INFO:PMIC: AXP803: dcdc6 voltage: 1.100V
INFO:PMIC: AXP803: dldo1 voltage: 3.300V
INFO:PMIC: AXP803: Enabling DC1SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing!
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2019.04-01010-g97c65687fd (Apr 26 2019 - 23:05:26 +) UBports

CPU:   Allwinner A64 (SUN50I)
Model: SoPine with baseboard
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
724 bytes read in 1 ms (707 KiB/s)
## Executing script at 4fc0
7416015 bytes read in 332 ms (21.3 MiB/s)
Uncompressed size: 16124416 = 0xF60A00
32791 bytes read in 3 ms (10.4 MiB/s)
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
   Loading Device Tree to 49ff4000, end 49fff016 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 5.6.0-rc2-letux-arm64+ (h...@imac.fritz.box) (gcc 
version 4.9.2 (GCC)) #2178 SMP Fri Feb 21 10:30:56 CET 2020
[0.00] Machine model: PinePhone
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 32 MiB at 0xbe00
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x4000-0xbfff]
[0.00] NUMA: NODE_DATA [mem 0xbdbcf100-0xbdbd0fff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x4000-0x7fff]
[0.00]   DMA32[mem 0x8000-0xbfff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x4000-0xbfff]
[0.00] Initmem setup node 0 [mem 0x4000-0xbfff]
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] psci: SMC Calling Convention v1.1
[0.00] percpu: Embedded 22 pages/cpu s52352 r8192 d29568 u90112
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: detected: ARM erratum 845719
[0.00] CPU features: detected: ARM erratum 843419
[0.00] Speculative Store Bypass Disable mitigation not required
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 516096
[0.00] Policy zone: DMA32
[0.00] Kernel command line: console=ttyS0,115200 console=tty0 
root=PARTUUID=c30d97f0-01 rw rootwait
[0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 
bytes, linear)
[0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, 
linear)
[0.00] mem auto-init: sta

[Tinkerphones] LetuxOS on PinePhone

[H. Nikolaus Schaller]

Hi,
I had ordered a developer PinePhone last year and unfortunately
it did collect dust, because I was too disturbed by other
topics...

And, I had to build my aarch64/arm64 cross-toolchain first.

But now I have managed to build a Letux 5.6-rc2 kernel.
And just some minutes ago I was able to boot after tweaking
with some u-boot related files!

Now comes the very interesting and unexpected part.

I do not (yet) have an arm64 Debian rootfs for installation
through makesd and accidentially installed the standard
armhf (32 bit) Jessie image.

And that works as well. Up to a login: on the PinePhone screen.

Since it has no keyboard I can't login of course.
And the console login is not configured. There is
only console output but no getty running.

After this observation it does not seem to be complicated
to get LetuxOS Replicant or QtMoko running on this device!

What I have to do next is to adapt the makesd and other
tools so that we can easily bake a bootable µSD card.

So if you happen to own a PinePhone as well, please stay
tuned until I can share a working makesd command.

BR,
Nikolaus
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] LetuxOS: PinePhone support

[H. Nikolaus Schaller]

Hi Xavi,

> Am 03.02.2020 um 21:37 schrieb Xavi Drudis Ferran :
> 
> El Mon, Feb 03, 2020 at 07:24:22PM +0100, H. Nikolaus Schaller deia:
>> Hi,
>> finally, after bootstrapping my aarch64-linux-gnu (arm64) cross-toolchain
>> and fixing minor issues I am able to compile our kernel tree for
>> arm64 :)
>> 
>> Using a pinephone_defconfig from
>> 
>>  
>> https://gitlab.com/pine64-org/linux/blob/58a9a99b775d71c5b78f19da1a251788561d28cc/arch/arm64/configs/pinephone_defconfig
>> 
>> and letux-5.5.1 I got an 248 MB vmimage.
>> 
>> Next I have to find out which image compression is needed for the
>> U-Boot and how to place it on the SD card and then try to boot.
>> 
> 
> I don't know about Allwinner, but what I remember about Pine Rockpro64
> is that arm64 kernels can't decompress themselves. So uboot does that
> after loading and before booting.
> 
> You can cp Image.gz to the card and in bootcmd decompress it with the uboot 
> command:
> 
> unzip $compressedKernImgAdr $uncompressedKernImgAdr
> 
> My notes are somethign like
> 
> export CROSS_COMPILE=aarch64-linux-gnu- ; export ARCH=arm64
> make clean
> make ${something}_defconfig
> 
> make -j 12 BL31=bl31.elf  u-boot-dtb.bin spl/u-boot-spl.bin u-boot.itb
> ./tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin out #this will be 
> different for allwinner, I guess
> 
> 
> cp u-boot-rockchip/uEnv.txt /media/.../boot/
> cp linux-5.2.11/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtb 
> /media/.../boot/rk3399-rockpro64.dtb
> cp linux-5.2.11/arch/arm64/boot/Image.gz /media/.../boot/Image.gz
> 
> in uEnv.txt:
> 
> KERNCOMPADDR=0x1300
> KERNUNCADDR=0x1000
> DEVTREEADDR=0x1400
> bootargs=...
> bootcmd=ext4load mmc 1:1 $KERNCOMPADDR Image.gz; unzip $KERNCOMPADDR 
> $KERNUNCADDR; ext4load mmc 1:1 $DEVTREEADDR rk3399-rockpro64.dtb; booti 
> $KERNUNCADDR - $DEVTREEADDR

It looks like the Ubuntu Touch image (and U-Boot) for the PinePhone
exactly does this.

I can find on the SD card
/boot/boot-pinephone.scr
/boot/boot-pinephone.txt
/boot/Image.gz
and
/boot/dtb/allwinner/sun50i-a64-pinephone.dtb

And boot-pinephone.txt indeed does:

part uuid ${devtype} ${devnum}:${distro_bootpart} uuid
setenv bootargs console=${console} console=tty0 root=PARTUUID=${uuid} rw 
rootwait
setenv kernel_addr_z 0x4408

if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_z} 
/boot/Image.gz; then
  unzip ${kernel_addr_z} ${kernel_addr_r}
  if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} 
/boot/dtb/allwinner/sun50i-a64-pinephone.dtb; then
if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} 
/boot/initrd.img; then
  booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
  booti ${kernel_addr_r} - ${fdt_addr_r};
fi;
  fi;
fi

So your descriptions help a lot and I better know which files I can
simply copy and how to prepare the newly built files...

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] LetuxOS: PinePhone support

[H. Nikolaus Schaller]

Hi,
finally, after bootstrapping my aarch64-linux-gnu (arm64) cross-toolchain
and fixing minor issues I am able to compile our kernel tree for
arm64 :)

Using a pinephone_defconfig from


https://gitlab.com/pine64-org/linux/blob/58a9a99b775d71c5b78f19da1a251788561d28cc/arch/arm64/configs/pinephone_defconfig

and letux-5.5.1 I got an 248 MB vmimage.

Next I have to find out which image compression is needed for the
U-Boot and how to place it on the SD card and then try to boot.

Then it seems possible to create our own kernel and in a next
step dream about user-space (Replicant, QtMoko, QuantumSTEP) etc.

So this means from letux-5.6-rc1 on, there will also be initial
PinePhone support. Potentially we can also support the RasPi 4
if someone wants to try and find out a defconfig.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Community Digest, Vol 91, Issue 1

[H. Nikolaus Schaller]

> Am 28.01.2020 um 13:02 schrieb Niels Heyvaert :
> 
> Don't think so.
> 
> Unless there is a talk or presentation on /e/, Librem, OpenMoko, OpenPhoenix, 
> Replicant, ShiftPhone, PostMarketOS, FairPhone, ...

I think there is a talk about PostmarketOS and Maemo:

https://fosdem.org/2020/schedule/event/smartphones/

There is also Philip Coval who contributed to the Openmoko community:

https://fosdem.org/2020/schedule/speaker/philippe_coval/

And there is a plan for a Replicant Meetup:

https://fosdem.org/2020/schedule/event/bof_replicant/

Replicant lists PinePhone and Librem 5 as future targets.

I personally won't attend FOSDEM this year. I have too many other activities 
not related to hard&software...

BR,
Nikolaus

> 
> Van: Community  > namens 
> community-requ...@tinkerphones.org 
>  
>  >
> Verzonden: dinsdag 28 januari 2020 11:00
> Aan: community@tinkerphones.org  
> mailto:community@tinkerphones.org>>
> Onderwerp: Community Digest, Vol 91, Issue 1
>  
> Send Community mailing list submissions to
> community@tinkerphones.org 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.goldelico.com/mailman/listinfo.cgi/community 
> 
> or, via email, send a message with subject or body 'help' to
> community-requ...@tinkerphones.org 
> 
> 
> You can reach the person managing the list at
> community-ow...@tinkerphones.org 
> 
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Community digest..."
> 
> 
> Today's Topics:
> 
>1. Fosdem (Andreas Kemnade)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 27 Jan 2020 21:38:06 +0100
> From: Andreas Kemnade mailto:andr...@kemnade.info>>
> To: Tinkerphones Community  >
> Subject: [Tinkerphones] Fosdem
> Message-ID: <20200127213806.5872a...@kemnade.info 
> >
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> just wondering whether anyone of you is attending Fosdem this year.
> 
> Regards,
> Andreas
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL: 
>   
> >
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> Community mailing list
> Community@tinkerphones.org 
> http://lists.goldelico.com/mailman/listinfo.cgi/community 
> 
> http://www.tinkerphones.org 
> 
> --
> 
> End of Community Digest, Vol 91, Issue 1
> 
> ___
> Community mailing list
> Community@tinkerphones.org 
> http://lists.goldelico.com/mailman/listinfo.cgi/community 
> 
> http://www.tinkerphones.org 
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] PinePhone with Ubuntu Touch image boot log

[H. Nikolaus Schaller]

I now have built an RS232 adapter and get this boot message:

U-Boot SPL 2019.04-01010-g97c65687fd (Apr 26 2019 - 23:05:26 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.1(debug):v2.1-109-gc3e4e088
NOTICE:  BL31: Built : 23:03:52, Apr 26 2019
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x40893e0, model: SoPine with baseboard
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE:  BL31: PMIC: Detected AXP803 on RSB.
INFO:PMIC: AXP803: dcdc1 voltage: 3.300V
INFO:PMIC: AXP803: dcdc5 voltage: 1.200V
INFO:PMIC: AXP803: dcdc6 voltage: 1.100V
INFO:PMIC: AXP803: dldo1 voltage: 3.300V
INFO:PMIC: AXP803: Enabling DC1SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing!
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2019.04-01010-g97c65687fd (Apr 26 2019 - 23:05:26 +) UBports

CPU:   Allwinner A64 (SUN50I)
Model: SoPine with baseboard
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
724 bytes read in 1 ms (707 KiB/s)
## Executing script at 4fc0
7454037 bytes read in 329 ms (21.6 MiB/s)
Uncompressed size: 16334856 = 0xF94008
29648 bytes read in 9 ms (3.1 MiB/s)
4634987 bytes read in 205 ms (21.6 MiB/s)
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
   Loading Ramdisk to 49b94000, end 49fff96b ... OK
   Loading Device Tree to 49b89000, end 49b933cf ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 5.4.0-pine64 
(root@runner-mUSadhTy-project-11304676-concurrent-0) (gcc version 7.4.0 
(Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #1 SMP Thu Dec 12 17:22:15 UTC 2019
[0.00] Machine model: PinePhone
[0.00] cma: Reserved 256 MiB at 0xb000
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x4000-0xbfff]
[0.00] NUMA: NODE_DATA [mem 0xafbd3800-0xafbd4fff]
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x4000-0xbfff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x4000-0xbfff]
[0.00] Initmem setup node 0 [mem 0x4000-0xbfff]
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] psci: SMC Calling Convention v1.1
[0.00] percpu: Embedded 22 pages/cpu s49880 r8192 d32040 u90112
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: detected: ARM erratum 845719
[0.00] CPU features: detected: ARM erratum 843419
[0.00] Speculative Store Bypass Disable mitigation not required
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 516096
[0.00] Policy zone: DMA32
[0.00] Kernel command line: console=ttyS0,115200 console=tty0 
root=PARTUUID=d5f53902-01 rw rootwait
[0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 
bytes, linear)
[0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] Memory: 1773592K/2097152K available (10430K kernel code, 720K 
rwdata, 3988K rodata, 768K init, 406K bss, 61416K reserved, 262144K 
cma-reserved)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=64 t

[Tinkerphones] Comparison PinePhone to Librem 5

[H. Nikolaus Schaller]

IMHO quite well written:


https://amosbbatto.wordpress.com/2019/12/01/decide-pinephone-vs-librem-5/

I could now boot my developer PinePhone to Ubuntu Touch and it works.
Well, it is a little difficult to find out how to operate Ubuntu
Touch without a user manual... So I could not really use it. But
this is not the hardware to blame for.

The Galaxy J7 battery doesn't fit 100% so I would have to cut
off some tiny pieces of plastic to make it fit. Fortunately, it
started to charge the unlabeld battery that came with the PinePhone.

So if I find time, I want to try to get access to the serial console
and find out if I can configure the USB port to become an ethernet
gadget. Both will make software development easier.

The plan is to port LetuxOS and first steps have been made:

http://download.goldelico.com/letux-u-boot/PinePhone/20191220/
http://git.goldelico.com/?p=letux-makesd.git;a=commit;h=5a2d803d892c1d0124f6123c47b99b7b042021d5

What is missing is a LetuxOS kernel which needs a 64 bit ARM
(cross)toolchain I currently do not have in my setup. Otherwise
it should not be difficult to modify the letux_defconfig.

Happy hacking,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] PinePhone arrived...

[H. Nikolaus Schaller]

Hi,
I had recently ordered a developer unit of the PinePhone and it just has 
arrived :)

Wow, is it big and does it feel heavy (186g)...

Here is a first photo comparing to the GTA04 (left) and the PyraPhone (GTA15 
prototype, right) which I had built a while ago.

Really nice is the thickness. It is just half as thick as the GTA04.

Now I have to
* charge it
* find time to play with it
* learn how to flash it
* prepare a Letux kernel and OS...

Anyone else here with a PinePhone?

BR,
Nikolaus


___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Problems seem to repeat...

[H. Nikolaus Schaller]

> Am 07.12.2019 um 14:05 schrieb H. Nikolaus Schaller :
> 
> 
>> Am 07.12.2019 um 13:35 schrieb Paul Boddie :
>> 
>> On Saturday 7. December 2019 08.37.23 H. Nikolaus Schaller wrote:
>>> I just came across:
>>> 
>>> https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-a->
>>>  hypothesis
>>> 
>>> So they also ran into unexpected solder bridges which must be X-Rayed. This
>>> sounds very very familiar to me...
>>> 
>>> With our experiences collected in the GTA04 project many years ago, I think
>>> it is easy to fix - if you have enough money or can borrow money to make
>>> some costly experiments with the production line setup.
>> 
>> I mentioned on the arm-netbook mailing list that similar problems were 
>> experienced before, albeit with the RAM chips:
>> 
>> http://rhombus-tech.net/ingenic/jz4775/news/EOMA68-jz4775_XRay_Photos/
>> 
>> So, I thought that the manufacturer might have built up some experience 
>> since 
>> then. From the latest update, it sounds like this is a production process 
>> problem, with the prototypes having been made without issues, so I guess 
>> that 
>> the matter of soldering the chips is not a fundamental problem but just 
>> something that needs to be done correctly in the production environment.
> 
> Yes, exactly the same issue we had with the GTA04. We knew that Nokia had
> built millions of phones incl. the N900 using the OMAP3 + PoP memory but
> failed.

I think this sentence could be misunderstood. Nokia had successfully built
millons of phones using the OMAP3 + PoP memory. And we failed with the same.

> 
> Then we got a manufacturer who adapted and learned how to properly produce
> them on their line.
> 
> Then, OpenPandora switched from omap3530 to dm3730 (like we aready had) and
> had only failures. Finally their production line learned how to produce them.
> 
> And then we did go to the same production line as the 1GHz OpenPandora
> with the GTA04A5 - and they failed. Almost. Well approx. 30% yield which
> was too low. We tried to optimize, but the GTA04A5 project did run out of
> money.
> 
>> 
>> (I wouldn't know what the difference between the pre-production and 
>> production 
>> environments are in this case. There were also some other production-related 
>> issues around board-edge component assembly, if I remember correctly.)
>> 
>>> But borrowing money requires a business model which promises future
>>> revenues.
>>> 
>>> Without money it needs a lot of creativity and time to replace the missing
>>> money.
>> 
>> I think that these experiments rely on a helpful and rather generous factory 
>> owner who is looking to gain experience in the processes involved.
> 
> Indeed. Or a big enough budget to pay for his experiments.
> 
> I think I now quite precisely know what did go wrong with the GTA04A5 but it
> would have cost several 1000€ to run another experiment. And it could have
> failed again.
> 
>> 
>>> Which leads to delay and delay and finally the product is working but
>>> obsolete and only the brave initial sponsors remain. So there is nobody
>>> following up the initial funding round.
>> 
>> Certainly, things have become a lot quieter around the EOMA68 initiative, 
>> and 
>> there are people who have probably lost interest and do not expect to see 
>> anything come out of it.
>> 
>> I have probably made a point about technological projects many times to 
>> anyone 
>> who might listen, reflecting on my own observations and experiences as well 
>> as 
>> what is already common knowledge, that the longer an uncompleted project 
>> takes, the less likely it will be realised.
> 
>> Factors include the finances (as you mention above) plus technological 
>> progress (making a product less attractive over time) and obsolescence 
>> (components becoming unavailable and technologies becoming unsupportable). 
>> Keeping a project short reduces the exposure to such risks.
> 
> Exactly. And that's the big challenge to keep the project duration short and
> to do something very complex. All the projects we're talking about here are
> at the level of the highest industry league, but are run by enthusiasts with
> far too little budget. So we can only admire everyone who takes the challenge
> and still tries to win (contrary to me - everyone is getting older).
> 
> BR,
> Nikolaus
> 
> ___
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Problems seem to repeat...

[H. Nikolaus Schaller]

> Am 07.12.2019 um 13:35 schrieb Paul Boddie :
> 
> On Saturday 7. December 2019 08.37.23 H. Nikolaus Schaller wrote:
>> I just came across:
>> 
>> https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-a->
>>  hypothesis
>> 
>> So they also ran into unexpected solder bridges which must be X-Rayed. This
>> sounds very very familiar to me...
>> 
>> With our experiences collected in the GTA04 project many years ago, I think
>> it is easy to fix - if you have enough money or can borrow money to make
>> some costly experiments with the production line setup.
> 
> I mentioned on the arm-netbook mailing list that similar problems were 
> experienced before, albeit with the RAM chips:
> 
> http://rhombus-tech.net/ingenic/jz4775/news/EOMA68-jz4775_XRay_Photos/
> 
> So, I thought that the manufacturer might have built up some experience since 
> then. From the latest update, it sounds like this is a production process 
> problem, with the prototypes having been made without issues, so I guess that 
> the matter of soldering the chips is not a fundamental problem but just 
> something that needs to be done correctly in the production environment.

Yes, exactly the same issue we had with the GTA04. We knew that Nokia had
built millions of phones incl. the N900 using the OMAP3 + PoP memory but
failed.

Then we got a manufacturer who adapted and learned how to properly produce
them on their line.

Then, OpenPandora switched from omap3530 to dm3730 (like we aready had) and
had only failures. Finally their production line learned how to produce them.

And then we did go to the same production line as the 1GHz OpenPandora
with the GTA04A5 - and they failed. Almost. Well approx. 30% yield which
was too low. We tried to optimize, but the GTA04A5 project did run out of
money.

> 
> (I wouldn't know what the difference between the pre-production and 
> production 
> environments are in this case. There were also some other production-related 
> issues around board-edge component assembly, if I remember correctly.)
> 
>> But borrowing money requires a business model which promises future
>> revenues.
>> 
>> Without money it needs a lot of creativity and time to replace the missing
>> money.
> 
> I think that these experiments rely on a helpful and rather generous factory 
> owner who is looking to gain experience in the processes involved.

Indeed. Or a big enough budget to pay for his experiments.

I think I now quite precisely know what did go wrong with the GTA04A5 but it
would have cost several 1000€ to run another experiment. And it could have
failed again.

> 
>> Which leads to delay and delay and finally the product is working but
>> obsolete and only the brave initial sponsors remain. So there is nobody
>> following up the initial funding round.
> 
> Certainly, things have become a lot quieter around the EOMA68 initiative, and 
> there are people who have probably lost interest and do not expect to see 
> anything come out of it.
> 
> I have probably made a point about technological projects many times to 
> anyone 
> who might listen, reflecting on my own observations and experiences as well 
> as 
> what is already common knowledge, that the longer an uncompleted project 
> takes, the less likely it will be realised.

> Factors include the finances (as you mention above) plus technological 
> progress (making a product less attractive over time) and obsolescence 
> (components becoming unavailable and technologies becoming unsupportable). 
> Keeping a project short reduces the exposure to such risks.

Exactly. And that's the big challenge to keep the project duration short and
to do something very complex. All the projects we're talking about here are
at the level of the highest industry league, but are run by enthusiasts with
far too little budget. So we can only admire everyone who takes the challenge
and still tries to win (contrary to me - everyone is getting older).

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Gta04-owner] Problems seem to repeat...

[H. Nikolaus Schaller]

> Am 07.12.2019 um 12:12 schrieb Andreas Kemnade :
> 
> Hi,
> 
> On Sat, 7 Dec 2019 08:37:23 +0100
> "H. Nikolaus Schaller"  wrote:
> 
>> I just came across:
>> 
>> https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-a-hypothesis
>> 
>> So they also ran into unexpected solder bridges which must be X-Rayed. This
>> sounds very very familiar to me...
>> 
>> With our experiences collected in the GTA04 project many years ago, I think 
>> it
>> is easy to fix - if you have enough money or can borrow money to make some
>> costly experiments with the production line setup.
>> 
>> But borrowing money requires a business model which promises future revenues.
>> 
>> Without money it needs a lot of creativity and time to replace the missing 
>> money.
>> 
> or buy the technically demanding parts ready made and use things like som 
> boards. Today
> the LogicPD torpedo stuff would be interesting to build something like the 
> gta04.
> DM3730 + PMIC.
> But if you have size restrictions things are getting difficult. And probably 
> the product will be more expensive.

Right. The LogicPD is 15 x 27 x 3.8 mm

There was also a DM3730 + PMIC + RAM module from a company called JorJin. I 
think I still
have some samples collecting dust. But it was still too thick for the GTA04 
project
where we only have 2 mm between PCB and battery.

And of course such modules are costly.

But if I would design a new device including case, I'd try such an approach. 
Maybe around
some tiny i.MX8 module or if lower performance suffices, around the OSD3358 SoM.

> 
>> Which leads to delay and delay and finally the product is working but 
>> obsolete
>> and only the brave initial sponsors remain. So there is nobody following up 
>> the
>> initial funding round.
>> 
>> The rule of thumb in consumer electronics is that there must be a successor
>> product (at least an upgraded version) every 1-2 years.
>> 
>> Let's see if Librem 5 can build up a sustainable business (unfortunately I 
>> have
>> difficulties to believe).
>> 
> Yes, interesting question. Same question about PinePhone. 
> The latter one has a lower price at the moment.

Indeed. I didn't mention it since a lower price has a better chance of building 
a
demand - but profitability and therefore being able to sustain, is a completely
different question.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] Problems seem to repeat...

[H. Nikolaus Schaller]

I just came across:

https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-a-hypothesis

So they also ran into unexpected solder bridges which must be X-Rayed. This
sounds very very familiar to me...

With our experiences collected in the GTA04 project many years ago, I think it
is easy to fix - if you have enough money or can borrow money to make some
costly experiments with the production line setup.

But borrowing money requires a business model which promises future revenues.

Without money it needs a lot of creativity and time to replace the missing 
money.

Which leads to delay and delay and finally the product is working but obsolete
and only the brave initial sponsors remain. So there is nobody following up the
initial funding round.

The rule of thumb in consumer electronics is that there must be a successor
product (at least an upgraded version) every 1-2 years.

Let's see if Librem 5 can build up a sustainable business (unfortunately I have
difficulties to believe).

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Letux-kernel] +++ PVR/SGX with LetuxOS Kernel running on GTA04 +++

[H. Nikolaus Schaller]

> Am 23.11.2019 um 09:11 schrieb Andreas Kemnade :
> 
> Hi,
> 
> On Thu, 21 Nov 2019 17:16:11 +0100
> "H. Nikolaus Schaller"  wrote:
> 
>> Hi,
>> I managed to get the latest kernel driver and user-space running on the 
>> GTA04 (with Debian Stretch 9.9).
>> 
>> See Video:   https://youtu.be/DDAEnDMVV3U
>> 
>> and compare: https://www.youtube.com/watch?v=G_QGU6e3eyA
>> 
> congrats, looks nice.

Thanks!

Well, it is several years late [1] but LetuxOS still provides updates :)

> Now the interesting question: Which applications besides typical 3D
> stuff run faster with it.

I would assume that some 3D games run faster.

> And no, I do not want to use SGX to accelerate the replicant 6
> "bootanimation"

:) Although that would also be helpful.

The next big task will be to make it (optionally) work with replicant,
i.e. replicant 6 works without and with SGX installed at user's choice.

AFAIR, I still have to fix the makesd -r replicant stuff before...

BR,
Nikolaus

[1]: http://projects.goldelico.com/p/gta04-kernel/issues/449/
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] +++ PVR/SGX with LetuxOS Kernel running on GTA04 +++

[H. Nikolaus Schaller]

Hi,
I managed to get the latest kernel driver and user-space running on the GTA04 
(with Debian Stretch 9.9).

See Video:  https://youtu.be/DDAEnDMVV3U

and compare:https://www.youtube.com/watch?v=G_QGU6e3eyA

BR,
Nikolaus




___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] 25% speed upgrade for some GTA04!

[H . Nikolaus Schaller]

Hi,
I am happy to announce that we have developed code that
(re)enables the 1GHz clock frequency of the DM3730CBP100
that is installed in ca. 50% of the GTA04 devices.

This allows to get 25% more processing speed since
it currently was limited to 800MHz.

The trick was to define additional "OPP" (operation points)
for DFVS (dynamic frequency and voltage scaling).

It was not available for the DM3730 processor because of
three reasons, where we had to work out solutions:

1. not all DM3730 chips are capable of running at 1GHz.
   Therefore the mainline kernel uses only 800MHz as the
   least common available limit.
   But there is a register inside the DM3730 where Texas
   Instruments has stored if the individual chip can run
   at 1 GHz. So we had to read this bit and disable/enable
   the OPP1G.

2. DM3730 has an internal voltage regulator for the
   "Body Bias" which is called ABB. This must be switched
   to a different mode for 1GHz operation. The driver
   for this regulator was already available, it just
   was not controlled.

3. 1GHz operation may drive the DM3730 very hot. So
   to protect the chip from overheating and being
   damaged, we had to add thermal management. The
   drivers were already available and in place and
   operation for OMAP4 & OMAP5 (Pyra Handheld). So
   we just had to copy and adapt the definitions.
   We now reduce clock rate if the chip reaches 90°C
   Junction Temperature. This usually happens only
   for a short moment (<1 second). And as long as
   you don't run resource intensive software, it
   won't be noticeable.

Our work has now been accepted by kernel maintainers
and appeared in linux-next. It likely will become part
of Linux v5.5. But you do not have to wait since we
already have it in letux-5.3 and letux-5.4-rc.

I hope you enjoy that we still support an 8 years old
device. Where else do you get a speed improvement
of 25% after that time?

Please let the world know about this :)

And of course, dig out your GTA04 and update to the
latest software.

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] magnetic usb plugs

[H. Nikolaus Schaller]

> Am 07.10.2019 um 22:40 schrieb Ларионов Даниил :
> 
> Hello Andreas.
> 
> I had exactly the same need as you a couple months ago and searched high and 
> low, spent a lot of time.
> Looks like such connectors are not produced anymore.
> 
> -- 
> Даниил Ларионов
> 
> 
> 07.10.2019, 23:09, "Andreas Kemnade" :
>> Hi,
>> 
>> there are some magnetic usb plugs on the market now.

Ah, would be interesting. The first ones were the JAB-NAB ca. 10 years ago
but they are no longer available anywhere (I still have one...).

>> I like them as they
>> prevent accidential excess force to the usb socket.
>> But I have not found mini plugs yet. Has anyone seen such things?

Not that I am aware of.

I tried to build some myself (and for our community) by using two PCBs.
One with round contact pads and the other with pogo pins soldered from
the backside, but the main problem is to fix the magnets and make it
mechanically snap to good positions. The JAB-NAB has 4 of them somehow
fixed in the case and N and S on each end in a way that it can snap in
only one position.

But all this is too big for mini or micro USB.

BR,
Nikolaus


___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Letux-kernel] [PATCH 1/3] ARM: dts: add Netronix E60K02 board common file

[H. Nikolaus Schaller]

Hi David,

> Am 29.09.2019 um 23:45 schrieb David Boddie :
> 
> On Fri, 27 Sep 2019 12:49:30 +0200, H. Nikolaus Schaller wrote:
> 
>> We think these type of e-book readers are really nice pieces of hardware
>> to be supported by LetuxOS.
>> 
>> Andreas has bought a Kobo Clara and I have got a Tolino Shine 3 (there are
>> IMHO other brand names as well) assuming they are identical (except
>> branding).
> 
> One place to look for more information is the MobileRead Wiki and forums:
> 
> https://wiki.mobileread.com/wiki/Tolino_Shine
> 
>> It is easy to snap-open the device and replace the ?SD inside so keeping
>> the original system safely and trying other things is easy.
> 
> It's the same with the Kobo Mini I have.

Nice!

> It makes experimenting a much more
> comfortable experience.
> 
> My device had a 4GB micro SD card inside, though I think it might have only
> been rated for 2GB:
> 
> https://www.mobileread.com/forums/showthread.php?p=2737506#post2737506

Yes, there was a change from the SD standards to allow more than 2GB.
Usually this is a combination of higher clock rates and an extension of
the sector addressing scheme. Which means that it is usually possible to
use big cards on a controller that was originally for small cards only.
It is only slower than the card would support.

> I used a break-out board to make it easier to insert and remove the card:
> 
> https://www.mobileread.com/forums/showthread.php?p=2742920#post2742920

The Tolino 3/Kobo Clara has a slightly different SD reader cage where it
is not difficult. At least so far :) I do not know how quickly it wears
out.

> 
>> There is also an RS232 (3.3V level) interface for the console and I have
>> soldered a cable with a connector to it so that I can plug it on demand
>> and connect to an adapter for a FTDI cable.
> 
> I didn't think to try that. I was fortunate that someone else had done the
> work of making a reasonably configured Linux kernel available. I've no idea
> if a more modern kernel would run on the i.MX50-based Kobo Mini.

Why not? AFAIK mainline kernels support the i.MX5 as well. Bigger work may
be to make the u-boot useable... The ones we have found are hacked in a
way that you can only load the original images without pain...

If you want to join our initiative I think there are enough
similarities to add another set of device tree files...

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Letux-kernel] [PATCH 1/3] ARM: dts: add Netronix E60K02 board common file

[H. Nikolaus Schaller]

Hi,
just a little note what is going on here and why LetuxOS is involved.

We think these type of e-book readers are really nice pieces of hardware
to be supported by LetuxOS.

Andreas has bought a Kobo Clara and I have got a Tolino Shine 3 (there are
IMHO other brand names as well) assuming they are identical (except branding).

It is easy to snap-open the device and replace the µSD inside so keeping
the original system safely and trying other things is easy.

There is also an RS232 (3.3V level) interface for the console and I have
soldered a cable with a connector to it so that I can plug it on demand
and connect to an adapter for a FTDI cable.

Unfortunately it turned out that despite exactly the same board designation
there are two options for populating the processors. One is with i.MX6SL
and the other with i.MX6SLL. These are pin-compatible, but not 100%
functionally compatible. And worse, the published u-boot source for the Clara
only supports the i.MX6SLL while the u-boot for the Shine only supports
the i.MX6SL - but does not even work.

Simply taking the i.MX6SLL does boot but the µSD is not readable.
Therefore we have started an u-boot project aiming at building our
own LetuxOS-U-Boot for all the E60K02 board variations:

http://git.goldelico.com/?p=letux-uboot.git;a=shortlog;h=refs/heads/e60k02

Regarding the kernel, Andreas has started to upstream some patches
and I plan start to integrate them with letux-5.4-rc1.

Hope you appreciate and support this efforts.

BR,
Nikolaus 

> Am 27.09.2019 um 08:14 schrieb Andreas Kemnade :
> 
> The Netronix board E60K02 can be found some several Ebook-Readers,
> at least the Kobo Clara HD and the Tolino Shine 3. The board
> is equipped with different SoCs.
> 
> For now the following peripherals are included:
> - LED
> - Power Key
> - Cover (gpio via hall sensor)
> - RC5T619 PMIC (the kernel misses support for rtc and charger
>  subdevices).
> - Backlight via lm3630a
> - Wifi sdio chip detection (mmc-powerseq and stuff)
> 
> It is based on vendor kernel but heavily reworked due to many
> changed bindings.
> 
> Signed-off-by: Andreas Kemnade 
> ---
> backligt dependencies:
> module autoloading:
> https://patchwork.kernel.org/patch/11139987/ 
> enable-gpios property:
> https://patchwork.kernel.org/patch/11143795/
> 
> arch/arm/boot/dts/e60k02.dtsi | 339 ++
> 1 file changed, 339 insertions(+)
> create mode 100644 arch/arm/boot/dts/e60k02.dtsi
> 
> diff --git a/arch/arm/boot/dts/e60k02.dtsi b/arch/arm/boot/dts/e60k02.dtsi
> new file mode 100644
> index ..c4fa8e314e2e
> --- /dev/null
> +++ b/arch/arm/boot/dts/e60k02.dtsi
> @@ -0,0 +1,339 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 Andreas Kemnade
> + * based on works
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + * and
> + * Copyright (C) 2014 Ricoh Electronic Devices Co., Ltd
> + *
> + * Netronix E60K02 board common.
> + * This board is equipped with different SoCs and
> + * found in ebook-readers like the Kobo Clara HD (with i.MX6SLL) and
> + * the Tolino Shine 3 (with i.MX6SL)
> + */
> +
> +/ {
> +
> + memory {
> + reg = <0x8000 0x8000>;
> + };
> +
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + post-power-on-delay-ms = <20>;
> + reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg_sd3_vmmc: wifi_regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "SD3_SPWR";
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> +
> + gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_led>;
> +
> + GLED {
> + gpios = <&gpio5 7 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "timer";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> + power {
> + label = "Power";
> + gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + gpio-key,wakeup;
> + };
> + cover {
> + label = "Cover";
> + gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = <0x05>;/* EV_SW */
> +  

Re: [Tinkerphones] Strategies for sustainable phones

[H. Nikolaus Schaller]

> Am 23.09.2019 um 17:03 schrieb Benson Muite :
> 
> 
> On 9/23/19 5:28 PM, Paul Boddie wrote:
>> On Saturday 21. September 2019 15.48.50 H. Nikolaus Schaller wrote:
>>>> Am 19.09.2019 um 18:18 schrieb Paul Boddie :
>>>> 
>>>> I dislike the tone of technology reviews, especially when they talk of
>>>> "last year's" technology. They start to sound like fashion industry
>>>> gossip ("last season's collection") with largely the same implied level
>>>> of regard for the planet, workers' rights, and so on, unless carefully
>>>> worded and qualified.
>>> Well, if there is no technological breakthrough progress any more (displays,
>>> cameras, processors, RAM sizes etc. do not show significant improvement any
>>> more), the only way vendors can tell they have something new and get
>>> customers to replace devices is by changing the clothing every year - this
>>> is called "fashion". And making them less durable. Seems to be a
>>> fundamental law of economics...
>> But very bad for the planet. As it is, however, people can always be 
>> persuaded
>> to upgrade by just making the software more demanding, so as I noted, we have
>> the same kind of upgrade culture as the one Microsoft and Intel cultivated.
>> 
>> I have tried to get in touch with a researcher I very vaguely know who has
>> done work on sustainable phones, inquiring about considerations of software
>> longevity which were generally absent in the research being done, but I
>> haven't had any response yet. It seems to be a blind spot: people care about
>> how the physical product is made, claiming a long lifespan, but then the
>> software makes the device obsolete.
>> 
>> [...]
> Any thoughts on KaiOS (https://en.wikipedia.org/wiki/KaiOS)?

Interesting. It seems to have similar goals as our QtMoko or my QuantumSTEP, but
we never got investments by Google or a telco operator :)

Key drivers of this project (and I think the same is for Sailfish) are telco
operators who try to stay independent of Google and Android and offer customers
an alternative.

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Strategies for sustainable phones

[H. Nikolaus Schaller]

> Am 23.09.2019 um 16:28 schrieb Paul Boddie :
> 
> On Saturday 21. September 2019 15.48.50 H. Nikolaus Schaller wrote:
>> 
>>> Am 19.09.2019 um 18:18 schrieb Paul Boddie :
>>> 
>>> I dislike the tone of technology reviews, especially when they talk of
>>> "last year's" technology. They start to sound like fashion industry
>>> gossip ("last season's collection") with largely the same implied level
>>> of regard for the planet, workers' rights, and so on, unless carefully
>>> worded and qualified.
>> 
>> Well, if there is no technological breakthrough progress any more (displays,
>> cameras, processors, RAM sizes etc. do not show significant improvement any
>> more), the only way vendors can tell they have something new and get
>> customers to replace devices is by changing the clothing every year - this
>> is called "fashion". And making them less durable. Seems to be a
>> fundamental law of economics...
> 
> But very bad for the planet. As it is, however, people can always be 
> persuaded 
> to upgrade by just making the software more demanding, so as I noted, we have 
> the same kind of upgrade culture as the one Microsoft and Intel cultivated.

Yes, indeed.

The key reason is that if there weren't artificial market demand, there would
not be enough work for everybody on world...

Economy is mainly a machinery that manages money streams (by merging and 
distributing)
between people. Some people can make oscillations in this membrane and this 
means
there is more energy inside.

On the other hand, all this could be seen as a follow-up phenomenon of how
life and mankind developed on earth. So these oscillations occur because of
human behaviour. It is difficult to decide (and currently more a belief) if
this is good or not.

> 
> I have tried to get in touch with a researcher I very vaguely know who has 
> done work on sustainable phones, inquiring about considerations of software 
> longevity which were generally absent in the research being done, but I 
> haven't had any response yet. It seems to be a blind spot: people care about 
> how the physical product is made, claiming a long lifespan, but then the 
> software makes the device obsolete.

Sometimes not only the software on the device, but the software it is 
communicating
with (html3 -> html4 -> html5).

Yes, it would be nice to learn about thoughts of people who do research in this
area. We are just laymen for socio-economics.

> 
> [...]
> 
>>> I wonder, and think that others have also wondered before, whether it
>>> isn't worth concentrating on making more modest devices instead of
>>> supposedly competitive smartphones where openness is the differentiator. I
>>> recall discussions of the Fernvale kit, the Zerophone, and maybe Nikolaus
>>> considered a featurephone design at one point.
>> 
>> Yes, we thought about it - but where are the real users?
>> 
>> There is for example hyped LightPhone2 but I don't see that it is a useful
>> device. Minimizing functions can also go too far.
> 
> The stupid Web site for the LightPhone needs all my computer's CPU and half 
> of 
> its RAM. I guess nobody will be viewing it on a LightPhone2. But I guess this 
> illustrates my point about ever-expanding hardware requirements for mundane 
> things.

Exactly.

> 
> As for that device itself, it takes the interesting but troublesome idea of 
> using e-ink or e-paper displays for something that people might expect to 
> support animated or rapidly updated content. Apart from the use-cases of 
> reading e-books or showing one's boarding pass barcode at the airport 
> security 
> gates, people struggle to consider things that are compelling enough for 
> people to want one (other than the fashion aspect of having something 
> different).

And I understood that they basically replace the colored icon buttons on
touch smartphones with text menus you have to scroll through. The latter
isn't easier to operate IMHO. It requires locally translated versions and
people able to read and understand what the working means...

IMHO the breakthrough of smartphones was that they are much more intuitively
operated than feature-phones with menus and submenus.

> 
>> 
>> The key benefit of a smartphone is its flexibility for everyone. For the
>> user and for the vendor and for app developers. Nobody is basically
>> limited. And it optimizeds the quantities produced for the vendor. It is a
>> win-win-win for everyone and leaving this in either direction must have
>> another win for either of the groups.
> 
> Maybe use of the term "featurephone" isn't app

Re: [Tinkerphones] OT: Banking in Germany (was: Strategies for sustainable phones)

[H. Nikolaus Schaller]

> Am 22.09.2019 um 01:21 schrieb Martin :
> 
> On 2019-09-21 21:33, Xavi Drudis Ferran wrote:
>> El Sat, Sep 21, 2019 at 07:22:22PM +0200, H. Nikolaus Schaller deia:
>>> BTW: this makes me wonder if a TAN generator can be used for tracking
>>> users? Who knows what information it is encoding in the TAN?
>> 
>> No idea, I hadn't heard of TAN before. Sounds like an interesting question.
> 
> Just two laypersons thoughts:
> 
> First, the TAN generator hardware is very simple. It does not
> have any connection to other devices or the internet, other than
> the optical sensor to detect the flicker code on the screen.
> There is no GPS to detect location.
> 
> Second, the TAN itself is very short, not more than six decimal
> numbers. There is not much, one could encode in so few numbers.

Yes, you are probably right.

I can imagine that the process is likely:

bank computer -> flicker(encrypt(random number + TAN + account information + 
transfer data)) -> sent to web browser screen -> optical sensor -> decrypt with 
some secret inside the generator -> display TAN -> user types the number into 
web form -> bank computer compares sent and received TAN

Which means the bank can (and must) already track that you are using the online 
account :)
They already know the IP address of the web browser. They already know your 
bank account number.
So there is no new information for the bank.

What I don't know is how the encrypt/decrypt works. This apparently involves 
some personal information.
Or does the generator read the chip inside your bank card? Then, this chip card 
encapsulates the secret and is unique.

So in total it doesn't seem to be more risky than using the card in some ATM.

But I am not at all a security specialist which is why I raise this question...

> 
>> Pse. Mine is also a cooperative, but now it requires a mobile phone to
>> operate. For many years it was enough with login and password, and for
>> operations moving money, a printed code card (a small One-Time-Pad,
>> which I left at home).  Now they send you a SMS that someone could
>> intercept or someone could use your stolen phone, or force you to use
>> your phone...
> 
> At least, you can receive SMS using an old, non-smart phone (no
> Android/iOS!) or a USB GSM modem, using ofono or modem-manager
> or gammu on a Linux PC. There is a software called sms4you, which
> forwards SMS via email (and XMPP is in the works).

Well, some banks seem to no longer provide TAN (transaction numbers)
neither by paper/card nor SMS. They require to have an App which is
the connection to the original topic.

There will never be FLOSS variants of such software. Unless there were
an open standard for the interfaces.

> 
>> I mean being a cooperative is not immediately a silver bullet (but maybe
>> the rest of banks are even worse). 
> 
> They are probably slightly less evil.

At least they are more responsible towards the member-owners and less to third 
party owners.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] OT: Banking in Germany (was: Strategies for sustainable phones)

[H. Nikolaus Schaller]

> Am 21.09.2019 um 19:14 schrieb Martin :
> 
> On 2019-09-21 15:48, H. Nikolaus Schaller wrote:
>> But the main problem I see (at least here in Germany) is that you can't live
>> without a smartphone with Android or iOS any more, after banks are now 
>> requiring
>> that you have a recent smartphone to run their new online banking apps.
> 
> Note: I live in Germany and do not own a mobile phone. My bank
> uses the so-called "Sm@rt-TAN plus", where one inserts the bank
> card. It reads some flickering code from the screen and displays
> the TAN. It was less than 12 € in the electronics shop nearby.

Well, yes this works of course. But makes me carry along (and not
have with me when needed) another device. With battery that may
be empty in the wrong moment.

And someone may have more than one bank. Each bank seems to have
a different mix between SMS (mTAN) and some App. Some banks require
you to confirm every login to your bank account.

All this is fine with a modern smartphone if you do not care about
free and open :) And if you don't care to be required by your bank
to carry around a TAN generator.

BTW: this makes me wonder if a TAN generator can be used for tracking
users? Who knows what information it is encoding in the TAN?

> 
> (Btw. my bank is a cooperative, which means, I'm the owner.
> Well, one of more than 2¹⁵ owners...)

Which obviously makes them more client-oriented than others.

BR,
Nikolaus


___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] Strategies for sustainable phones

[H. Nikolaus Schaller]

Hi Paul,

> Am 19.09.2019 um 18:18 schrieb Paul Boddie :
> 
> Hello again,
> 
> Recently, having found myself needing to buy a fairly cheap Android 
> smartphone 
> to keep communicating with the rest of the world, I found myself reviewing 
> what the options really were for buying something that would be (amongst 
> other 
> things)...
> 
> 1. Viable for a reasonable amount of time: the featurephone I retired lasted
>   15 years but was wearing out and obviously couldn't do smartphone things.

Durability has become weaker.

But the main problem I see (at least here in Germany) is that you can't live
without a smartphone with Android or iOS any more, after banks are now requiring
that you have a recent smartphone to run their new online banking apps.

Some banks even go so far by contract clauses that you are not allowed to root
the device, have recent one from a renowned brand and have to run the
latest virus scanners...

And all they say is that it is for our security. Well, it is for their 
security...

> 
> 2. Designed not to become obsolete purely because of cynical corporate
>   decisions: for example, having a removable battery instead of something
>   sealed in that may either spontaneously decide that it wants to burst out
>   of the phone or that will eventually fail to hold a decent amount of
>   charge, making the whole device useless.

Well, I rarely had battery problems. If the charging circuit is well designed
batteries can live for quite a long time. For example I have a MacBook Pro with
non-replaceable battery which is model 2013 (i.e. 6 years old), has 780 charging
cycles, good quality and reports a fully charged capacity of 91% of what it had
when I bought. So there is still no need for replacement. Maybe in 6 more years?

> 
> 3. Running Free Software under my control as an end-user.

Definitively!

> 
> Obviously, the phone I ended up getting doesn't fully satisfy (3) even though 
> the manufacturer does provide something claiming to be the source code.

Well, they usually provide source code of something... But sometimes not the 
exact model
you have and you have to find out yourself what these bits are...

> It 
> does satisfy (2), being something of a rarity now. Time will tell how 
> successful it will satisfy (1).
> 
> Being aware of various initiatives, it was therefore interesting to read the 
> following review of Fairphone 3:
> 
> "Fairphone 3 review: the most ethical and repairable phone you can buy"
> https://www.theguardian.com/technology/2019/sep/18/fairphone-3-review-ethical-phone
> 
> I dislike the tone of technology reviews, especially when they talk of "last 
> year's" technology. They start to sound like fashion industry gossip ("last 
> season's collection") with largely the same implied level of regard for the 
> planet, workers' rights, and so on, unless carefully worded and qualified.

Well, if there is no technological breakthrough progress any more (displays,
cameras, processors, RAM sizes etc. do not show significant improvement any
more), the only way vendors can tell they have something new and get customers
to replace devices is by changing the clothing every year - this is called 
"fashion".
And making them less durable. Seems to be a fundamental law of economics...

> Fairphone have clearly refined their process of getting products to market 
> that satisfy their ethical goals, and they appear to be improving with regard 
> to software support, but even with their resources it appears difficult to 
> convince others that their premium (£200 according to the article) is worth 
> paying or that their longevity goals can be realised. Will the phone still be 
> usable in five years?
> 
> Coincidentally, another article approaches this latter problem from a 
> different angle:
> 
> "To decarbonize we must decomputerize: why we need a Luddite revolution"
> https://www.theguardian.com/technology/2019/sep/17/tech-climate-change-luddites-data
> 
> Although it is perhaps not a central observation of the article, one reason 
> why something like the Fairphone might not be usable in five years is down to 
> the ongoing escalation of end-user hardware requirements by software and 
> services. This is rather like the way Microsoft and Intel worked in concert 
> to 
> make people upgrade their computers every few years, but now things like 
> "bloat" in Web and online services are factors, too.
> 
> Making a top-end device can mitigate obsolescence to an extent, but this 
> raises some worthwhile questions about where less well-resourced efforts for 
> making genuinely open phones might be best directed. Smaller initiatives 
> cannot hope to be using the latest chipsets because these are all exclusive 
> things for the largest companies.

It has become even worse than some years ago. Connections between chip producers
and EMS companies have been established now and there is no room for any
smaller initiative. Unless it buys what the EMS has already designed.

> And sadly

[Tinkerphones] GTA04: about the MMCX socket for external GPS antenna...

[H. Nikolaus Schaller]

Hi,
I think I finally understand what the problem is...

Recently I found out that my external GPS antenna with long cable and MMCX plug 
is broken.
I ordered a new one and then I tried to plug it into the GTA04A4.

It didn't go in as smoothly as I was used to and therefore I applied just a 
little more pressure
and ...

... snap, the MMCX socket did disappear inside the GTA04 case.

Now what is the reason?

The MMCX plug has a tiny golden slotted ring which should be pressed together 
when inserting
the plug into the outer ring of the MMCX socket. This ring should then move 
inside the socket
until it snaps in a notch and keeps the plug from falling off by gravity 
applied to the cable.

This is the "lock-snap mechanism" mentioned here: 
https://en.wikipedia.org/wiki/MMCX_connector

Well, making the ring be pressed together and move inwards needs a smaller or 
bigger force
in the insertion direction, i.e. into the GTA04 plastics case.

My old MMCX antenna had a plug where the force apparently was much lower. And 
new one needs
a higher force.

Since the MMCX socket inside the GTA04 is not mounted upwards on the PCB but 
with right angle
(while the one shown on the wikipedia photo is straight), the force is not 
pressing the socket
onto the PCB but parallel to it. With the result of shearing it off.

I have checked with some Amphenol data sheet and they say:

Engagement Force< 30 Newtons
Disengagement Force > 8 Newtons @ 1 - 5 Mating Cycles
> 4 Newtons @ 100 - 500 Mating Cycles

Well, 30 Newtons is like placing a 3kg weight on it... That is quite a lot, 
compared to the
ca. 140g of the GTA04. And explains why the solder joints can be sheared off.

Interesting is that it is expected to wear out after more than 5 cycles which 
is what could
have happened several years ago to my old cable.

A solution would be available in the GTA04A5 where the MMCX socket is a 
through-hole type
(like the Wikipedia photo but with a 90 degrees bend). This withstands much 
higher forces
(maybe > 300 N) than the simple surface mounted soldering of the GTA04A4 SMD 
socket.

So I now have to repair it, which is fortunately trained several times.

Then we have to find out how to make the plug insertion need lower forces...

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] CI20 - was Re: New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Paul,

> Am 05.07.2019 um 18:10 schrieb Paul Boddie :
> 
> On Friday 14. June 2019 11.13.16 H. Nikolaus Schaller wrote:
>> 
>> And it should not be too difficult to find the relevant patches and
>> forward-port them to mainline or simply add the missing LED nodes to the
>> ci20.dts. I'll give it a try in the next days.
> 
> I looked into this with the 5.1.8 kernel. The following configuration 
> settings 
> are required:
> 
> CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_GPIO=y
> CONFIG_LEDS_TRIGGERS=y
> CONFIG_LEDS_TRIGGER_MTD=y
> CONFIG_LEDS_TRIGGER_CPU=y
> 
> With the device tree file, the following from 3.18 seems to be necessary 
> under 
> the / node:
> 
>leds {  
>compatible = "gpio-leds";
>led3 {  
>gpios = <&gpc 0 0>;
>linux,default-trigger = "cpu0";
>};
>led2 {  
>gpios = <&gpc 1 0>;
>linux,default-trigger = "cpu1";
>};
>led1 {
>gpios = <&gpc 2 0>;
>linux,default-trigger = "nand-disk";
>};
>led0 {
>gpios = <&gpc 3 0>;
>linux,default-trigger = "mmc0";
>};
>};
> 
> With this, I can get led3 (cpu0) and led0 (mmc0) working. Maybe led1 (nand-
> disk) works if the NAND flash is accessed, but I don't use it. The led0 
> assignment could have been done as follows:
> 
> sudo sh -c "echo 'mmc0' > /sys/class/leds/led0/trigger"

It seems that I have forgotten to announce that I have added similar patches in 
5.2-rc5 a while
ago to get the LEDs blink - and (untested) Infrared support:


http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/dt-ci20

http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/mips_defconfig

I did not yet backport to letux-4.19.x or letux-5.1.x. It was too low prio on 
my to-do list
to get done.

So I too your mail as a reminder and just have prepared it and it will appear 
with the next
stable release build of LetuxOS kernels. You will get a letux-5.1.17 tree soon.

> 
> Another thing with 5.1.8 is that the second core in the CPU (cpu1) is not 
> active.

Oh really! I think there is no cpufreq-info driver for the jz4780 so I did not 
yet
notice.

> I don't know how that got broken: it's probably the usual breaking up 
> of functionality into morsels that upstream might like, with the rest getting 
> dumped over the side.

This is something to discuss on the mips-creator mailing list.

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] CI20 - was Re: New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Paul,

> Am 12.06.2019 um 23:56 schrieb Paul Boddie :
> 
> On Wednesday 12. June 2019 20.07.35 H. Nikolaus Schaller wrote:
>> 
>> Yes, that is sad, but not the most important issue. It may be even better
>> to have the NAND as a fallback boot option if the SD card becomes broken.
> 
> I personally wonder about the point of NAND, ultimately, at least for this 
> kind of board. If I were designing a board, I'd be tempted to only support 
> removable media given that the onboard flash memory will ultimately 
> deteriorate and be unusable.
> 
> [...]
> 
>>>> What I wonder is where the LEDs (LED0 .. LED3) near the Ethernet
>>>> controller chip DM9000C are connected to... I could not locate them in
>>>> the schematics...
>>> 
>>> Aren't they the MMC indicators?
>> 
>> I have never seen them being active...
> 
> With the 3.1.x kernels there are always some LEDs twinkling when the SD card 
> is being read. I actually thought that they were hard-wired and that any SD 
> card accesses would cause them to twinkle, but I guess that this isn't the 
> case.

I have looked a little around:

here are 4 LEDs with default-triggers:


https://github.com/MIPS/CI20_linux/blob/ci20-v3.18/arch/mips/boot/dts/ci20.dts#L105

They are gpio-LEDs provided by &gpc;

GPC seems to be the gpio-controller of the jz4780 which is already upstream:


https://github.com/MIPS/CI20_linux/blob/ci20-v3.18/arch/mips/boot/dts/jz4780.dtsi#L155

https://elixir.bootlin.com/linux/v5.2-rc4/source/arch/mips/boot/dts/ingenic/jz4780.dtsi#L97

So my theory that it is connected to the ethernet controller is likely wrong...

And it should not be too difficult to find the relevant patches and forward-port
them to mainline or simply add the missing LED nodes to the ci20.dts. I'll give
it a try in the next days.

> 
> [...]
> 
>> I have neither observed reboot problems nor Ethernet not working.
>> 
>> Maybe the DHCP isn't working reliable on your setup. Or the Ethernet gets a
>> random MAC address so that the IP address changes after every reboot. Do the
>> LEDs built into the Ethernet socket blink and show activity?
> 
> Now that I try again it works just fine with the 5.1.8 kernel. So I imagine 
> that I didn't wait long enough previously and was convinced that a lack of 
> LED 
> activity meant that the board had failed to boot, which wasn't the case.

That is a good explanation.

> 
> This is a bit more encouraging, although I obviously haven't tested various 
> other peripherals, but at least the networking functions as it did before.
> 
> Paul

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] CI20 - was Re: New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Paul,

> Am 12.06.2019 um 18:37 schrieb Paul Boddie :
> 
> On Tuesday 11. June 2019 17.38.20 H. Nikolaus Schaller wrote:
>> Hi Paul,
>> also adding the letux kernel mailing list because discussion becomes quite
>> kernel focussed...
> 
> OK, maybe my message will bounce, though, because I am not subscribed to that 
> list.

Seems to have worked :)

http://lists.goldelico.com/pipermail/letux-kernel/2019-June/003594.html

> 
> [...]
> 
>> I have just booted sucessfully the letux-5.2-rc4 kernel. Log is attached.
>> It seems to ignore NAND completely.
> 
> Yes, support for the specific kind of NAND on the CI20 was dropped in the 
> mainline kernel because it is the "wrong" type, or something. There was 
> argument about it being unreliable and no-one being able to know when it 
> fails, or something like that, so the kernel developers just pushed it over 
> the side. Obviously, this came as a surprise to anyone thinking they could 
> upgrade their kernel and expect everything to keep working.

Yes, that is sad, but not the most important issue. It may be even better
to have the NAND as a fallback boot option if the SD card becomes broken.

> Anyway, I tried booting the 5.1.8 kernel (from upstream) attached to the 
> serial cable and it did actually boot in the end. I don't get any logging to 
> UART0 despite changing the device tree file and doing "make uImage" but maybe 
> that isn't sufficient. Also, I couldn't figure out how to make systemd start 
> a 
> terminal over UART0 (/dev/tty0), which was easily done using /etc/inittab 
> before some people decided they knew better about how things should be set up.
> 
> So, I ended up investigating using the UART4 connector which is unreliable 
> mechanically for those of us using female header connectors.

I have looked around for a pre-crimped 4-pin JST-XH socket with cable ends and
did find one as "3s battery balancer cable". There are other offers of course.

It is also easy to find JST-XH sets with the plastic parts and the connector
pins, but it needs a special crimping tool to build a cable that can't easily
be pulled out.

And I soldered the 3 significant wires to a normal 6-pin 2.54mm header which I
can directly connect to a FTDI adaper.

> 
>> The only problem seems to be "spidev@0 enforce active low on chipselect
>> handle" which indicates a missing DT property.
>> 
>> What I wonder is where the LEDs (LED0 .. LED3) near the Ethernet controller
>> chip DM9000C are connected to... I could not locate them in the
>> schematics...
> 
> Aren't they the MMC indicators?

I have never seen them being active...

> 
>> It mentions only the RED/BLUE D5 and two wires LED1 and LED2 going from
>> DM9000C to the RJ45 socket which has the two Ethernet status LEDs.
>> 
>> It is likely that they go to some SD8..SD15 of the DM9000C but it seems that
>> the schematics do not exactly match my (pink CI20 V2a) board. But I also
>> could not locate an LED or GPIO controller driver for the DM9000C... So
>> there is no easy way to get them blinking (heartbeat, cpu, mmc activity).
> 
> So it seems that the LEDs are a general problem given that they do not 
> indicate MMC activity and made me think that the board hadn't booted.

Therefore it would be nice if we could make them work and set the 
default-triggers
in device tree to CPU activity, heartbeat and MMC activity.

> Since I  don't have the board connected with a serial cable and Ethernet at 
> the same 
> time, I don't know whether the networking actually works, but ifconfig does 
> seem to show eth0 set up, albeit without an address.
> 
> Maybe I will try and let the board boot on the network again and just wait 
> for 
> it to appear or not appear.

I have neither observed reboot problems nor Ethernet not working.

Maybe the DHCP isn't working reliable on your setup. Or the Ethernet gets a
random MAC address so that the IP address changes after every reboot. Do the
LEDs built into the Ethernet socket blink and show activity?

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] CI20 - was Re: New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Paul,
also adding the letux kernel mailing list because discussion becomes quite 
kernel focussed...

> Am 11.06.2019 um 15:38 schrieb Paul Boddie :
> 
> On Tuesday 11. June 2019 14.54.36 H. Nikolaus Schaller wrote:
>> 
>> Maybe you could also try the letux tree. The idea of the letux tree is that
>> we can collaborate on it and contribute good things to kernel.org if we are
>> successful.
> 
> I'll put the CI20 to work on it as soon as it is finished building a 
> Raspberry 
> Pi Zero toolchain that maybe will work this time.
> 
> Since my hardware tends not to withstand the weight of these repositories 
> under Git management, I will download the snapshot of the tree from the 
> appropriate page:
> 
> http://git.goldelico.com/?p=letux-kernel.git;a=snapshot;h=refs/heads/letux-5.1.8;sf=tgz

I have just booted sucessfully the letux-5.2-rc4 kernel. Log is attached.
It seems to ignore NAND completely.

The only problem seems to be "spidev@0 enforce active low on chipselect handle"
which indicates a missing DT property.

What I wonder is where the LEDs (LED0 .. LED3) near the Ethernet controller chip
DM9000C are connected to... I could not locate them in the schematics...

It mentions only the RED/BLUE D5 and two wires LED1 and LED2 going from DM9000C
to the RJ45 socket which has the two Ethernet status LEDs.

It is likely that they go to some SD8..SD15 of the DM9000C but it seems that the
schematics do not exactly match my (pink CI20 V2a) board. But I also could not
locate an LED or GPIO controller driver for the DM9000C... So there is no easy
way to get them blinking (heartbeat, cpu, mmc activity).

BR,
Nikolaus

--

U-Boot 2013.10-rc3-00096-gef995a1-dirty (Apr 13 2019 - 19:15:18)

Board: ci20 (r2) (Ingenic XBurst JZ4780 SoC)
DRAM:  1 GiB
NAND:  8192 MiB
MMC:   jz_mmc msc1: 0
*** Warning - bad CRC, using default environment

In:eserial4
Out:   eserial4
Err:   eserial4
Net:   dm9000
Hit any key to stop autoboot:  0 
4818644 bytes read in 792 ms (5.8 MiB/s)
## Booting kernel from Legacy Image at 8800 ...
   Image Name:   Linux-5.2.0-rc4-letux-l400+
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:4818580 Bytes = 4.6 MiB
   Load Address: 8001
   Entry Point:  80755700
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

[0.00] printk: debug: ignoring loglevel setting.
[0.00] User-defined physical RAM map:
[0.00]  memory: 1000 @  (usable)
[0.00]  memory: 3000 @ 3000 (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] cma: Reserved 32 MiB at 0x0100
[0.00] Primary instruction cache 32kB, VIPT, 8-way, linesize 32 bytes.
[0.00] Primary data cache 32kB, 8-way, VIPT, no aliases, linesize 32 
bytes
[0.00] MIPS secondary cache 256kB, 8-way, linesize 128 bytes.
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x1fff]
[0.00]   HighMem  [mem 0x2000-0x5fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x0fff]
[0.00]   node   0: [mem 0x3000-0x5fff]
[0.00] Initmem setup node 0 [mem 0x-0x5fff]
[0.00] On node 0 totalpages: 262144
[0.00]   Normal zone: 1152 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65536 pages, LIFO batch:15
[0.00]   HighMem zone: 196608 pages, LIFO batch:63
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260992
[0.00] Kernel command line: console=ttyS4,115200 console=tty0 
mem=256M@0x0 mem=768M@0x3000 rootwait quiet rw root=/dev/mmcblk0p1 
dm9000.mac_addr=d0:31:10:ff:6e:86 earlycon console=ttyS4,115200 
clk_ignore_unused ignore_loglevel
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 990856K/1048576K available (7479K kernel code, 585K 
rwdata, 2204K rodata, 412K init, 166K bss, 24952K reserved, 32768K 
cma-reserved, 786432K highmem)
[0.00] rcu: Preemptible hierarchical RCU implementation.
[0.00]  Tasks RCU enabled.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
[0.00] NR_IRQS: 222
[0.00] random: get_random_bytes called from start_kernel+0x3a8/0x5ec 
with crng_init=0
[0.00] clocksource: jz4740-timer: mask: 0x max_cycles: 0x, 
max_idle_ns: 9721025 ns
[0.00] sched_clock: 16 bits at 3000kHz, resolution 333ns, wraps every 
10922500ns
[0.000321] Console: colour dummy device

Re: [Tinkerphones] CI20 - was Re: New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

> Am 11.06.2019 um 10:52 schrieb Paul Boddie :
> 
> On Tuesday 11. June 2019 08.14.49 H.  Nikolaus Schaller wrote:
>> 
>>> Am 09.06.2019 um 18:01 schrieb Paul Boddie :
>>> 
>>> Ignoring the investigations into configuration and deployment tools, I did
>>> manage to compile an upstream kernel for the CI20 today. Choosing the
>>> 5.1.8 kernel, on the CI20 itself, I did the usual...
>>> 
>>> make ci20_defconfig
>>> make
>>> make uImage
>>> 
>>> Installing the uImage to /boot and rebooting actually worked without any
>>> problems.
>> 
>> Great!
> 
> Actually, I rather spoke too soon. Rebooting succeeded, but a later cold boot 
> failed: the device didn't start flashing its activity LEDs and wasn't 
> reachable over the network.
> 
> Maybe there are some things that don't work in the upstream kernel that don't 
> affect a reboot, or maybe systemd does some "helpful" things to simulate a 
> reboot that I didn't know about. (It's always worthwhile to speculate about 
> systemd and other "opinionated" software doing "helpful" stuff.)

Indeed... This is one of the reasons why I still mainly use Jessie with the
letux-system-d ("system minus d") package...

> 
>> You could also try the latest
>> 
>> http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-5
>> .1.8
>> 
>> with letux_defconfig.
>> 
>> The main differences are
>> * adds your JZ4730 code (but does not make use it, obviously)
>> * some diffs in the defconfig
>> * prepared to build pvrsrv.ko
>> 
>>> I was able to ssh into the CI20 and find it over the network again!
>> 
>> Yes, Ethernet and ssh seems to work.
> 
> I do actually wonder if there isn't some very basic initialisation that does 
> not work. Maybe it is related to the flash memory issues described on the 
> ci20(-dev) mailing lists.

I think, on my system it reports some non-recoverable errors during boot. While
it can boot from NAND using the old kernel stored in NAND.

> So perhaps I will start the kernel with the UART 
> cable attached and see what is reported.

Yes, this may be more enlighting than guessing :)

> 
> [...]
> 
>> What I have observed that it is not working:
>> * USB
>> * HDMI
>> * Camera
>> * PVR/SGX (obviously)
>> * untested: Audio
>> * untested: Infrared (?). LED0..3, SW1
>> * untested: Wireless
>> 
>> Does any of these work for you?
> 
> I'll have to investigate. I also looked at Mathieu's separate linux-ci20 
> repository, but the tip of that didn't manage to build, complaining about 
> rules to make various clock-related files.

Maybe it is work in progress or has some dependencies.

Maybe you could also try the letux tree. The idea of the letux tree is that
we can collaborate on it and contribute good things to kernel.org if we are
successful.

The main benefit I see in using the letux tree is that we support several
almost identically configured ARM boards for comparisons. So you can easily
find out if it is configuration or driver code or device tree or user-space
or specific to some SoC model.

This makes doing cross-checks between them much easier than trying different
trees you find in github etc.

And my dream is to have a single patch set for PVR/SGX for ARM and MIPS
which is only in reach within this managed jacket of letuxos kernel and same
tree and config options.

BR and thanks,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] CI20 - was Re: New LetuxOS Kernels and some tricks and thoughts

[H . Nikolaus Schaller]

Hi Paul,

> Am 09.06.2019 um 18:01 schrieb Paul Boddie :
> 
> On Tuesday 21. May 2019 14.12.22 Paul Boddie wrote:
>> On Tuesday 21. May 2019 10.22.50 H. Nikolaus Schaller wrote:
>>> What else is going on in the LetuxOS eco-system?
>>> 
>>> We now support MIPS devices, not only ARM. Well one. The Imagination CI20
>>> board. Just do "makesd ci20" to get a first SD card.
>> 
>> I'll have to stop procrastinating and try this now. Well done for getting to
>> the bottom of the kernel configuration problems, too!
> 
> Ignoring the investigations into configuration and deployment tools, I did 
> manage to compile an upstream kernel for the CI20 today. Choosing the 5.1.8 
> kernel, on the CI20 itself, I did the usual...
> 
> make ci20_defconfig
> make
> make uImage
> 
> Installing the uImage to /boot and rebooting actually worked without any 
> problems.

Great!

You could also try the latest

http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-5.1.8

with letux_defconfig.

The main differences are
* adds your JZ4730 code (but does not make use it, obviously)
* some diffs in the defconfig
* prepared to build pvrsrv.ko

> I was able to ssh into the CI20 and find it over the network again! 

Yes, Ethernet and ssh seems to work.

> So, thanks to the hard work done by Mathieu and others, this went 
> surprisingly 
> well.
> 
> Paul

What I have observed that it is not working:
* USB
* HDMI
* Camera
* PVR/SGX (obviously)
* untested: Audio
* untested: Infrared (?). LED0..3, SW1
* untested: Wireless

Does any of these work for you?

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi,
just a small update

> Am 21.05.2019 um 10:22 schrieb H. Nikolaus Schaller :
> 
> Hi,
> there are new LetuxOS kernels:
> 
>   letux-5.2-rc1

we now have letux-5.2-rc3 ...

>   letux-5.1.3
>   letux-5.0.17
>   letux-4.19.44
>   letux-4.14.120 

... and merged upstream here ...

> 
> Please see:
> 
>   projects.goldelico.com/p/gta04-kernel/
> 
> Unfortunately display drivers in letux-5.2-rc1 for almost all devices are 
> broken. So please either help
> to fix the issues or wait for a later -rc.

... and all panel drivers seem to be fixed now.

It was very different:

GTA04/L2804: the spi-cs-high legacy handler was broken again
L3704 & L7004: the panel driver had to be replaced by the generic panel-simple
Pyra: it was not the display driver but a bug in the pca953x gpio expander 
which wasn't programmed any more

There is still a minor issue with the PWM backlight for the combination of 
BeagleBoard Black + 4.3 inch panel
cape. It does not work for 4.19 but for 5.0 and later.

> 
> BR and happy tinkering,

same again :)
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] makesd (was Re: [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts)

[H. Nikolaus Schaller]

Hi Paul,

> Am 28.05.2019 um 13:20 schrieb Paul Boddie :
> 
> On Monday 27. May 2019 20.46.32 H. Nikolaus Schaller wrote:
>> 
>> The pre-built images are just the result of a complete debootstrap in a
>> fresh chroot on some ARM or MIPS SBC. Either bare bone with some minimal
>> set of required or generally useful packages or with some more, e.g. a full
>> GUI like Xfce or QtMoko.
> 
> Right. So they are already fully configured.

Yes.

> This is the challenge when cross-
> bootstrapping, and with the CI20 they recommend using qemu for the second 
> stage:

I had experimented with qemu some years ago in the hope to make things
easier but it was a dead end... The solution was to use the Letux Cortex 8
(basically the same as a PocketBeagle) for <50€ and power and connect through
an USB cable to the Goldelico server. Some shell scripts can remote control
the debootstrap process and copy results from the SBC to the web-server's
file system. The Letux Cortex 8 also runs a copy of Letux OS for that purpose
on a 200GB µSD card (another 50€) so that it has a lot of space for all these
debootstrapped images...

This concept is running smoothly for ca. 3 years now.

Now, I have a LetuxOS image for the CI20 and can just do the same. Maybe
over Ethernet because USB/OTG seems to not yet be available with upstream
kernels. But the concept is exactly the same. I do not even have to modify
my remote control scripts significantly (just telling them to debootstrap
MIPSEL and use a different IP address).

> https://www.elinux.org/How_to_make_a_debian_rootfs_for_MIPS_CI20
> 
> I never got that to work, and given that a lot of the package configuration 
> should be machine-independent (it shouldn't need to see specific hardware), I 
> would rather see some kind of generic configuration getting done, leaving 
> only 
> a small amount of machine-specific stuff, if any, to the actual hardware 
> itself.

> 
> (Emulation is just a hack because there isn't a nice way of running host 
> programs to do the configuration work within the target environment. So one 
> ends up running emulated binaries that do the same things as host binaries, 
> discarding the portability and interoperability benefits of having a set of 
> programs that behave the same way and can act on filesystems and other things 
> regardless of the system architecture.)
> 
> So, I decided to use my own tool to make a root filesystem instead:
> 
> https://hg.boddie.org.uk/qi-emdebian
> 
> This runs the second stage on the CI20 itself.

Well, I can run first and second on CI20... By eliminating the 
cross-debootstrapping
step.

> 
>> Configuration of the LetuxOS is now completely done by some
>> letux-something.deb packages. So no single file is touched (well, there is
>> some fallback at the moment that should be eliminated soon) besides through
>> installing a .deb package. So it can also be removed or replaced (there are
>> usually preinst and postrm scripts to make backups). The same for the
>> kernel package.
> 
> This part starts to sound a bit like Jonas's Boxer tool and its objectives.

Yes, a little.

But I think the task here is much simpler and a set of .deb packages just does
what is needed. IMHO RaspBian has invented the same concept independently. It is
not intended to become a swiss army knife tool like I interpret Boxer.

Here, the task is to make SD cards boot an fill with a useful rootfs...
There is no dependency on what hardware is used (which is sometimes not easy).
And almost no dependency on the GUI. Basically most packages are meta-packages
just listing which useful standard Debian packages are to be installed. A 
slightly
complicated thing is that not all packages have the same name in wheezy, jessie,
stretch, buster etc. or do not exist in all architectures (e.g. x11 for omap3).

So the main task of that is not to invent a new tool but just avoid having
someone type a list of parameters for apt-get install after first boot and
setting up a network access. Keep it simple is the idea...

> 
> [remakesd]
> 
>> Yes, I noticed that you are trying to make it a little more object-oriented
>> by this approach, especially in the aspect of modularization and
>> encapsulation of implementations.
>> 
>> Unfortunately the bash isn't the best OO language :)
> 
> If I were really going for object orientation, I would probably use Python 
> instead.

Indeed.

> 
> I did think a bit more about the formulation of systems in makesd yesterday, 
> trying to understand how some of the options work, and it occurred to me that 
> if I were describing the partitioning scheme

That is an assumption which makesd tries to avoid. A user might not even need
to know that a specific board needs two partitions and anothe

Re: [Tinkerphones] makesd (was Re: [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts)

[H. Nikolaus Schaller]

> Am 27.05.2019 um 19:55 schrieb Paul Boddie :
> 
> On Monday 27. May 2019 16.28.15 H. Nikolaus Schaller wrote:
>> 
>> Exactly. It is coming not from theory but practice and has evolved over
>> the years into a simple workhorse. Features were added where needed
>> and over the years some of the underlaying tools had changed.
>> 
>> So it basically is a macro processor which allows to describe how to
>> partition and fill an SD card with a bootable system for the most
>> common bootable SD card schemes we find for OMAP, i.MX, Broadcom processors.
> 
> I thought that the macro concept was a good one, allowing systems to be 
> derived from others and for different concerns to be mixed.
> 
>> It also knows abbreviations for many components for the SD card so that
>> nobody has to type http: links or run gunzip manually.
>> 
>> Key principle is: people need a useful SD card for first boot of a naked
>> device which may not have any external interfaces. So you can't bootstrap
>> in on the device itself.
> 
> I see that pre-built filesystems are downloaded, and I guess that they are 
> preconfigured. In my own efforts, I have tended to perform a debootstrap (or 
> equivalent) and then had the device perform the second stage itself, which 
> worked surprisingly well.

The pre-built images are just the result of a complete debootstrap in a fresh
chroot on some ARM or MIPS SBC. Either bare bone with some minimal set of 
required
or generally useful packages or with some more, e.g. a full GUI like Xfce or
QtMoko.

Configuration of the LetuxOS is now completely done by some letux-something.deb
packages. So no single file is touched (well, there is some fallback at the 
moment
that should be eliminated soon) besides through installing a .deb package. So
it can also be removed or replaced (there are usually preinst and postrm scripts
to make backups). The same for the kernel package.

It is also possible to take one of the preconfigured packages to boot a board
and then debootstrap something else on the initially running system. That can
be stored on some network server and the download link passed to makesd.

Even the SD card we use for the ARM or MIPS SBCs to debootstrap the images are
created by makesd... If such a card or SBC fails, we simply makesd a new one
from a stable version.

With this concept it did only need some initial and manual cross-debootstrap
and manual config (e.g. /etc/fstab) ca. 10 years ago to pull it up to where it
is now :)

> 
>> Most SBC vendors provide some .dd or .tgz files for this purpose which
>> need to be manually fetched, extracted and copied to the raw SD card.
>> In most cases the SD card size is fixed (e.g. 1GB) even if your destination
>> card is bigger. And for every board there is a different download location,
>> download and installation procedure - and finally every board has a
>> different password, different preinstalled packages, different kernel
>> version etc.
> 
> Yes, this kind of thing can be a mess, with mostly the same things being done 
> slightly differently every time.
> 
>> This is what makesd (and LetuxOS) wants to get rid of. Have a single OS
>> that runs everywhere (almost) the same. Like macOS or iOS or Windows can
>> be installed on any current hardware without need for "configuration".
> 
> Or GNU/Linux on Intel-based systems.

Yes. They are fortunately homogenous enough so that it is much easier to
achieve.

> 
>>> https://hg.boddie.org.uk/remakesd
>> 
>> I have looked into it but did not get the feeling that it is easier to
>> maintain than a single script file which is broken up into shell functions.
>> With multiple files, you have to open them separately to get the overall
>> structure. Maybe that depends on the source code editor you have...
> 
> I just use vim. :-) But it is something I try and do with shell scripts: to 
> separate out each of the different tasks and to formalise some interfaces 
> between them.
> 
> Typically, I am very cautious about big scripts that are downloaded and run, 
> particularly if they need to acquire elevated privileges. Separating things 
> into separate scripts allows the parts which need elevated privileges to be 
> confined, leaving the other parts to do their things under normal privileges.
> 
> Another thing that I wanted to explore was the macro expansion. By having a 
> separate script just concerned with that, it becomes possible to ask that 
> script to summarise its understanding of the board definition or macro given 
> to it. For example:
> 
> ./makesd-expand-def lc8
> 
> -f fat -s 5 -b Letux-Cortex-8/latest -k latest -d latest -f ext4 ...
> 
> And these arguments can be presented to anot

Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Paul,

> Am 27.05.2019 um 12:33 schrieb Paul Boddie :
> 
> On Tuesday 21. May 2019 23.29.43 Paul Boddie wrote:
>> 
>> I can't judge what is conservative or not, but the first thing I thought of
>> was this:
>> 
>> https://wiki.debian.org/vmdebootstrap
> 
> It appears that it now has a successor:
> 
> http://git.liw.fi/vmdb2
> 
>> And, of course, it is deprecated. Good thing I never paid it any attention
>> when people were talking it up! More here:
>> 
>> https://wiki.debian.org/SystemBuildTools
> 
> So, in the context of the makesd script...
> 
> http://projects.goldelico.com/p/gta04-makesd/
> 
> ...I had a look at what kind of tools might also do the same job. The tasks 
> makesd appears to do are as follows:
> 
> * Downloads pre-built bootloader, device tree, kernel, modules, root
>   filesystems
> 
> * Partitions a disk according to device expectations
> 
> * Formats filesystems
> 
> * Unpacks or copies the different payloads into their destinations

Exactly. It is coming not from theory but practice and has evolved over
the years into a simple workhorse. Features were added where needed
and over the years some of the underlaying tools had changed.

So it basically is a macro processor which allows to describe how to
partition and fill an SD card with a bootable system for the most
common bootable SD card schemes we find for OMAP, i.MX, Broadcom processors.

It also knows abbreviations for many components for the SD card so that
nobody has to type http: links or run gunzip manually.

Key principle is: people need a useful SD card for first boot of a naked
device which may not have any external interfaces. So you can't bootstrap
in on the device itself.

Most SBC vendors provide some .dd or .tgz files for this purpose which
need to be manually fetched, extracted and copied to the raw SD card.
In most cases the SD card size is fixed (e.g. 1GB) even if your destination
card is bigger. And for every board there is a different download location,
download and installation procedure - and finally every board has a different
password, different preinstalled packages, different kernel version etc.

This is what makesd (and LetuxOS) wants to get rid of. Have a single OS
that runs everywhere (almost) the same. Like macOS or iOS or Windows can
be installed on any current hardware without need for "configuration".

> 
> Not wanting to spend weeks looking at this, I briefly looked at the following:
> 
> ELBE - https://elbe-rfs.org/docs/sphinx/article-elbeoverview-en.html
> 
> Seems very powerful, but is also rather heavy, needs to use virtual machine 
> technology, has a verbose XML configuration language.
> 
> isar - https://github.com/ilbers/isar
> 
> Seems to be oriented towards building root filesystems, delegates image 
> generation and other such tasks to other tools, needs qemu.
> 
> FAI - https://fai-project.org/
> 
> Seems powerful for its intended use but overkill and maybe not even 
> completely 
> appropriate for the more modest goals being considered here. Also needs qemu.
> 
> Boxer - https://wiki.debian.org/Boxer
> 
> Since Jonas is the author and maintainer of the software and Debian package, 
> he can correct me on my impressions. This appears to be a framework for 
> performing system configuration tasks, maybe even deployment, but the Debian 
> source package doesn't seem to contain much of immediate use (at least to my 
> eyes).
> 
> Meanwhile, I took a closer look at makesd itself. It seems like a very 
> capable 
> script but is also rather complicated. Out of curiosity, I wanted to see if I 
> could break it up into smaller pieces that are easier to inspect and 
> maintain. 
> Consequently, I ended up rewriting functionality, investigating some awkward 
> issues with sfdisk, and generally spending more time on doing all of this 
> than 
> is perhaps worthwhile.
> 
> Still, my ongoing efforts can be found here:
> 
> https://hg.boddie.org.uk/remakesd

I have looked into it but did not get the feeling that it is easier to maintain
than a single script file which is broken up into shell functions. With multiple
files, you have to open them separately to get the overall structure. Maybe that
depends on the source code editor you have...

Makesd just defines a set of shell functions and then runs through the main
code in a predetermined sequence (parse arguments, setup partitions, format
the partitions, extract files into the partitions, fsck and umount everything).

So it is just an SD card baking recipe with some common subroutines.

And it is tied closely to a server infrastructure which provides the files
to be installed at certain well known locations.

BTW: maintaining makesd is a recreational walk compared to maintaining kernel
drivers that are not upstream and where others break in-kernel APIs without
documentations besides the code or similar drivers...

> Eventually, I will get round to looking at more substantial things, of course.

The key question I have is what you think is missing 

Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Jonas,
one more thought on this with some distance in time.

> Am 21.05.2019 um 15:13 schrieb Jonas Smedegaard :
> 
>>> My point is that that I firmly believe that to get out of the 
>>> vicious circle we _first_ need to collaborate and only _then_ 
>>> compete (if needed at all, but that's a different discussion).
>> 
>> Well, I am waiting for years for collaboration (the first LetuxOS 
>> dates back to 2006) but it seems as if other projects decided to 
>> compete and start from scratch instead of building on top of LetuxOS
>> :)
> 
> Yes, just as Debian had waited for years for your collaboration (first 
> release dates back to 1993) but you decided to compete with LetuxOS 
> instead of joining and improving Debian :-)

The main contribution of LetuxOS since 2006 is to advocate using Debian
on embedded boards. At that time everyone was using Angstrom. We used
Debian right from the beginning. And LetuxOS is (still) making Debian
more available and better useable on some set of devices by adding a
handful packages and compatible kernels. IMHO this *is* collaboration
and not competition.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

> Am 21.05.2019 um 18:33 schrieb Paul Boddie :
> 
> On Tuesday 21. May 2019 15.48.06 H. Nikolaus Schaller wrote:
>>> Am 21.05.2019 um 15:13 schrieb Jonas Smedegaard :
>>> 
>>> Speaking for myself, I got discouraged when we met in Bavaria and it
>>> became clear to me that your avoiding OSHW certification was a
>>> deliberate business choice.
>> 
>> No it was not about avoiding it. It was about not seeing any benefit
>> for anyone.
>> 
>> Just more paperwork and discussions. And some requirements that are
>> difficult to fulfill. And nobody covering additional expenses.
> 
> Personally, I am increasingly skeptical about associations that collect 
> membership dues and merely do advocacy with a bit of extra lobbying on the 
> side. It seems like a great way of siphoning money away from the actual work, 
> albeit one that some corporations might like due to questionable tax 
> arrangements.
> 
> Confirming that someone happens to license their work in a particular way 
> might provide some benefit to end-users, but if that isn't a continual 
> process 
> then it is just easy money for some persuasive branding. I also remain 
> concerned about the effect of certification on the perception of works that 
> are genuinely licensed appropriately.
> 
> No-one should act as a monopoly who gets to decide whether works or projects 
> are merely perceived as being acceptably licensed, casting doubt on those who 
> do not wish to be certified by some self-appointed authority. The FSF might 
> have an authoritative view on whether some software actually complies with 
> the 
> GPL, but they don't implicitly undermine random GPL-licensed projects on the 
> basis that those projects failed to sign up for some FSF money-making scheme.
> 
>> My key learning came from a discussion before that meeting where some guys
>> urged me to publish the schematics. I did finally say: ok - here are the
>> EAGLE source files. What happened? NOTHING. Nobody did apparently
>> make use of this information. The device did not become better. Nobody
>> had needed this for writing software - a PDF of the schematics was
>> sufficient.
> 
> The only argument I can make excusing those asking for the schematics (or 
> even 
> the layouts) was that Eagle is proprietary software.

Yes, it is but the file format is openly and really well documented (contrary
to KiCAD - I have only found outdated documentation). It is XML and the DTD is
available.

And KiCAD and others can import this format. So that the Tool to originally
generate the file is proprietary should not be any issue.

It is more or less the same that someone can write a document in MS Word 
(proprietary),
publish it under an open source license and everyone can still edit through 
LibreOffice.

> There has been a 
> discussion about such topics on another list I follow recently, involving 
> software that is also presumably expensive as well as proprietary.
> 
> But then again, I feel that there are people out there who just want to "tick 
> the box" and feel good about the hardware being "open source". I believe that 
> such people do not appreciate the investment involved in getting to a point 
> where the hardware can be made. Something similar might also be said about 
> how 
> people perceive software, thinking that "open source" means lots of free-from-
> cost stuff that magically gets made, too.
> 
> I recall Nikolaus getting quite a bit of hassle from people who demanded full 
> access to the materials around projects like GTA04. I wonder if those people 
> are currently pursuing projects in a way that is consistent with the demands 
> they made of Nikolaus (and others) back then.

Yes, I wonder too...

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

> Am 21.05.2019 um 15:13 schrieb Jonas Smedegaard :
> 
> Quoting H. Nikolaus Schaller (2019-05-21 12:51:43)
>> Hi Jonas,
>> 
>>> Am 21.05.2019 um 12:26 schrieb Jonas Smedegaard :
>>> 
>>> Quoting H. Nikolaus Schaller (2019-05-21 12:02:06)
>>>> Hi Jonas,
>>>> 
>>>>> Am 21.05.2019 um 11:00 schrieb Jonas Smedegaard :
>>>>> 
>>>>> First of all, congratulations with the progress!
>>>> 
>>>> Thanks!
>>>> 
>>>>> 
>>>>> 
>>>>> Quoting H. Nikolaus Schaller (2019-05-21 10:22:50)
>>>>>> BTW, here is another trick: You may (not) know that LetuxOS 
>>>>>> images created by makesd come rooted. This means you can simply 
>>>>>> ssh as root into the device without password check. This is quite 
>>>>>> helpful for developers and debugging.
>>>>> 
>>>>> A password-less network-accesible backdoor maybe unknown to the 
>>>>> system owner sounds dangerous to me: I recommend documenting that 
>>>>> very clearly (at least) everywhere passwords are currently 
>>>>> menioned in documentation.
>>>> 
>>>> Yes, please feel free to document it in the Wiki.
>>> 
>>> Is the wiki the only place passwords are mentioned?  There are no 
>>> other places users could be helped get notified about this open 
>>> access? users
>> 
>> I have no idea about what users do... We need users to see the missing 
>> information and add it themselves. So we just must enable them to do 
>> it. Which is the Wiki.
> 
> Makes sense that users document what they do.
> 
> Makes sense that developers document what they do.
> 
> You really expect users to understand and document backdoors better than 
> the developers implementing them?!?

No. But I am the developer and in this case you are the user - and you
have a better understanding where this should be documented.

> 
> 
>>> Suggestion: Add a notice in /etc/motd
>> 
>> Hm. Do your ever read/see that?
> 
> Why on Earth would I suggest it otherwise?

Ok, accepted. My fault. I assumed that because I am not using that that
it is rare that others use it.

On the other hand in LetuxOS it is not enabled. And not displayed anywhere.

> 
> 
>>>>>> On a very general view, we have achieved a lot, but still not 
>>>>>> enough to get the LetuxOS eco-system into a self-sustaining mode. 
>>>>>> What is lacking?
>>>>>> 
>>>>>> * users are missing because software is not good enough for daily 
>>>>>> use
>>>>>> * hardware is missing because potential users complain about 
>>>>>> missing high-quality software
>>>>>> * developers to polish the software are missing, because of missing 
>>>>>> (new) hardware
>>>>>> 
>>>>>> You see the vicious circle? Ideas how to magically break it?
>>>>> 
>>>>> Contributing as certified OSHW your own work on designing hardware 
>>>>> helps encourage developers contributing to getting the devices 
>>>>> supported in mainline linux and u-boot.
>>>>> 
>>>>> Getting bootloader and kernel code mainlined encourage distributors 
>>>>> integrate and maintain support the the devices in their 
>>>>> distributions.
>>>>> 
>>>>> Having devices supported in distributions helps users prioritize the 
>>>>> devices over other (lesser free) options available to them.
>>>> 
>>>> This seems to assume that LetuxOS is not itself a distribution.
>>> 
>>> No.
>>> 
>>> For comparison, I work on the Debian distribution and dearly want the 
>>> Olimex Teres-I DIY laptop well supported there, which requires escaping 
>>> a similar vicious circle.
>> 
>> It looks as if we need someone who actively wants to get the goodies 
>> from LetuxOS into standard Debian. We had such members in our 
>> community in the past, but they seem to have lost interest (or more 
>> likely time for pure volunteering).
> 
> Speaking for myself, I got discouraged when we met in Bavaria and it 
> became clear to me that your avoiding OSHW certification was a 
> deliberate business choice.

No it was not about avoiding it. It was about not seeing any benefit
for anyone.

Just more paperwork and discussions. And some requirements that are
difficult to fulfill. And nobody c

Re: [Tinkerphones] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Paul,

> Am 21.05.2019 um 14:12 schrieb Paul Boddie :
> 
> On Tuesday 21. May 2019 10.22.50 H. Nikolaus Schaller wrote:
>> 
>> What else is going on in the LetuxOS eco-system?
>> 
>> We now support MIPS devices, not only ARM. Well one. The Imagination CI20
>> board. Just do "makesd ci20" to get a first SD card.
> 
> I'll have to stop procrastinating and try this now. Well done for getting to 
> the bottom of the kernel configuration problems, too!
> 
>> Behind the scenes, we have debootstrapped mipsel variants of the Letux
>> Debian images. And adapted the kernel defconfig so that we get a CI20
>> (Ingenic JZ4780) compatible kernel.
>> 
>> What is the motivation behind supporting yet another board (and not fixing
>> all others first)? The main aspect is that the jz4780 also contains an SGX
>> 544 GPU - like the OMAP5. This should help to get the SGX drivers working.
> 
> It might also help get the Letux 400 Minibook supported by a modern kernel as 
> well. :-)

Yes! This is also an important goal and comes much closer to reality now with
the CI20 up and running.

> 
> [Exciting PyraPhone and other news]
> 
>> On a very general view, we have achieved a lot, but still not enough to get
>> the LetuxOS eco-system into a self-sustaining mode. What is lacking?
>> 
>> * users are missing because software is not good enough for daily use
>> * hardware is missing because potential users complain about missing
>> high-quality software
>> * developers to polish the software are missing, because of missing (new)
>> hardware
>> 
>> You see the vicious circle? Ideas how to magically break it?
> 
> I ended up ranting a bit about this again recently. But it just takes a 
> glance 
> at the state of the smartphone market to see where some of the problems are 
> and where we might be able to offer solutions. I'm sure most people on this 
> list already know everything that I write below, but it is sometimes worth 
> reflecting on a situation to remind ourselves of the value in the things we 
> do.
> 
> Let us start by investigating what kinds of sustainable choices are available 
> for smartphone purchasers. It might be nice to consider the conventional 
> sustainability and ethical production criteria (and we should do so), but 
> with 
> our backgrounds we should start with an evaluation of the software on any 
> given phone because this is often the limiting factor in the phone's 
> longevity:
> 
> * Is the software up-to-date or upgradeable to bring it up to date?
> * Can the user build it all from sources?
> * Can the user deploy all the built software?
> * Will it always be possible to upgrade and use new software?
> 
> Given the way phones are produced and sold, the answer to these things is 
> generally "no". Sure, the first answer may be "yes" if you buy a brand new, 
> top-of-the-line phone, but it will eventually be "no" as well. The producers 
> just want you to replace your phone and hope that this will be an acceptable 
> solution, which it is not:
> 
> https://www.smart.uio.no/news/swap-svitsj-and-burn-baby%21.html
> 
> Also, there tend to be very firm restrictions on deploying new software, 
> particularly at the lower levels. So, it is all very well the producer 
> offering a bundle of sources on their licence compliance site, but if they 
> don't let you deploy the software, it is all a charade and fails to empower 
> the end-user.
> 
> Naturally, there are choices like Fairphone which focused on conventional 
> sustainability issues first and arrived at the software issues later. Support 
> for updated software is apparently better on the second Fairphone model, but 
> there are still fundamental limitations to that support. And currently, only 
> refurbished units are available because production has been discontinued.
> 
> With this background, it is then worth looking at "community" initiatives 
> that 
> try and remedy the software situation. This seems to involve the following:
> 
> * Pure Free Software distributions (like Replicant)
> * Hybrid distributions that favour GNU/Linux (like PostmarketOS)
> * Hybrid distributions that favour Android (like LineageOS)
> * Application distributions derived from the Android Open Source Project
>   (like OmniROM and a bunch of others)
> 
> Maybe I conflate or confuse some of these things, particularly the latter 
> ones. But it is worth looking at which devices they tend to support. The 
> latter ones seem to have broader device support, but they also appear to be 
> focused on reworking the applications, decluttering the user experience, 
> &quo

Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Jonas,

> Am 21.05.2019 um 12:26 schrieb Jonas Smedegaard :
> 
> Quoting H. Nikolaus Schaller (2019-05-21 12:02:06)
>> Hi Jonas,
>> 
>>> Am 21.05.2019 um 11:00 schrieb Jonas Smedegaard :
>>> 
>>> First of all, congratulations with the progress!
>> 
>> Thanks!
>> 
>>> 
>>> 
>>> Quoting H. Nikolaus Schaller (2019-05-21 10:22:50)
>>>> BTW, here is another trick: You may (not) know that LetuxOS images 
>>>> created by makesd come rooted. This means you can simply ssh as 
>>>> root into the device without password check. This is quite helpful 
>>>> for developers and debugging.
>>> 
>>> A password-less network-accesible backdoor maybe unknown to the 
>>> system owner sounds dangerous to me: I recommend documenting that 
>>> very clearly (at least) everywhere passwords are currently menioned 
>>> in documentation.
>> 
>> Yes, please feel free to document it in the Wiki.
> 
> Is the wiki the only place passwords are mentioned?  There are no other 
> places users could be helped get notified about this open access? users 

I have no idea about what users do... We need users to see the missing
information and add it themselves. So we just must enable them to do it.
Which is the Wiki.

> 
> Suggestion: Add a notice in /etc/motd

Hm. Do your ever read/see that?

> 
> 
>>>> On a very general view, we have achieved a lot, but still not 
>>>> enough to get the LetuxOS eco-system into a self-sustaining mode. 
>>>> What is lacking?
>>>> 
>>>> * users are missing because software is not good enough for daily 
>>>>  use
>>>> * hardware is missing because potential users complain about 
>>>>  missing high-quality software
>>>> * developers to polish the software are missing, because of missing 
>>>> (new) hardware
>>>> 
>>>> You see the vicious circle? Ideas how to magically break it?
>>> 
>>> Contributing as certified OSHW your own work on designing hardware 
>>> helps encourage developers contributing to getting the devices 
>>> supported in mainline linux and u-boot.
>>> 
>>> Getting bootloader and kernel code mainlined encourage distributors 
>>> integrate and maintain support the the devices in their 
>>> distributions.
>>> 
>>> Having devices supported in distributions helps users prioritize the 
>>> devices over other (lesser free) options available to them.
>> 
>> This seems to assume that LetuxOS is not itself a distribution.
> 
> No.
> 
> For comparison, I work on the Debian distribution and dearly want the 
> Olimex Teres-I DIY laptop well supported there, which requires escaping 
> a similar vicious circle.

It looks as if we need someone who actively wants to get the goodies from
LetuxOS into standard Debian. We had such members in our community in the
past, but they seem to have lost interest (or more likely time for pure
volunteering).

>  I have appreciated the efforts done in other 
> distributions - concretely I work done in Armbian and OpenSuSE was 
> instrumental in getting the device supported in mainline u-boot (likely 
> included with 2019.07 release), which benefits all competing 
> distributions.

I just came to my mind what the most successful embedded Linux PC probably
is: RasPi with Raspbian.

It is not even open hardware or software nor supported well by mainline
which seems to contradict your suggestions. So what can we learn from it?

Some factors may be:
* technical support by silicon vendor (brcm)
* sales&marketing support by component/chip distributors
* they likely can pay developers

> 
> 
>> So what do you think would help users to prioritize LetuxOS over other 
>> distributions?
> 
> LetuxOS being superior to its competitors, obviously :-)

Yes, it is superior in several aspects (e.g broad hardware support
in kernel) but not all (e.g. GUI useability). That is what I mean
with missing "quality for daily users".

> 
> My point is that that I firmly believe that to get out of the vicious 
> circle we _first_ need to collaborate and only _then_ compete (if needed 
> at all, but that's a different discussion).

Well, I am waiting for years for collaboration (the first LetuxOS dates
back to 2006) but it seems as if other projects decided to compete and start
from scratch instead of building on top of LetuxOS :)

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] [Gta04-owner] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi Jonas,

> Am 21.05.2019 um 11:00 schrieb Jonas Smedegaard :
> 
> First of all, congratulations with the progress!

Thanks!

> 
> 
> Quoting H. Nikolaus Schaller (2019-05-21 10:22:50)
>> BTW, here is another trick: You may (not) know that LetuxOS images 
>> created by makesd come rooted. This means you can simply ssh as root 
>> into the device without password check. This is quite helpful for 
>> developers and debugging.
> 
> A password-less network-accesible backdoor maybe unknown to the system 
> owner sounds dangerous to me: I recommend documenting that very clearly 
> (at least) everywhere passwords are currently menioned in documentation.

Yes, please feel free to document it in the Wiki.

> 
> 
>> On a very general view, we have achieved a lot, but still not enough 
>> to get the LetuxOS eco-system into a self-sustaining mode. What is 
>> lacking?
>> 
>> * users are missing because software is not good enough for daily use
>> * hardware is missing because potential users complain about missing 
>>  high-quality software
>> * developers to polish the software are missing, because of missing 
>>  (new) hardware
>> 
>> You see the vicious circle? Ideas how to magically break it?
> 
> Contributing as certified OSHW your own work on designing hardware helps 
> encourage developers contributing to getting the devices supported in 
> mainline linux and u-boot.
> 
> Getting bootloader and kernel code mainlined encourage distributors 
> integrate and maintain support the the devices in their distributions.
> 
> Having devices supported in distributions helps users prioritize the 
> devices over other (lesser free) options available to them.

This seems to assume that LetuxOS is not itself a distribution.

So what do you think would help users to prioritize LetuxOS over other
distributions?

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] New LetuxOS Kernels and some tricks and thoughts

[H. Nikolaus Schaller]

Hi,
there are new LetuxOS kernels:

letux-5.2-rc1
letux-5.1.3
letux-5.0.17
letux-4.19.44
letux-4.14.120 

Please see:

projects.goldelico.com/p/gta04-kernel/

Unfortunately display drivers in letux-5.2-rc1 for almost all devices are 
broken. So please either help
to fix the issues or wait for a later -rc.

Just in case you are not aware, letux-4.19.44 is the current longterm kernel 
and recommended for daily
use on our devices. You can also install it in LetuxOS Debian systems through

apt-get install linux-image-letux linux-rootfs-letux

and then an

apt-get update && apt-get upgrade

is sufficient to get future kernel (and other) updates.

BTW, here is another trick: You may (not) know that LetuxOS images created by 
makesd come rooted.
This means you can simply ssh as root into the device without password check. 
This is quite helpful
for developers and debugging.

You can just do

apt-get remove letux-ssh-root

to disable. Or apt-get install letux-ssh-root to re-enable. The latter of 
course means that you still
have some root access to the device. Either through sudo or the serial console.

What else is going on in the LetuxOS eco-system?

We now support MIPS devices, not only ARM. Well one. The Imagination CI20 
board. Just do "makesd ci20" to
get a first SD card.

Behind the scenes, we have debootstrapped mipsel variants of the Letux Debian 
images. And adapted the
kernel defconfig so that we get a CI20 (Ingenic JZ4780) compatible kernel.

What is the motivation behind supporting yet another board (and not fixing all 
others first)?
The main aspect is that the jz4780 also contains an SGX 544 GPU - like the 
OMAP5. This should help to get
the SGX drivers working.

The other aspect is that "fixing all others first" is a Sisyphus work. It is a 
never ending story. So
we can't wait until it is done. It will never be done ;) Therefore better 
contribute what can be done.

Finally, we have built a second generation (mechanical) prototype of the GTA15, 
the PyraPhone.
Some photos can be seen in the twitter channel

https://twitter.com/goldelico

and ED has made a nice video showing the Pyra and explaining the GTA15 board:

https://youtu.be/X3Su8LJnmd4 (GTA15 presentation is starting at 14:07).

Both devices can share almost the same software, so there is a big synergy 
between both projects.

Note that although it looks almost finished, this is just a mechanical protoype 
to find out if it can
be built and if components are on good positions (almost all are, some are not 
that good). The PCB
traces are incomplete which means that connecting a battery has no effect :)

On a very general view, we have achieved a lot, but still not enough to get the 
LetuxOS eco-system
into a self-sustaining mode. What is lacking?

* users are missing because software is not good enough for daily use
* hardware is missing because potential users complain about missing 
high-quality software
* developers to polish the software are missing, because of missing (new) 
hardware

You see the vicious circle? Ideas how to magically break it?

BR and happy tinkering,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] New major LetuxOS Kernel release: letux-5.1 is here

[H. Nikolaus Schaller]

and

letux-5.0.13
letux-4.19.40
letux-4.14.116

As usual, you can find the sources and precompiled binaries here:

http://projects.goldelico.com/p/gta04-kernel/

The binary kernel packages of letux-4.19.40 are included in the Letux debian 
repository
so that if you have installed the packages linux-image-letux, 
linux-modules-letux,
linux-rootfs-letux a simple apt-get update && apt-get upgrade && reboot
should suffice to get the latest longterm kernel.

I have successfully tested to boot letux-5.1 on a GTA04A5 and a Pyra.
Only my BeagleBoneBlack+LCD has display backlight broken again...

So please test and report any errors and bugs. And of course, patches
are welcome!

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] A short story about some GTA04 repairs

[H . Nikolaus Schaller]

Hi all,
recently, I received a parcel containing 4 GTA04A4 devices which were broken,
and I was asked for a repair.

Well, all of them had broken GPS sockets, which is known to be a weak point
of the GTA04A4 design. The problem is that the socket is surface mounted
and if the PCB is not extracted carefully enough from the case (or if the
GPS antenna cable is pressed in by too much force), the socket is ripped
off the PCB. This was fixed in GTA04A5 by using a THT socket.

Some boards also had problems with a broken off USB socket - mainly the same
issue that it is a SMT part in GTA04A4 and became a THT only in GTA04A5 later.

This is especially problematic if the camera is installed (like on these 4
units). Because then everything fits to 100µm into the case and a single wrong
movement of the PCB can give too much shearing force to the sockets/PCBs.

Additionally, one device did have a broken AUX button and another one a
broken off headset jack.

After doing this optical inspection, I tried to boot the naked boards.

The first board did not boot and I was not able to make it boot by recovery
µSD cards. It did not even show the magic ID string on RS232 which means
the OMAP3 Boot ROM is not running (or RS232 is broken). This needs deeper
analysis and looked to be unrepairable.

The second one did show the ID, but also did not want to boot. Therefore,
I took a recovery µSD (makesd gta04 / makesd gta04a5) and with that one I
could boot a little, but with problems. Therefore, I did break into the U-Boot
console and did erase the MLO and NAND environment:

nand erase 0 50

After booting again from µSD the boot loader did flash a new MLO / U-Boot
(red screen) and Linux booted to a login: prompt. So I just had to look how
to repair the ripped off sockets (unfortunately the copper was also ripped
off so it can't be soldered any more to the PCB...).

Next, I tried to run the flash-nand script to get a kernel into NAND, but it 
appears
that we did miss some typo in the script (and nobody seems to flash new images).
It was a little difficult to debug because it was ${DEV) instead of ${DEV}.
Do you spot the difference? What makes it really difficult to find is that the
shell can't report the precise line number but fails approx. 100 lines later...
So we have another patch already included in letux-5.1-rc3, letux-5.0-next
letux-4.20-next and letux-4.19-next.

The third device did show the same effects as the second one.

The fourth board did boot from NAND into an LXDE environment, and interestingly
it was a very old setup: a letux-3.7-offmode kernel compiled in June 2013 and
an U-Boot compiled in Feb 2014. I didn't know that our 5 years old software
is still in use :)

So at this point it appeared that 3 out of 4 boards "just" need hardware
micro-surgery to get the sockets and pushbuttons (or replacements) into
a better shape again.

Then I started to repair them. Reinstalling USB or GPS sockets is not easy
and it is more difficult if the copper pads are ripped off. So this required
to invent some tricks how to fasten them to the PCB. More like microsurgery
or a dentist's work by adding small stabilizer wires... They must not bee too
thin to be stiff enough and not too thick so that they fit. And they must
be solderable i.e. made of copper or brass.

After investing a lot of time, I managed to get two of them repaired.

The owner also had asked if I could install an ambient light sensor as
suggested in the GTA04 manual. This was an easy task and I had several TEPT4400
photo-transistors available and it was merely finding out the polarity
and drilling a hole into the front case. The best way to do it is to
insert (bot not solder) the transistor in the soldering pads, place the
GTA04 board (with display installed) onto the front plate of the case
and make a marking where the rounded head of the transistor is. Then drill
a 3mm hole from the inside out. Finally place the PCB with display and
TEPT into the front part so that the TEPT is in the hole. Then solder the
pins and cut them. Voila, done.

It can easily be tested by the /root/blanviewd daemon which is needed
for the Letux3704 (which uses the same sensor and connection to the
tsc2007 touch screen controller).

So I finally could send the two units out and two more were waiting that I
find the time to take care of them.

On Wednesday I found the time to take care of the remaining two and
managed to repair them as well. Fixing the sockets was just microsurgery
again and while doing that I noticed that two capacitors were missing
near the GPS receiver module. It turned out that they are 100nF and
belong to the RS232 charge pump. So this explained why the broken board
did not even report the magic ID. There was no power for RS232. After
reinstalling them I could start the board, flash a newer U-Boot and
everything went fine.

The most problematic was the ripped off headset socket. It has only
weak solder tabs, is mostly plastic. This differs from the USB and
G

Re: [Tinkerphones] MIPS CREATOR CI20

[H. Nikolaus Schaller]

Hi Paul,

> Am 29.03.2019 um 11:27 schrieb Paul Boddie :
> 
> On Friday 29. March 2019 08.57.22 H. Nikolaus Schaller wrote:
>> 
>>> Am 27.03.2019 um 17:51 schrieb H. Nikolaus Schaller :
>>> 
>>> 
>>> 
>>> So I have ordered one some minutes ago. The key idea was that I expect to
>>> get a board where I can more easily test and debug the MIPS variant of
>>> LetuxOS incl. kernels. And then this might help to get it onto the
>>> MipsBooks/Letux 400...
>> 
>> It already arrived yesterday.
> 
> Things happen fast where you are! I think my board was shipped from the USA 
> and although it did enter the country fairly quickly after that, I ended up 
> arguing with the courier about the tax applied to the "free shipping" for 
> several weeks afterwards.

Mine came through UPS from the UK. Nobody has an idea how this will run in
the future...

> 
>> Now I did power it on - and I am really impressed. It is the first board
>> I have seen where there is 3D-GPU support included in the preinstalled
>> NAND image. It starts with Xfce, Debian 7.5 (Wheezy), Kernel 3.0.8 and
>> as said SGX drivers are included and loaded. Running the sgx_clipblit_test
>> can be done immediately from the command line. This is where LetuxOS
>> on omap3 still fails...
> 
> It sounds like they did a good job on the default software. Unfortunately for 
> me, neither my monitor nor another one - both supporting DVI via an adapter - 
> could support the default resolution, which was particularly odd for the 
> second monitor. Although I recompiled the driver to use a different 
> resolution, I think I just decided to switch kernels in the end.
> 
> It is worth noting that modern GCC versions do not like the kernel code from 
> the 3.0.8 era (nor the U-Boot version being used), and there are some fixes 
> needed (in include/linux/compiler-gcc.h), but I am sure you have seen this 
> before. Also worth noting from looking at the drivers is that some of them 
> were fixed up to be less like vendor code and more like normal kernel code in 
> 3.18, so the HDMI support is rather different.
> 
> I also found from experiments that the I2C support is unreliable, although 
> the 
> Linux driver usually manages to get the display resolution over I2C just 
> fine. 
> Apparently, previous Ingenic SoCs also have reliability issues with the I2C 
> support.
> 
>> So far I only have these observations:
>> * there is no heartbeat so unless a monitor is connected it is difficult to
>> tell if the board is running
> 
> The rather bright LEDs tend to flash a lot, but that appears to be related to 
> MMC/SD activity.

I have used the Flash image only and not yet the SD card reader.

> 
>> * the apt/sources.list is outdated and points to server names no longer
>> available (Debian rearranges things every now and then)
> 
> Another thing that probably won't affect you is that most of the online 
> resources for this board are gone now. But pity the people who bought the 
> CI40 
> for IoT and for use with some cloud-based service provided by Imagination!
> 
>> * I had to change the keyboard layout
> 
> This is something I should have mentioned, but it is part of the usual Debian 
> configuration procedure:
> 
> dpkg-reconfigure keyboard-configuration
> 
> Also things like the locales. Since there's no battery on the board (arguably 
> reasonable given the Ethernet and WLAN support, perhaps also better for the 
> planet), the RTC needs updating every boot-up, but the distribution seems to 
> take care of that using NTP, I think.

Well it was easier to use the Xfce Settings... menu. Because I already had 
problems
typing the "-" character for something like "dpkg-reconfigure 
keyboard-configuration".

> 
>> * the board has a standard-SD slot (but I have enough adapters)
>> * the Mini-USB/OTG port is installed vertically - funny :)
> 
> There is some weird stuff with the OTG connector:
> 
> https://www.elinux.org/CI20_Hardware#USB_mini-OTG_connector

Ok, this is an important warning!!!

> 
>> * it is not clear how where and how to connect an RS232 port - but kernel
>> boot log is shown on screen
> 
> I use UART0 via pins 6, 8 and 10 of the primary expansion header:
> 
> https://www.elinux.org/CI20_Hardware#Primary_expansion_header
> 
> I use a USB-to-UART adapter like this:
> 
> https://shop.pimoroni.com/products/usb-to-uart-serial-console-cable

Yes, I have several of such things.

> 
> I think that the U-Boot prompt is only shown via the UART.

That would be expected. U-Boot does not know displays (with some exceptions
like GTA04 or OpenPandora).

> 
&

Re: [Tinkerphones] MIPS CREATOR CI20

[H. Nikolaus Schaller]

Hi Paul,

> Am 27.03.2019 um 17:51 schrieb H. Nikolaus Schaller :
> 
> 
> 
> So I have ordered one some minutes ago. The key idea was that I expect to
> get a board where I can more easily test and debug the MIPS variant of
> LetuxOS incl. kernels. And then this might help to get it onto the
> MipsBooks/Letux 400...

It already arrived yesterday.

Now I did power it on - and I am really impressed. It is the first board
I have seen where there is 3D-GPU support included in the preinstalled
NAND image. It starts with Xfce, Debian 7.5 (Wheezy), Kernel 3.0.8 and
as said SGX drivers are included and loaded. Running the sgx_clipblit_test
can be done immediately from the command line. This is where LetuxOS
on omap3 still fails...

So far I only have these observations:
* there is no heartbeat so unless a monitor is connected it is difficult to 
tell if the board is running
* the apt/sources.list is outdated and points to server names no longer 
available (Debian rearranges things every now and then)
* I had to change the keyboard layout
* the board has a standard-SD slot (but I have enough adapters)
* the Mini-USB/OTG port is installed vertically - funny :)
* it is not clear how where and how to connect an RS232 port - but kernel boot 
log is shown on screen

So in summary it was a good decision to get one :)

Now I have to learn how to find and boot a prebuilt SD (only) image with Debian
(so far I only found one that would reflash NAND). And then adapt makesd to
be able to create LetuxOS images with Wheezy, Jessie, Stretch, Buster, LXDE, 
XfCE,
Mate, QuantumSTEP, QtMoko, Replicant... And finally make SGX 1.14 work for them
(I can already compile the pvrsrvkm driver for jz4780).

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] MIPS CREATOR CI20

[H. Nikolaus Schaller]

> Am 27.03.2019 um 17:32 schrieb Paul Boddie :
> 
> On Wednesday 27. March 2019 15.47.28 H. Nikolaus Schaller wrote:
>> 
>> I think we articficially make the long-term goal even farther away by
>> not having a working GPLed kernel driverfor loading and interfacing to
>> the specific SoC. Therefore everyone has to start with getting something
>> working.
> 
> I agree with this. You have to start somewhere.
> 
>> Which may already too painful because it is not available for the latest
>> kernel, there are parts missing (e.g. for omap in the clocks and hwmods
>> setup).
>> 
>> So the barrier to start reverse engineering of closed parts is high, because
>> the open source parts are not easily working.
> 
> Yes, this is the unsustainable thing with Free Software components that 
> supposedly isolate the Linux kernel from proprietary software.
> 
>> The latter is what I am trying to achieve...
>> 
>> Yes, it is already a lot of work. But also fun.
> 
> But it is worth pursuing even if it just prolongs the life of a few products.
> 
> [Installing U-Boot in a gap between the partition table and the first 
> partition]
> 
>> Yes, that is what I mean with the "hidden section". It seems to contain
>> the SPL and U-Boot.
>> 
>> Basically using a FAT partition was just a trick on OMAP to make life
>> easier. The BootROM started to look for the boot loader (MLO, now called
>> SPL) at a specific sector.
>> 
>> If the SD card was formatted as FAT and the first file written to it was
>> called "MLO" it happened to sit at the correct position (and checksums
>> inside the file made the BootROM accept it). So this was equivalent to a dd
>> seek=
> 
> That is a neat hack, it must be said.
> 
>> Later omap chips and others got a BootROM that understands FAT... While
>> other SoC did not even try to "overlay" a FAT partition. The Udoo neo
>> (i.MX6) is such an example. Therefore, makesd understands macros to shift
>> the beginning of the first sector of a partition to make room. And another
>> option allows to install a file directly into some sector(s) by running
>> some dd after download.
>> 
>> So the CI20 doesn't seem to be an exception here and makesd should be
>> able to handle it without new functionality. Just needs the (U-Boot+SPL)
>> file to be installed on the server and a macro that describes the partition
>> scheme and runs the dd commands in the elinux page you have mentioned.
> 
> Yes, once you know what the requirements are, it really shouldn't be 
> difficult 
> to support the necessary copying commands.
> 
>> So I am really tempted to try to get one now :)
> 
> If you do, you should find it pretty easy to get a distribution working. 
> There 
> were some problems with Debian Stretch if you wanted to avoid systemd, which 
> was something I was attempting for the sake of continuity, and it seemed that 
> only Debian Jessie could support that configuration.

Well, LetuxOS has some letux-system-d.deb package... If it is installed it
will "remove" (i.e. prevent) systemd to be installed by setting an apt config.
So far it seems to work quite well - but only for Jessie.

Anyways, my systemd experiences with Stretch and Buster were not that bad.
In most cases it boots faster and sometimes it is easier to understand if
daemons with dependencies must be defined. But it is difficult to understand
the existing ones written by someone else.

One thing has changed since systemd and Debian 8 did appear: it is much easier
to google for examples and tutorials and documentation. That was difficult
during Jessie + systemd times.

> 
> With systemd, Stretch seems to work fine. There might be some extra package 
> configuration required in any case. I seem to be very good at finding corner 
> cases in Debian that cause things not to work properly for me.
> 
> Even if you don't get one, if you let me know which repositories I should be 
> looking at, I might be able to take a closer look at the code.

So I have ordered one some minutes ago. The key idea was that I expect to
get a board where I can more easily test and debug the MIPS variant of
LetuxOS incl. kernels. And then this might help to get it onto the
MipsBooks/Letux 400...

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

Re: [Tinkerphones] MIPS CREATOR CI20

[H. Nikolaus Schaller]

Hi Paul,

> Am 27.03.2019 um 14:40 schrieb Paul Boddie :
> 
> On Wednesday 27. March 2019 08.26.29 H. Nikolaus Schaller wrote:
>> 
>>> Am 25.03.2019 um 11:55 schrieb Paul Boddie :
>>> 
>>> Yes, I have a CI20 board.
>> 
>> Ah, great!
> 
> I may have mentioned it before somewhere, maybe not on this list, though.
> 
> [...]
> 
>>> Apart from that, I have used the Debian GNU/Linux distribution on the
>>> CI20, but since I don't care about the GPU (and don't like proprietary
>>> drivers/firmware),
>> 
>> Yes, I don't as well, but if it is the only choice, I am not that
>> ideological... Anyways there is the GPLed kernel driver which I am
>> currently interested in.
> 
> It would actually be interesting to make alternative firmware,

yes, this is the very very long term goal.

> and I think 
> efforts have been made for other GPU technologies in this regard, but it 
> requires a lot of time and reverse engineering plus familiarity with the 
> technologies involved.
> 
> But even with GPL-compatible kernel drivers, these proprietary GPUs cause 
> considerable problems, although I am surely telling this to someone who 
> already knows about the practical difficulties they cause. :-)

I think we articficially make the long-term goal even farther away by
not having a working GPLed kernel driverfor loading and interfacing to
the specific SoC. Therefore everyone has to start with getting something 
working.

Which may already too painful because it is not available for the latest kernel,
there are parts missing (e.g. for omap in the clocks and hwmods setup).

So the barrier to start reverse engineering of closed parts is high, because
the open source parts are not easily working.

The latter is what I am trying to achieve...

Yes, it is already a lot of work. But also fun.

> 
>>> I haven't used it with the GPU enabled. On some occasions, I have used it
>>> as a desktop system, but more often I log into it across the network.
>> 
>> That is like what I do with a Letux Cortex 8 and a RasPi 3B+. Just to habe
>> specific compute power for special tasks. For example debootstrapping the
>> LetuxOS rootfs images.
> 
> Right. Indeed, I should use it a bit more for building things, and I think 
> the 
> power consumption is pretty good, although I haven't measured it. One thing 
> that disappointed people was the wired network performance, recalling the 
> reaction from the OpenWrt community. (I also haven't tried the wireless 
> network support because that involves another binary blob.)
> 
> [...]
> 
>>> I then used a later kernel (3.18 instead of 3.08) for which the supplied
>>> GPU drivers probably wouldn't work, anyway, and I didn't fetch newer
>>> ones. Of course, Imagination have dropped the CI20 completely, so the
>>> links on elinux.org do not work (as you probably saw already):
>>> 
>>> https://www.elinux.org/CI20-SGX_kernel_module
>> 
>> Yes. I have already been able to find a copy of the DDK1.14 files.
>> 
>> Comparing with the TI provided DDK1.14 shows that they are almost the same,
>> except that TI added better OMAP support than the IMG package. But there
>> are ca. 15 code changes in general code which will become interesting to
>> study.
> 
> I should probably take a look. I have occasionally browsed the documentation 
> for PowerVR in case there were some helpful things released that might make 
> improved Free Software support possible, but I don't really have a focus on 
> this kind of thing.
> 
> [...]
> 
>>> I tend to use SD cards for new installations, however, leaving the flash
>>> memory alone.
>> 
>> Yes, that is probably not a big issue then.
>> 
>> A question about the SD format for the non-Flash case: does it also have the
>> standard 2-Partition scheme (FAT for u-boot and uImage and DTB) plus an ext
>> for rootfs?
> 
> The instructions I followed are here:
> 
> https://www.elinux.org/CI20_Dev_Zone#Making_a_bootable_SD_card_from_sources
> 
> I don't think the FAT partition is needed. On one of my cards, I just have a 
> single "Linux" partition:
> 
> Device Boot Start  End  Sectors  Size Id Type
> /dev/sdc14096 15278079 15273984  7.3G 83 Linux
> 
> And the partition uses the ext4 filesystem. So it is a similar arrangement to 
> that supported by the Ben NanoNote, with the difference being that the 
> NanoNote has a modified U-Boot in the flash memory that understands ext2/3/4 
> to access the SD card, whereas the process is supported directly by the CI20 
> hardware by changing a &

Re: [Tinkerphones] MIPS CREATOR CI20

[H. Nikolaus Schaller]

Hi Paul,

> Am 25.03.2019 um 11:55 schrieb Paul Boddie :
> 
> On Monday 25. March 2019 09.04.06 H. Nikolaus Schaller wrote:
>> Hi,
>> as you may know I am working a little on the PVR/SGX drivers for
>> omap.
>> 
>> Since the latest DDK code (1.14) includes some jz4780 support,
>> I researched and found that
>> a) this is for the CI20 creator board
>> b) it could also be used as an SGX reference implementation
>>   https://elinux.org/CI20_upstream
>>   https://elinux.org/CI20-SGX_kernel_module
>> c) the CI20 is still available at not too high cost (<100€)
>> d) LetuxOS already has some basic MIPS/jz4730 support (untested)
>> 
>> Does anyone have experimented with the CI20?
> 
> Yes, I have a CI20 board.

Ah, great!

> I have used it for exploration with L4Re/Fiasco.OC, 
> which needed some adjustment to work on the CI20 and which led to my efforts 
> to get that software working on the Ben NanoNote and Letux 400 (of which you 
> are familiar):
> 
> http://www.boddie.org.uk/paul/Landfall.html
> 
> Apart from that, I have used the Debian GNU/Linux distribution on the CI20, 
> but since I don't care about the GPU (and don't like proprietary 
> drivers/firmware),

Yes, I don't as well, but if it is the only choice, I am not that ideological...
Anyways there is the GPLed kernel driver which I am currently interested in.

> I haven't used it with the GPU enabled. On some occasions, 
> I have used it as a desktop system, but more often I log into it across the 
> network.

That is like what I do with a Letux Cortex 8 and a RasPi 3B+. Just to habe
specific compute power for special tasks. For example debootstrapping the
LetuxOS rootfs images.

> 
>> Yes, I know that there will be no new products based on it,
>> but we are tinkering... And tinkering with the CI20 may
>> help to better understand the omap3/4/5 sgx drivers and
>> separate the architecture and SoC dependent from the independent
>> parts.
> 
> Indeed, I mentioned this in a thread about the PowerVR GPU in the CI20 only 
> the other day, referencing your project:
> 
> https://groups.google.com/d/msg/mips-creator-ci20/5G_6rv0uixg/ZsxJUyC8BgAJ

Fine.

> 
> Also, there was an update about the availability which I added to the 
> elinux.org page:
> 
> https://www.elinux.org/CI20_Availability
> 
> The base system should already include the relevant drivers, but I only 
> booted 
> it once and discovered that it wouldn't produce a display on my monitor (via 
> a 
> HDMI-to-DVI cable) because the resolution was not set to a reasonable default.
> 
> I then used a later kernel (3.18 instead of 3.08) for which the supplied GPU 
> drivers probably wouldn't work, anyway, and I didn't fetch newer ones. Of 
> course, Imagination have dropped the CI20 completely, so the links on 
> elinux.org do not work (as you probably saw already):
> 
> https://www.elinux.org/CI20-SGX_kernel_module

Yes. I have already been able to find a copy of the DDK1.14 files.

Comparing with the TI provided DDK1.14 shows that they are almost the same, 
except
that TI added better OMAP support than the IMG package. But there are ca. 15 
code
changes in general code which will become interesting to study.

> But I imagine that the objective would be to work from other sources, anyway. 
> (My own priorities for L4Re involve enabling HDMI and the framebuffer, with 
> the former being awkward because I would need to adapt Linux driver code 
> since 
> the HDMI stuff is not documented.)
> 
> I don't know what the situation is regarding newer kernels. There are all 
> sorts of Android kernels that appear to be later than 3.18 (assuming that the 
> versioning is consistent), and someone is maintaining Gentoo with newer 
> "patch 
> releases" of 3.18:
> 
> https://groups.google.com/d/topic/mips-creator-ci20/KslB5LFqd-s/discussion
> https://www.setphaserstostun.org/pages/mips-creator-ci20-gentoo-resources/

Intersting!

> 
> The most recent kernels have dropped support for the flash memory used by the 
> CI20, leading to recriminations:
> 
> https://groups.google.com/d/topic/mips-creator-ci20-dev/tVuJlzX_q0w/discussion
> 
> I tend to use SD cards for new installations, however, leaving the flash 
> memory alone.

Yes, that is probably not a big issue then.

A question about the SD format for the non-Flash case: does it also have the 
standard
2-Partition scheme (FAT for u-boot and uImage and DTB) plus an ext for rootfs?

Then we might be easily able to have makesd support the CI20 as well.

If it uses a hidden section for binary U-Boot and/or kernel it is also possible
but a little more tricky and more difficult to maintain.

So it is good to know that you have such a board an might be able to help 
testing
or setting up another one.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] MIPS CREATOR CI20

[H. Nikolaus Schaller]

Hi,
as you may know I am working a little on the PVR/SGX drivers for
omap.

Since the latest DDK code (1.14) includes some jz4780 support,
I researched and found that
a) this is for the CI20 creator board
b) it could also be used as an SGX reference implementation 
   https://elinux.org/CI20_upstream
   https://elinux.org/CI20-SGX_kernel_module
c) the CI20 is still available at not too high cost (<100€)
d) LetuxOS already has some basic MIPS/jz4730 support (untested)

Does anyone have experimented with the CI20?

Yes, I know that there will be no new products based on it,
but we are tinkering... And tinkering with the CI20 may
help to better understand the omap3/4/5 sgx drivers and
separate the architecture and SoC dependent from the independent
parts.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] OpenMoko Debug Boards and www.openmoko.org

[H. Nikolaus Schaller]

Hi,
it seems as if Harald has some Debug Boards:

> http://shop.sysmocom.de/products/openmoko-neo-debug-board-v3-kit

And donations there help to keep the archive of openmoko.org active and in 
operation.

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

[Tinkerphones] GTA15 / Pyra-Phone news

[H. Nikolaus Schaller]

Hi,

I have spent a little time to improve some component
placement and fix my scripts which do the translation
to 3D data (by generating a python script that can be
imported into the FreeCAD command line version to
write a STEP file).

Here you can find the result:

https://twitter.com/goldelico/status/1098903479534395395

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org