Re: [Community] FOSDEM 2015

[Dr. H. Nikolaus Schaller]

Hi Paul,

Am 01.02.2015 um 17:58 schrieb Paul Kocialkowski cont...@paulk.fr:

 ² the main entrance but inside from about 11:45 to 12:00 holding in 
 front of
 me a sign with the OpenPhoenux logo.
 
 I'll be there, and I guess Paul will read this as well. I'll wear my
 phone around my neck for identification.
 
 Sure, count me in as well!
 
 I waited for about half an hour at the indicated location, with Christ
 who had to leave at some point. Eventually, I gave up and grabbed lunch
 on my own.
 
 Thankfully, we were able to chat a bit after my talk!

sorry that I could not visit FOSDEM this year and did miss your talk.
But I am curious how it was.

And how the FOSDEM generally was. Anything interesting to share
with our community?

BR,
Nikolaus

 
 -- 
 Paul Kocialkowski, Replicant developer
 
 Replicant is a fully free Android distribution running on several
 devices, a free software mobile operating system putting the emphasis on
 freedom and privacy/security.
 
 Website: http://www.replicant.us/
 Blog: http://blog.replicant.us/
 Wiki/tracker/forums: http://redmine.replicant.us/
 
 ___
 Community mailing list
 Community@openphoenux.org
 http://lists.goldelico.com/mailman/listinfo.cgi/community
 http://www.openphoenux.org

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

Re: [Community] [Gta04-owner] FOSDEM 2015

[Dr. H. Nikolaus Schaller]

Hi.,

Am 16.01.2015 um 19:34 schrieb Christ van Willegen cvwille...@gmail.com:

 Hi all,
 
 On Fri, Jan 16, 2015 at 5:12 PM, Dr. H. Nikolaus Schaller
 h...@goldelico.com wrote:
 If there's no 'official' pace to meet (Nikolaus had a stand last year,
 it was easy to go there…)
 
 unless someone has organised one, there won’t be a stand this year.
 
 I gathered that.
 
 we’ll discuss later.
 
 unfortunately I have too many other things to do, for which I am paid.
 
 That wasn't aimed at you, no offence meant (and presumably none
 taken…).

no offence assumed :)

I just wanted to explain that I can’t attend and organize things. And why…

 I had Paul in mind to discuss things with :-) It;s good
 that you get paid to do stuff!!
 
 I _think_ the best _time_ to meet up would be Saturday, in the
 morning, since everyone (not Lukas, unfortunately...) will be there, I
 guess. The opening talk is at 09:30, in Janson. Can we meet at the bar
 that is inside Janson at 09:00 to get to know each other's faces and
 talk about our schedules?
 
 Christ van Willegen

BR, and have fun!

Nikolaus

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

[Community] ANN 2: new gta04-makesd for preparing bootable SD cards

[Dr. H. Nikolaus Schaller]

Hi,
as written in the 3.19.0-kernel announcement, we now support more and more
different hardware devices by the kernel.

To simplify creating bootable SD cards for such a plethora of devices,
there is also a new makesd script. No longer one for each device, doing
dirty tricks, but a generic one that knows how to create single and multi-
partiton images by pulling the components from http://downloads.goldelico.com

It is easily controlled by command line arguments allowing to choose
the version of a package to be installed, the device it should run on,
how many partitions should be filled with what. It is possible to configure
individually for each partition which x-loader and u-boot, which kernel,
which device trees which modules and which root file system is to be installed.

Some examples:

DEV=/dev/sdc ./makesd -v latest-beta gta04  — production image (for unbricking, 
u-boot upgrade) for the GTA04 (Letux 2804) with Debian/LXDE using variant 
‘latest-beta’
DEV=/dev/sdc ./makesd gta04b2  — same for GTA04b2 (Letux 3704)
DEV=/dev/sdc ./makesd bb  — image for the BeagleBoard (classic or XM) with 
Debian/LXDE
DEV=/dev/sdc ./makesd bbb  — image for the BeagleBone Black with Debian/LXDE
DEV=/dev/sdc ./makesd pyra  — same for OMAP5432EVM (Pyra prototype)
DEV=/dev/sdc ./makesd replicant  —  latest (stable) replicant (universal image 
boots on L2804, L3704, L7004)
DEV=/dev/sdc ./makesd -v unstable replicant  —  latest (unstable) replicant 
(boots on L2804, L3704, L7004)
DEV=/dev/sdc ./makesd all — make a 4-system (Debian, QtMoko, Replicant, 
QuantumSTEP) multi-partition image where you can choose the system through the 
boot loader menu (boots on L2804, L3704, L7004)
DEV=/dev/sdc ./makesd -v unstable pyra -F -v latest replicant — use unstable 
kernel and replace the Debian/LXDE in partition 2 with latest replicant (boots 
up to the root@android:/ # prompt) for the OMAP5432EVM
DEV=/dev/sdc ./makesd -v unstable openpandora  — the current working image for 
the OpenPandora (put into left slot and boot through boot menu)

More information about installation and examples can be found at

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

Please note that a new consistent “latest” release is due, but not yet tested,
so some of the commands (without specifying -v unstable or -v latest-beta)
may fail because they try to pull files that are not yet available in the 
“latest”
as of today..

So I hope that we are doing something you appreciate and find useful
and maybe would like to support either through [1] or by testing, reporting
bugs and submitting patches.

We really appreciate your feedback, since we don’t find every bug and
flaw - and we always understand the bad and incomplete documentation [2]
we have written…

BR,
Nikolaus

[1]: http://shop.goldelico.com/wiki.php?page=GTA04%3ADonation
[2]: http://projects.goldelico.com/p/gta04-makesd/

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

Re: [Community] Neo900 ship date

[Dr. H. Nikolaus Schaller]

Hi Ryan,

Am 10.03.2015 um 19:27 schrieb Ryan de Laplante (Personal) 
r...@ryandelaplante.ca:

 Does anyone have a vague idea of when we'll be able to pay for and
 receive a Neo900?  It can't come soon enough.

For schedule, pricing, payments etc., please contact the Neo900 project 
management team:

http://neo900.org/contact

Well, this list here is also mentioned but it appears that nobody who can give 
authoritative answers
is reading it.

BR,
Nikolaus

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

Re: [Community] Staus update GTA04A5

[Dr. H. Nikolaus Schaller]

Hi,

Am 13.05.2015 um 13:19 schrieb Liviu Farbas liviu.far...@gmail.com:

 Apart from the case space, couldn't the second SD slot be connected to the 
 OMAP cpu instead of the emmc?
 
The GTA04 has no eMMC, it has NAND flash (this is not the same regarding the 
interfaces).
And the OMAP3 has no specific eMMC interface. It has 3 MMC interfaces. 2 of 
them are already used and the third one is not available.

Maybe the schematics in the system manual give some more background information:

http://projects.goldelico.com/p/gta04-main/page/Manual/

BR,
Nikolaus


 On May 13, 2015 10:05 AM, Dr. H. Nikolaus Schaller h...@goldelico.com 
 wrote:
 Hi,
 
 Am 13.05.2015 um 08:38 schrieb Liviu Farbas liviu.far...@gmail.com:
 
 If that is the case, it's OK. So if the memory chip containing bootloader 
 will get damaged we can still use the phone?
 
 Yes. You can even reflash the NAND image (it is “unbrickable” by design).
 
 My main idea was to have 2 SD card slots: one for the card with the 
 bootloader and operating system, and one with the card for the file storage.
 
 Ah I see. Well, we don’t have the space in the Freerunner plastics case and 
 the OMAP3 has no spare MMC interface (one is for the uSD and the other one 
 for the WiFi SDIO; the third MMC I/F is not available to pinmux restrictions).
 
 Best regards,
 
 
 
 BR and thanks for your suggestions,
 Nikolaus
 
 Liviu
 
 On May 12, 2015 8:52 PM, Dr. H. Nikolaus Schaller h...@goldelico.com 
 wrote:
 Hi,
 
 Am 12.05.2015 um 19:37 schrieb Liviu Farbas liviu.far...@gmail.com:
 
 i was thinking at something like the Raspberry Pi, which does not have any 
 memory built in, and everythin including bootloader is stored on sd card.
 
 What would be the benefit?
 
 On the GTA04 you can store bootloader and kernel either in NAND or uSD or 
 both. By pressing the AUX button you can choose which memory the system 
 boots from.
 
 And, the NAND and the RAM are combined in a single multi-chip-module, so you 
 can’t remove just the NAND. You can erase it and then it will be skipped 
 when booting. So this would simulate a non-existing chip.
 
 IMHO a mix of boot loader in NAND and kernel/device-tree/rootfs on uSD is 
 the most flexible setup so that you can simply swap SD cards for different 
 OS versions to run.
 Please also note that having the boot loader on the SD card requires a 
 two-parition layout and is quite inflexible. We have a tool that can 
 partition and format and fill SD cards in quite flexible choices [1].
 
 So what are you missing or trying to improve?
 
 BR,
 Nikolaus
 
 [1]: http://projects.goldelico.com/p/gta04-makesd/
 
 
 
 On May 12, 2015 11:37 AM, Dr. H. Nikolaus Schaller h...@goldelico.com 
 wrote:
 Hi,
 the GTA04A5 has a NAND flash of 512 MB and a uSD reader up to 32 GB (see 
 photos on www.gta04.org). The NAND flash is mainly used for the boot loader 
 and a small rescue Linux system but real OS operation is done by swapping 
 such uSD cards. So you can for example have a uSD card for Replicant and 
 another one for QtMoko. Or put both on one in different partitions.
 
 BR,
 Nikolaus
 
 Am 12.05.2015 um 10:12 schrieb Liviu Farbas liviu.far...@gmail.com:
 
 What about the emmc module? Will that module be removable? Or instead a 
 built in emmc, wouldn't be a better choice to add a SD card slot? It would 
 be really great to experiment with operating systems without the risk of 
 corrupting the emmc.
 
 Best regards,
 
 Liviu
 
 On May 11, 2015 10:37 AM, Dr. H. Nikolaus Schaller h...@goldelico.com 
 wrote:
 Hi all,
 you may wonder what is going on with this project. Did it turn into a 
 black hole? Or
 did someone do a “rm -rf /“ :)
 
 No, nothing of that. Therefore, I think we owe you some short status 
 update on this project.
 
 There hasn’t been much to report in the last months, but now we have 
 several news
 within some days.
 
 1. I have checked again and we can still get the GTM601W, but the 
 distributor says
 the risk is high that OPTION declares EOL any time and in that case we 
 would have
 to make an order of at least 3000 units so that they restart 
 production just for us.
 
This means we must secure these modules for us now, since there is no 
 replacement
that easily fits into the space constraints of the GTA04 (resp. 
 GTA01/02 board).
 
Cinterion modules would be nice since they are planned for the Pyra and 
 the Neo900,
but they are approx. 10% too big.
 
 2. we see some difficulties in getting the W2SG0084 GPS module, but that 
 is some
 paperwork the distributor has to do with Wi2Wi.
 
Nevertheless, this is also a risk candidate for EOL because only one 
 distributor shows
stock.
 
 3. There are also good news:
 we participate in the risk buy of Samsung 1GB RAM+512MB NAND chips (as
 planned for the Neo900). So the GAT04A5 gets twice as much RAM :)
 
 This chip has already been tested by reworking a BeagleBoard XM and 
 modifying
 the boot loader (kernel didn’t find

Re: [Community] Staus update GTA04A5

[Dr. H. Nikolaus Schaller]

Hi,

Am 12.05.2015 um 11:18 schrieb NeilBrown ne...@suse.de:

 On Mon, 11 May 2015 09:37:07 +0200 Dr. H. Nikolaus Schaller
 h...@goldelico.com wrote:
 
 Hi all,
 you may wonder what is going on with this project. Did it turn into a black 
 hole? Or
 did someone do a “rm -rf /“ :)
 
 No, nothing of that. Therefore, I think we owe you some short status update 
 on this project.
 
 There hasn’t been much to report in the last months, but now we have several 
 news
 within some days.
 
 1. I have checked again and we can still get the GTM601W, but the 
 distributor says
the risk is high that OPTION declares EOL any time and in that case we 
 would have
to make an order of at least 3000 units so that they restart production 
 just for us.
 
   This means we must secure these modules for us now, since there is no 
 replacement
   that easily fits into the space constraints of the GTA04 (resp. GTA01/02 
 board).
 
   Cinterion modules would be nice since they are planned for the Pyra and 
 the Neo900,
   but they are approx. 10% too big.
 
 2. we see some difficulties in getting the W2SG0084 GPS module, but that is 
 some
paperwork the distributor has to do with Wi2Wi.
 
   Nevertheless, this is also a risk candidate for EOL because only one 
 distributor shows
   stock.
 
 3. There are also good news:
we participate in the risk buy of Samsung 1GB RAM+512MB NAND chips (as
planned for the Neo900). So the GAT04A5 gets twice as much RAM :)
 
This chip has already been tested by reworking a BeagleBoard XM and 
 modifying
the boot loader (kernel didn’t find the NAND yet, but U-Boot did. This is 
 a problem
that will jointly be fixed with the Neo900 software team).
 
 4. Production: we still are a little away from the quorum of 100 preorders 
 (at the
moment of this writing we have estimated approx. half = 45 units). So it 
 is still
not possible to make final decisions about production dates and final 
 pricing.
 
So we need to get a little more support for our project. If you have 
 ideas, please
let us know or start activities. Many small activities are as good as a 
 big one!
And we know that this is a niche product that requires an existing 
 GTA01/02
device. So it is not possible to “attract the masses”. We must find and 
 convince
the previous GTA01/02 owners whose devices are collecting dust. There had 
 been
produced ca. 15k such devices so that we just need another 1/3% or in 
 other
words only 1 out of 300 GTA02 owners needs to decide for a GTA04A5.
 
 5. Regarding the risk buy of the GTM601W, RAM chips and W2SG0084, I plan to
take the budget (~5100 EUR) that we already have collected.
 
This will transform the vouchers into ownership of components. So it has 
 the
consequence that we can’t refund in money (cash, bank transfer) any more, 
 but
only in unused hardware components (i.e. 100 EUR ~ 1*GTM601+1*RAM+1*GPS)…
 
For future preorder vouchers you would also buy such a component set 
 (which we
would keep in safe warehouse of course) until we can really build the 
 whole devices.
 
 
 So quite some news and I would be happy if we can fill up the missing 
 preorders [1]
 sooner than later so that we can start production. Please think about 
 securing your
 set of components for the last production batch of the most open smartphone 
 platform
 that we already have.
 
 
 I have been thinking about ordering a GTA04A5, but there is one barrier.
 I need to be confident that it can draw less than 10mA in standby.

 Currently the best we have seen with GTA04A3,4 is about 20mA (and 40mA on
 Linux 4.0, but that must be a software issue).
 
 This is probably a software issue, but until it's actually been demonstrated
 that the hardware can sit in standby using under 10mA, I cannot be certain.

There will be = 2 changes that affect the standby current:
a) the 26 MHz oscillator is not always on any more
b) IrDA receiver and RS232 level shifters can be turned on/off separately (on 
A3/A4 either one is always on)
c) the HMC5883l and ITG3200 will likely be replaced by newer Bosch sensors

If you know something else which could affect standby current, please let me 
know.

Ah, a new unknown is the new SAMSUNG RAM/NAND chip. There we have no data sheet
but know that it is used in the N9.

 It’s all very frustrating...

At least for me it is fun and a playground to learn :)

BR,
Nikolaus

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

Re: [Community] [Gta04-owner] Looking for a new project name (gta04-kernel)

[Dr. H. Nikolaus Schaller]

Hi Butrus,

Am 24.06.2015 um 11:41 schrieb Butrus Damaskus butrus.but...@gmail.com:

 
 On Mon, Jun 8, 2015 at 10:12 PM, Dr. H. Nikolaus Schaller 
 h...@goldelico.com wrote:
 
 Now, the stage is open for your ideas and comments:
 
 
 What about Linux? ;-)
 
 (In other words, is there any reason gta04-kernel is not mergen into the 
 mainstream?)

some reasons:

1. it is not only about the kernel, but boot loader, makesd script, roofs, etc. 
I.e. a name for a GNU/Linux distribution optimized (and preconfigured) for our 
handheld devices
2. yes, we want to merge things into mainstream, but this is still a long way 
to go. And until we have 100% upstreamed, we need a project name different from 
“Linux(TM)”.
3. there are components which a kernel for daily use needs but are unlikely to 
get upstream ever (e.g. the gta04_defconfig, useful user space tools, GPU 
driver)

I.e. this kernel wants to be ahead of kernel.org and support features missing 
in kernel.org already today.

BR,
Nikolaus

 
 
  
 ___
 Gta04-owner mailing list
 gta04-ow...@goldelico.com
 http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

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

Re: [Community] [Gta04-owner] Looking for a new project name (gta04-kernel, gta04-rootfs etc.) = letux.org

[Dr. H. Nikolaus Schaller]

Hi all,
thanks for all your contributions!

I have made up my mind and the goal will be to (re)name it to:

Letux-distribution (as the overall name)
Letux-kernel
Letux-bootloader
Letux-makesd
etc.

It wants to be a complete GNU/Linux distribution for several different 
portable/embedded devices
(GTA04, OpenPandora, Pyra, BeagleBoard/Bone, others) and with different GUI 
flavours (LXDE,
XFCE, Replicant, QtMoko, QuantumSTEP, …).

The main reason behind this choice was that it already exists: www.letux.org
The other one that it is concise (just 5 letters) - and the word alludes to 
“Linux”.

And it was initially started exactly as what I think we should end up: a 
complete GNU/Linux system for different devices.

To avoid confusion, this move will of course not be done over night.

And it will neither make the OpenPhoenux name obsolete (that is this community) 
nor GTA04 (that is the successor hardware of GTA02).

So please expect a slow migration in the next months and support wherever it is 
possible.

BR and thanks,
Nikolaus

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

Re: [Community] Looking for a new project name (gta04-kernel)

[Dr. H. Nikolaus Schaller]

Am 11.06.2015 um 02:01 schrieb Neil Brown ne...@suse.de:

 On Mon, 8 Jun 2015 22:12:43 +0200
 Dr. H. Nikolaus Schaller h...@goldelico.com wrote:
 
 Hi all,
 as you all know we are maintaining a “production” kernel for GTA04 devices 
 and are working to
 get it (again) feature complete (i.e. that it supports all bits and pieces 
 of the GTA04 hardware
 including good power management for daily use).
 
 We have made progress - but we are still not there. Linux 4.1-rc7 is now 
 available (see our
 Twitter postings) and so will become a long-term kernel in 4.1.x in 1-2 
 weeks.
 
 While all this work started as a kernel for the GTA04 device (Letux2804) it 
 has broadened
 its scope over the past years to other ARM based devices. Still mainly OMAP3 
 but also
 OMAP4 and OMAP5. A list of the currently supported devices is here:
 
  http://projects.goldelico.com/p/gta04-kernel/page/Platforms/
 
 We already support these different boards with a single kernel binary and 
 modules - just
 the device tree files differ. 
 
 As a next step, we will work on 4.2.
 
 It looks as if Linux 4.2 might bring Device Tree to MIPS machines as well, 
 and therefore there
 are chances to finally support even more machines as we already do. Well, 
 not always with the
 same binary kernel (ARM vs. MIPS instruction set). But it suffices to just 
 run it twice with different
 cross-compilers.
 
 Two of the interesting devices might be well known to this community: Letux 
 400 MiniBook
 and the Ben Nanonote.
 
 This shows a big trend of Linux Kernels: they become more universal and the 
 list of boards
 that can be supported is becoming broader.
 
 Therefore, I think we should recognise that “GTA04-Kernel” (and GTA04-boot, 
 -rootfs etc.) is becoming
 a misleading name (since GTA04 is just a specific piece of OMAP3+GTM601W 
 hardware), as it implies
 a narrow focus that is no longer the case.
 
 And with the new gta04-makesd script we already give the user the impression 
 that we maintain
 a “Distribution” for different devices.
 
 So, let me open a discussion and request proposals how we could rename our 
 “Distribution”.
 
 Some aspects to think about:
 * it is ARM, OMAP but not necessarily (MIPS is on the radar screen)
 * it has its roots in Openmoko, Freerunner, Letux
 * and wants to bring long-term support for these devices (if possible)
 * should be easy to recognise
 * not be used by any similar project to avoid confusion
 * the main idea is to add minimally to Linux kernel what should already be 
 there and work permanently on upstreaming
 * but it is not only kernel. It is boot loader, makesd script, Debian 
 rootfs, Replicant and potentially other user space flavours
 
 Now, the stage is open for your ideas and comments:
 
 How about
  openphoenux
 ??
 I presume you thought of that

Ahem. No. Sometimes you don’t see the obvious. Especially if you get older :)

 and rejected it.  Could you explain why?

Well, there are some aspects:
1. community should be involved and decide
2. “openphoenux kernel” is a little long and difficult to speak - isn’t it? So 
alternatives should get a chance.

Another obvious choice would be “Letux”. It was coined [1] exactly as what we 
are looking for: a full Linux distro for handheld devices.
The first one was for the Acer n30 [2].

Looks a little confusing. Agreed. Therefore we need to do some house keeping.

BR and thanks,
Nikolaus

[1]: http://projects.goldelico.com/p/letux/
[2]: http://projects.goldelico.com/p/letux-n30/

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

Re: [Community] [Gta04-owner] OpenPhoenux and GTA04 at CCCamp?

[Dr. H. Nikolaus Schaller]

Hi,

Am 24.07.2015 um 18:53 schrieb Paul Kocialkowski cont...@paulk.fr:

 Next month, CCCamp will take place near Berlin, Germany.
 The event is a great occasion to highlight the GTA04 project and our
 OpenPhoenux community at large. Neo900 folks already plan on attending
 and will organize a Neo village:
 https://events.ccc.de/camp/2015/wiki/Village:Neo
 
 I will also attend to represent Replicant (and hopefully get a lightning
 talk about it, if not a self-organized session).

Good!

 In addition to
 presenting the project and the various freedom and
 privacy/security-related issues in mobile devices, I would also like to
 try and get new people to join-in.
 
 Nikolaus, do you plan on having some OpenPhoenux and GTA04
 representation at camp besides Neo900?

I didn’t know about this event until some weeks ago - and I personally
have a schedule conflict… And I am not a fan of outdoor camping either :)

 Also, my GTA04 still has a broken
 GPS connector, so I thought perhaps it would be the right time to see
 about it and get it fixed (Joerg already mentioned he would bring some
 soldering tools, too).

Yes, that would have been a good occasion. But you can also send it to me
(any time you like) and I can return it next day (sometimes same day). It
needs around 10 minutes to repair if the person knows how to do it quickly
and reliable.

 
 I would be very happy to meet members of the community there and talk
 about the future of Replicant on the OpenPhoenux projects and community!

Thanks for making us aware!

I am sure that some members of our community are going there. Maybe they
can share their plans and reply to this mail?

BR,
Nikolaus

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

Re: [Community] Custom display for GTA04

[H. Nikolaus Schaller]

Hi,

Am 26.10.2015 um 20:57 schrieb wonderph...@posteo.de:

> Hi Nikolaus,
> 
> What would it take if someone wanted to use a GTA04 replacement board not 
> with a GTA02 case and display but with a different display?

Yes, it is possible. For example the Letux 3704 and Letux 7004 devices use a 
GTA04 mainboard with different display.

What it needs:
* connector
- the GTA04 custom board would have two board to board connectors
- or you can use a 39 pin "jumper cable"
* interface PCB
- using matching connectors
- may need level shifter (GTA04 output signals are 1.8V logic levels 
and some panels need 3.3V)
- (different) backlight dc/dc converter
- connection for touch screen
- depending on the panel type: LVDS or MIPI converter

> 
> The design and the 3D printing of the case might not be that difficult but 
> what would need to be done to attach for example the display of an old 
> (sp)iPhone?

Well, AFAIK the iPhone displays use DSI (MIPI Display Serial Interface) but the 
GTA02/04 panel is 24 bit RGB parallel. So you need a data and signal converter 
chip. Toshiba makes some but these are difficult to get and understand and 
program.

> 
> Would I need another driver or just make some adjustments in the existing 
> one? Would it be possible to connect it at all? Do standards exist in display 
> connectors or are they all proprietary?

You need a different driver. Although there are informal (e.g. RGB-TTL) and 
formal standards (e.g. MIPI-DSI) they only define a framework and each panel is 
still different and needs a different control sequence.

So in summary: yes, it is possible and has been done. But you should search for 
a matching panel instead of choosing one and trying to interface it.
http://www.panelook.com may help.

> 
> Thanks for you insights,
> 
> Oliver

BR,
Nikolaus


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

[Community] Running a mainline kernel on a cellphone [LWN.net]

[H. Nikolaus Schaller]

Interesting to read.



If you have an LWN account, please comment that the GTA04 is already running 
4.3-rc7
and 4.3 next week... So there is one community/project/vendor who does 
everything
except following economical wisdom...

BR,
Nikolaus

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

Re: [Community] Make Munich 16./17. Januar 2016

[H. Nikolaus Schaller]

Hi,

Am 18.10.2015 um 18:56 schrieb wonderph...@posteo.de:

> Hi all,
> 
> Do you think it makes sense to inform makers on the Munich maker fair about
> 
> GTA04 phones?

yes sure! Please go ahead.

> 
> There will be not only hardcore hackers but a lot of people who need this 
> information and are open for it.

Lukas and me did visit last year and it was really impressive. From people 
making aluminium hats to
protect agains eavesdropping of a turned off mobile phone without battery up to 
a guy who developed
his hand-operated injection moulding machine. And a lot of toys and kits for 
students to learn something
about electronics.

The talks were also interesting, but more a self-presentation by the component 
distributors who support
"makers", e.g. Conrad, Bürklin and others.

BR,
Nikolaus

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

[Community] Letux 4.3-rc5

[H. Nikolaus Schaller]

Hi,
we have Letux 4.3-rc5 available:

http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/4.3-rc5

Significant changes are for the OpenPandora:
* WLAN is now working :)
* it boots from MMC again (there is still an unresolved issue with MMC CD and 
WP so they are simply disabled)
* letux_defconfig enables RTL8152/3 Ethernet USB adapters which helps testing 
USB ports and devices

Unfortunately, charging is still broken.

Please also note the feature branches (rebased to 4.3-rc5):

work/hns/omapdrm - which adds omapdrm X11 config and setup
work/hns/pm - which adds the measure-suspend scripts from Neil Brown

Maybe they can be integrated soon.

Please use, test, contribute, donate to support this project.

And, if you are missing other devices that should be supported by the Letux 
Distribution,
please let us know.

Currently these are:

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

BR,
Nikolaus

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

Re: [Community] [Gta04-owner] GTA04 power management

[H. Nikolaus Schaller]

Hi all,
I have fixed some minor issues in the Letux 4.3-rc5 release and now it is 
possible
to boot (again) on the OpenPandora.

I have also adapted the measurement script so that it uses the bq27500 inside 
the
pandora:

http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/measure-suspend;h=95f9ebcba688f91002b2da72bbc03f7dfcf1f82d;hb=dae7865eff2e4ce9a2c8375e5f11e2fcb2b8fde6

Setup:
* OpenPandora 600MHz
* external RS232 (level shifter is externally powered so ther eis no need and 
mechanism to turn it off)
* one LED enabled
* USB cable connected
* display backlight is turned off
* Letux 4.3-rc5 (branch work/hns/pm with omapdrm)
* WLAN turned off (ifconfig wlan0 down)
* boot from MMC

The two results are:

72240 uA over 299 seconds
84000 uA over 300 seconds

So I would conclude that it is more likely that some component on the SoC is 
not disabled correctly.
Or are MMCs generally not powered down? But they do not draw 50mA in standby 
mode (no clock).

BR,
Nikolaus


Am 07.10.2015 um 10:06 schrieb H. Nikolaus Schaller <h...@goldelico.com>:

> Hi Neil.
> 
> Am 03.10.2015 um 05:16 schrieb Neil Brown <ne...@suse.de>:
> 
>> "H. Nikolaus Schaller" <h...@goldelico.com> writes:
>>> 
>>> Could you share a complete description of your setup? So that it is 
>>> reproducible?
>>> I.e. which kernel, which user space, command to suspend/wakeup, boot loader
>>> version, how you measure suspend current etc.
>>> 
>> My test board in a GTA04A3, though my GTA04A4 shows much the same sort
>> of numbers.
> 
> There shouldn't be big differences (some A3 boards may have an additional 
> LIS302)
> 
>> 
>> 
>> User space is Debian/testing ... possibly with a bit of
>> Debian/experimental (it is listed in my sources.list but I don't
>> remember why).
>> 
>> I have a few of my own tools running, but they are all idle while I test
>> power usage.
>> So screen is blank, sound is off, GPS is off etc.  There is no SIM card
>> and I haven't tried to access the GSM module at all.
>> 
>> I use the following script while connected to the serial console.
>> The script disables RS-232 (as the sucks several mA) and turns of the
>> power source (my board is powered via a 5V source on the 'AC' pins of
>> the serial connector).
>> Then it checks the battery, suspends for 5 minutes (default), wakes up
>> and checks the power usage.
>> I run that several times and discard the outliers.
>> 
>> With a 4.2 kernel at:
>>  http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/4.2-gta04
>> I get numbers like:
>> 
>> 46967 uA over 301 seconds
>> 46967 uA over 301 seconds
>> 46967 uA over 301 seconds
>> 46967 uA over 301 seconds
>> 46967 uA over 301 seconds
>> 46967 uA over 301 seconds
>> 46967 uA over 301 seconds
>> 46967 uA over 301 seconds
>> 47124 uA over 300 seconds
>> 47124 uA over 300 seconds
>> 47124 uA over 300 seconds
>> 47124 uA over 300 seconds
>> 47124 uA over 300 seconds
>> 47124 uA over 300 seconds
>> 47124 uA over 300 seconds
>> 47281 uA over 299 seconds
>> 47281 uA over 299 seconds
>> 47600 uA over 297 seconds
>> 
>> 
>> With the 3.7 kernel
>> http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/3.7-gta04
>> I get:
>> 
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21420 uA over 300 seconds
>> 21709 uA over 296 seconds
>> 23556 uA over 300 seconds
>> 23568 uA over 300 seconds
>> 36420 uA over 300 seconds
>> 36420 uA over 300 seconds
>> 
>> 
>> Disabling the RS-232 doesn't work on my 3.7 kernel (because the required
>> GPIO isn't exported by the board file) so I have to unplug the RS-232 to
>> get proper reading there, but I could easily fix that.
>> 
>> I'd be interested to hear what other people measure.
> 
> I have run a quick test with our Letux 4.3-rc4 kernel (on a GTA04A3 with
> broken WiFi) and get readings ~170-190 mA.
> 
> Well, this is with backlight still enabled (we have no proper config for
> that in our tree - it remains "white") and the red power button LED stays
> on.
> 
> Backlight needs ~20mA@18V which translates to ~100 mA (depends
> on battery voltage). So this means the core goes down to less than
> 70 - 90mA.
> 
> And, I did not take care of turning off everything yet. Just a first test.
> 
> Subtracting the red LED and some 

Re: [Community] Will Neo900 ship before the end of this year?

[H. Nikolaus Schaller]

Hi Ryan,

Am 18.11.2015 um 20:06 schrieb Ryan de Laplante (Personal) 
<r...@ryandelaplante.ca>:

> 
> 
> On 2015-11-18 12:43 PM, H. Nikolaus Schaller wrote:
>> 
>> Well, I don't believe such conspiracy :) The Neo900 project is too small to 
>> start such activities by any government. Would be too much recognition for a 
>> small project. They would have to pay a team of investigators and updating 
>> such lists...
>> 
>> And, there are more effective means of stoping a project than making Paypal 
>> apply their "standard procedure" to limit accounts. For example they could 
>> have frozen it completely.
>> Additionally, there are payment methods to continue without Paypal.
>> 
>> Basically, there are hundreds of stories of people having similar issues 
>> (limited account) floating around and I would have to add my own one...
>> So it is more a fight with Paypal policies which are more restrictive and 
>> unpredictable than normal banks and credit card merchant accounts. Because 
>> they are *not* a real bank.
>> 
>> AFAIK Joerg has asked a lawyer for help.
>> 
>> And more generally, western democracy has rules for electronic and radio 
>> devices which are defined by EN and FCC standards everyone can study. They 
>> don't change over night on a case by case basis. As long as the Neo900 
>> fulfills them it can have everything like separate chips, watchdog, free 
>> software apps etc. All those are not directly forbidden in any such 
>> certification rules. The only thing that is forbidden is to operate it 
>> without fulfilling the approval requirements.
>> 
>> That is for example the FCC 5GHz WLAN discussion. They don't really care 
>> about software or firmware and open or closed. What they care about is that 
>> it must be made sure that all devices in operation have the same 
>> characteristics as the one that passed the approval measurements and can't 
>> transmit on frequencies that are assigned to different radio systems. As 
>> long as this can be guaranteed by open software there is no problem with 
>> FCC. Unfortunately it isn't, if the WLAN chip is baseband only and the 
>> firmware can be replaced or configured differently. Of course with closed 
>> software it is easier to prove that it can't be changed.
> 
> 
> Interesting, I didn't know the issue was PayPal's "standard procedure" to 
> limit accounts.

They do their way of "risk management". This appears to require that merchants 
can ship goods from stock. Otherwise, customers can complain with PayPal or 
their credit card company that they did not receive the goods. Then, the 
transaction is in dispute and the merchant must pay back the money. At least as 
a security deposit. Until the case is cleared.

Paypal simplifies their own life. As soon as they get a hint that goods are not 
shipped (and a down payment is easy to identify), they keep back a big portion 
of the funds they would have to pay to the merchant. So that they can easily 
withstand any disputes and they don't have to get the money back from a 
fraudulent merchant. To some extent it is even understandable what they are 
doing because they don't know the merchant well.

The main problem is that it comes unexpected and ist is difficult to discuss it 
with them. And it is not even possible that the Neo900 customers can waive 
their rights to complain and explicitly confirm that they want to pass the 
money as risk money and they understand the risks. Paypal does not even listen 
to that. They follow their rules.

But, they are not a bank and their account is not a bank account (where you as 
the account owner have a lot of rights and the bank is just a trustee).

> 
> BTW I wasn't talking about FCC regulations. I meant the NSA and GCHQ type 
> people possibly not wanting the Neo900 on the market.  From their 
> perspective, they might wonder why anyone would care enough about the modem 
> that they would design a new phone that keeps it separate and monitors it 
> with a watchdog. That is the primary feature that distinguishes the Neo900 
> from all other "smartphones".

Well, they do not need to care about the handheld. As soon as you do some phone 
call, the network can be tapped and trace what you are doing.
As soon as your Neo900 is registered with a network they can catch and track 
the IMSI and your location. This is not detectable by any hard/software at the 
handheld end (as long as it passes the certification rules which include a 
check that the IMEI and other things can not be manipulated - this is where FCC 
regulations help them and come into play).

> 
> A while ago I saw a TV show call people who care about such things "privacy 
> terrorists&quo

[Community] About cost and business models for community hardware

[H. Nikolaus Schaller]

Hi all,
quite a while that there was the last discussion.

So let me start one by jumping into this topic:



There, people heavily discuss if a Pyra must be as cheap as possible - or if it 
must allow to
cover expenses and a business model that even gives shareholders a profit and 
is necessarily
more expensive than devices built in millions of units.

It appears to me that all mobile devices you can currently get, follow a 
“profit” model which
also means that they have to cut cost where they can to stay competitive (“… 
there is always
one who makes the same, but cheaper”).

The result is what we know:
a) cheap as crap devices without any openness (because being open adds efforts 
and therefore cost)
b) leading edge high cost devices without any openness (because being open 
allows a) to become better)

And in all offerings, the user is only needed to pay for the device and accept 
what is given to him/her.
An exception may be the Fairphone - but even they have 25 EUR (?) for paying 
their developers and managers.

So what is your opinion?

Should our projects be “profitable” or more be a “charity” based on volunteer 
work?

BR,
Nikolaus

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

[Community] GTA04A5 production status

[H. Nikolaus Schaller]

Hi all,
good news!

I have received the final quotation and we are ready to place the final order 
at the production
company (http://www.global-components.de) on Monday.

All production data (gerber files, material list etc.) is available so it only 
depends on their production
schedule.

We will produce 20 units in a first step (to verify that production and A5 
hardware and layout changes
work) and then another run (hoping that it does not need anything to be redone).

Another good news is that we can offer a new camera module that appears to be 
compatible.
Will be made available soon in our shop.

Finally, our workshop last weekend was successful and is a basis that we will 
see new software
(QtMoko2) soon.

So please if you consider to get a GTA04A5 / Letux 2804 (or have preordered but 
not yet paid fully),
please do an order now:

http://shop.goldelico.com/wiki.php?page=GTA04%20Complete
http://shop.goldelico.com/wiki.php?page=GTA04

Just to remind what the GTA04 / Letux 2804 is: it is a smartphone produced by 
the community for
the community that is as open as currently feasible to allow you to tinker 
around with software or do
hardware extensions.

New features of GTA04A5:
* 1GHz DM3730
* 1GB RAM
* 512 MB OneNAND
* new WiFi chip (2.4 GHz and 5.8 GHz) with Bluetooth 4.1
* some sensors modernized (BMC150, BMG160, BMP280)
* new camera module
* should allow for even deeper power states in suspend than before
* USB-OTG and GPS antenna plugs soldered differently so that it is more 
difficult to break them off
* other hardware fixes and improvements

Thank you,
Nikolaus

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

Re: [Community] [Gta04-owner] GTA04A5 RAM + NAND size

[H. Nikolaus Schaller]

Hi Jonas,

> Am 03.06.2016 um 23:03 schrieb Jonas Smedegaard <d...@jones.dk>:
> 
> I just stumbled upon this old post:
> 
> Quoting H. Nikolaus Schaller (2015-11-28 20:08:01)
>> Another (probably easier to solve) issue for the 1GB + 512MB is that 
>> we want to provide some default Linux+Debian+LXDE (or something else) 
>> in NAND for all GTA04A5 boards we ship. So that you have something to 
>> boot into before partitioning and even buying any µSD card.
>> 
>> Unfortunately we have not yet managed to squeeze Wheezy nor Jessie 
>> images so that they fit into ~450 MB. They end up with ~800 MB.
>> 
>> Therefore they would easily fit into the 512MB + 1GB chips, but not in 
>> the 1GB + 512MB.
>> 
>> If someone has an idea how to strip it better down than this script, please 
>> let
>> me know:
>> 
>> <http://git.goldelico.com/?p=gta04-rootfs.git;a=blob;f=config/root/flash-nand;hb=refs/heads/master>
>> 
>> (this script already strips unneeded kernel modules and most debian 
>> caches).
> 
> Above script starts with the following comment:
> 
>  "clone the currently running system to NAND"
> 
> I suspect the place to save more space is in looking into which packages 
> gets installed.  Do you have the script to _create_ the system that I 
> can examine and tweak?

Basically:

http://git.goldelico.com/?p=gta04-rootfs.git;a=blob;f=config/root/bootstrap;h=1b9ef7784898e08bf0bcf41ce98f718435f99453;hb=refs/heads/master

and then

http://git.goldelico.com/?p=gta04-rootfs.git;a=blob;f=config/root/useful;h=849262736df0ce6067c2f7c9766d729b0879663e;hb=refs/heads/master

The first script debootstraps a new image (either running on a real GTA04 or in 
qemu) into a chroot rootfs.
This image boots but has no GUI and lacks important tools. This is pulled off 
the rootfs (by tar czf ...) and
results in e.g.

http://download.goldelico.com/letux-debian-rootfs/

20150928-jessie-8.2-minimal.tbz 2015-09-28 09:4776M

The second script adds useful things incl. X11 and LXDE or XFCE4. The result is 
e.g.

20150928-jessie-8.2-lxde.tbz2015-09-29 00:05231M

So what is blowing up by factor 3 is X11 + GUI.

Nand flashing is done by the script cited above by trying to copy but prune 
parts of
this (running) system from µSD root to NAND root.

I can explain more details later on our workshop.

See you in <2 hours,
Nikolaus

> 
> 
> - Jonas
> 
> -- 
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
> [x] quote me freely  [ ] ask before reusing  [ ] keep private
> ___
> Community mailing list
> Community@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.openphoenux.org

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

Re: [Community] Report on QtMoko

[H. Nikolaus Schaller]

Hi,

> Am 14.06.2016 um 16:41 schrieb Josua Mayer :
> 
> Greetings to all of you,
> 
> I present to you my results from the hacking weekend:
> I was working on making it easy to start hacking on QtMoko.
> 
> 0) Prelude
> I intended to make actual debs available, but I have yet to find time
> uploading these huge things. For the moment packages will have to be
> built from source, as to the instructions in the new repositories linkd
> below.

Great work!

> 
> 1) Kernel: http://projects.goldelico.com/p/qtmoko2-kernel/page/README/
> There is now an easy way to build a kernel deb from whatever release our
> kernel hackers deem stable. It is meant to be unpacked on top of a fresh
> rootfs.
> The idea is that this rootfs should at this point be bootable. However
> currently a custom bootargs.scr is required to facilitate looking for
> the DeviceTree files in /boot/dtb/. Please find a sample script attached
> to this mail.
> 
> As you will notice, I did not override bootcmd, but instead manually
> implemented the boot procedure. This is not perfect. Ideally this
> bootargs.scr would only override the u-boot environment variable that
> currently has / and /boot hardcoded as valid sources for DTBs. Feel free
> to provide improvements should you find any.

This will change with latest U-Boot. bootscr is deprecated there and uEnv.txt
will provide just the device tree name.

An example can be seen here fore the Pyra:

http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=Letux/boot-scr/uEnv-pyra%2Blc15.txt;h=ea46c1e9b58eb7e1ab09b0c929ee079a5e86b72a;hb=refs/heads/work/hns/letux-extensions

But all this can be fixed when U-Boot is upgraded at some point in the future
(which needs a little more to be done for the GTA04 to provide touch screen
interface within u-boot).

> 
> 2) Qt-Embedded: http://projects.goldelico.com/p/qtmoko2-qte/page/README/
> First, to avoid any confusion: Qt-Embedded is just Qt, but built to
> directly draw on the Framebuffer instead of using any of the available
> Window Systems of this Universe.
> I picked version 4.8.7 as starting point because this one is the latest
> stable release of the 4.8 series that QtMoko currently uses.
> My goal was to provide Qt as a standalone framework to then later build
> QtMoko components against it.
> This direction is completely opposite to QtMoko, which has tried to
> accumulate every component and library into a single monolithic system.
> 
> Currently the Qt-Embedded deb installs itself into /opt in order to not
> mess, or conflict with the non-embedded Qt variant provided by Debian.
> There are demos installed to /opt/qt-embedded/examples, and I did try
> out a few of them. They appeared to work properly, but there is a
> problem with touchscreen input:
> When touching the screen, Qt properly detects a mouse-press at the right
> location of the screen. But then when moving the pointer, it runs away
> in a non-linear fashion.
> I later concluded that it looks like this:
> pos_new = new_absolute_coordinates + distance_to_last_position
> This is a serious issue and needs investigating. We suspect that the
> Qt-Embedded LinuxTP mouse driver is doing something nasty!
> 
> If you want to play around with it, this is how:
> # set up environment
> export PATH=/opt/qt-embedded/bin:$PATH
> export LD_LIBRARY_PATH=/opt/qt-embedded/lib:$LD_LIBRARY_PATH
> export QWS_MOUSE_PROTO=linuxtp:/dev/input/touchscreen
> cd /opt/qt-embedded/examples
> # try out whatever example you like, and dont forget to pass the -qws
> commandline option
> 
> 3) QtMoko itself
> Sadly, besides having a perl programmer do a quick scan of its configure
> script, we ran out of time before making any notable progress.
> There are now 2 optiosn for next steps:
> a) try to make QtMoko build itself against the standalone Qt-Embedded,
> WITHOUT rebuilding it as part of the qtmoko build
> b) identify core components of QtMoko and build them individually
> 
> Thats it for now, as mentioned above you can expect an apt repository to
> be made available soon(TM).
> 
> best regards
> Josua Mayer

BR and thanks again,
Nikolaus


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

Re: [Community] [Gta04-owner] Report on QtMoko

[H. Nikolaus Schaller]

Hi,

> Am 15.06.2016 um 13:48 schrieb Jonas Smedegaard <d...@jones.dk>:
> 
> Quoting Josua Mayer (2016-06-15 13:07:56)
>> Am 15.06.2016 um 06:45 schrieb H. Nikolaus Schaller:
>>> Am 15.06.2016 um 00:33 schrieb Jonas Smedegaard <d...@jones.dk>:
>>>> Quoting Josua Mayer (2016-06-14 16:41:23)
>>>>> I intended to make actual debs available, but I have yet to find
>>>>> time uploading these huge things. For the moment packages will have
>>>>> to be built from source, as to the instructions in the new
>>>>> repositories linkd below.
>>>>> 
>>>>> 1) Kernel: http://projects.goldelico.com/p/qtmoko2-kernel/page/README/
>>>> 
>>>> Seems to me a more appropriate name would be gta04-kernel.
>>> 
>>> Well, "gta04-kernel" already exists and is the project for the kernel
>>> source. But it should be renamed to Letux kernel (which is the
>>> official project name).
>>> 
>>> And we have to keep in mind that kernel is not only for the gta04
>>> device but also for others like openpandora and pyra (just by picking
>>> a different device tree file). I don't know if you want to have 10
>>> slightly different kernel packages for 10 devices or a single one
>>> that runs on all (just having different u-boot setup). The latter is
>>> what we use for some time for LXDE/XFCE and Replicant and I do not
>>> see a need to go back.
>>> 
>>> On the other hand I agree that qtmoko2-kernel is also not exactly
>>> right.
>>> 
>>> A better name could be debian-kernel but that is also wrong.
>>> 
>>> The best description would be some abbreviation of:
>>> 
>>> kernel-for-letux-project-for-many-devices-but-not-all-packaged-for-debian
> 
> Ok, so scope is the whole _family_ of Letux devices, not (the GTA04
> board of) Letux 2604 as I thought.
> 
> Then the in my opinion most appropriate name is letux-kernel.
> 
> 
>>>>> There is now an easy way to build a kernel deb from whatever
>>>>> release our kernel hackers deem stable. It is meant to be unpacked
>>>>> on top of a fresh rootfs.
>>>> 
>>>> Great!
>>>> 
>>>> I have improvements - at first to the README, to use only pure
>>>> Debian, not need the (derivative of Debian) emdebian, but I may
>>>> stumble upon other details I can polish.
>> If you have good instructions for that, sure. I thought emdebian was
>> still required to get the prebuilt cross-compiler.
> 
> Emdebian is needed only with Jessie, not Stretch onwards.
> 
> Assuming your end goal is inclusion in _Debian_ I would change the
> documentation to talk about pure Debian by default now that is possible,
> and mention workaround for Jessie and older only as a comments, to
> clearly discourage use of that moving forward, and ease later cleanup.
> 
> 
>>>> Can I please get write access to that repo, or should I rather post my
>>>> proposed changes here for screening/discussion/whatever?
>>> 
>>> You already should have...
>> I believe this depends on how ripe your improvements are. At some
>> point they are bound to hit me on the head, and this is when you
>> should just commit them imo.
> 
> Not sure what you mean by that.  To be on the safe side I will *not*
> touch that git until clarified that you consider it a help that I do so.
> (but since mailinglist discussion is more tedious than git edits, I will
> likely contribute _less_).
> 
> 
>>>>> Thats it for now, as mentioned above you can expect an apt
>>>>> repository to be made available soon(TM).
>>>> 
>>>> As I mentioned also at our meeting, I would be happy to either host
>>>> that APT repo or help set it up, if that is of interest.
>> I have no objections here, whichever is easiest to upload either
>> source- or binary packages to I guess.
>>> 
>>> Since I am not sure how easy it is to set up write access for an apt
>>> repo on the goldelico server (this is outside of the project
>>> management tool), it would be a good idea to host it where the
>>> infrastructure exists.
>>> 
>>> Some things to think about:
>>> * a different server needs to manage developer login twice
>>> * ideally users would add some www.qtmoko.net path to /etc/apt/source.list
>>> * so we need to add a forwarding link
> 
> APT does not support http 301/302 redirection,

Hm. That is bad luck ...

> so if branding is important,

Re: [Community] [Gta04-owner] Report on QtMoko

[H. Nikolaus Schaller]

> Am 15.06.2016 um 14:42 schrieb Josua Mayer <josua.maye...@gmail.com>:
> 
> 
> 
> Am 15.06.2016 um 14:10 schrieb H. Nikolaus Schaller:
>> Hi,
>> 
>>> Am 15.06.2016 um 13:48 schrieb Jonas Smedegaard <d...@jones.dk>:
>>> 
>>> Quoting Josua Mayer (2016-06-15 13:07:56)
>>>> Am 15.06.2016 um 06:45 schrieb H. Nikolaus Schaller:
>>>>> Am 15.06.2016 um 00:33 schrieb Jonas Smedegaard <d...@jones.dk>:
>>>>>> Quoting Josua Mayer (2016-06-14 16:41:23)
>>>>>>> I intended to make actual debs available, but I have yet to find
>>>>>>> time uploading these huge things. For the moment packages will have
>>>>>>> to be built from source, as to the instructions in the new
>>>>>>> repositories linkd below.
>>>>>>> 
>>>>>>> 1) Kernel: http://projects.goldelico.com/p/qtmoko2-kernel/page/README/
>>>>>> 
>>>>>> Seems to me a more appropriate name would be gta04-kernel.
>>>>> 
>>>>> Well, "gta04-kernel" already exists and is the project for the kernel
>>>>> source. But it should be renamed to Letux kernel (which is the
>>>>> official project name).
>>>>> 
>>>>> And we have to keep in mind that kernel is not only for the gta04
>>>>> device but also for others like openpandora and pyra (just by picking
>>>>> a different device tree file). I don't know if you want to have 10
>>>>> slightly different kernel packages for 10 devices or a single one
>>>>> that runs on all (just having different u-boot setup). The latter is
>>>>> what we use for some time for LXDE/XFCE and Replicant and I do not
>>>>> see a need to go back.
>>>>> 
>>>>> On the other hand I agree that qtmoko2-kernel is also not exactly
>>>>> right.
>>>>> 
>>>>> A better name could be debian-kernel but that is also wrong.
>>>>> 
>>>>> The best description would be some abbreviation of:
>>>>> 
>>>>> kernel-for-letux-project-for-many-devices-but-not-all-packaged-for-debian
>>> 
>>> Ok, so scope is the whole _family_ of Letux devices, not (the GTA04
>>> board of) Letux 2604 as I thought.
>>> 
>>> Then the in my opinion most appropriate name is letux-kernel.
>>> 
>>> 
>>>>>>> There is now an easy way to build a kernel deb from whatever
>>>>>>> release our kernel hackers deem stable. It is meant to be unpacked
>>>>>>> on top of a fresh rootfs.
>>>>>> 
>>>>>> Great!
>>>>>> 
>>>>>> I have improvements - at first to the README, to use only pure
>>>>>> Debian, not need the (derivative of Debian) emdebian, but I may
>>>>>> stumble upon other details I can polish.
>>>> If you have good instructions for that, sure. I thought emdebian was
>>>> still required to get the prebuilt cross-compiler.
>>> 
>>> Emdebian is needed only with Jessie, not Stretch onwards.
> I see. Well that is a relieve!
>>> 
>>> Assuming your end goal is inclusion in _Debian_ I would change the
>>> documentation to talk about pure Debian by default now that is possible,
>>> and mention workaround for Jessie and older only as a comments, to
>>> clearly discourage use of that moving forward, and ease later cleanup.
>>> 
>>> 
>>>>>> Can I please get write access to that repo, or should I rather post my
>>>>>> proposed changes here for screening/discussion/whatever?
>>>>> 
>>>>> You already should have...
>>>> I believe this depends on how ripe your improvements are. At some
>>>> point they are bound to hit me on the head, and this is when you
>>>> should just commit them imo.
>>> 
>>> Not sure what you mean by that.  To be on the safe side I will *not*
>>> touch that git until clarified that you consider it a help that I do so.
>>> (but since mailinglist discussion is more tedious than git edits, I will
>>> likely contribute _less_).
> What I mean is simple: If:
> a) the change is tested
> b) you dont feel like there is a need to discuss potential alternatives
> feel free to commit.
> I did consider a pull-request approach, but that is really pointless as
> long as there are so few people working on this tree.
>>> 
>

Re: [Community] [Gta04-owner] Report on QtMoko

[H. Nikolaus Schaller]

> Am 15.06.2016 um 15:10 schrieb Jonas Smedegaard <d...@jones.dk>:
> 
> Quoting H. Nikolaus Schaller (2016-06-15 14:10:34)
>> Am 15.06.2016 um 13:48 schrieb Jonas Smedegaard <d...@jones.dk>:
>>> Quoting Josua Mayer (2016-06-15 13:07:56)
>>>> Am 15.06.2016 um 06:45 schrieb H. Nikolaus Schaller:
>>>>> Since I am not sure how easy it is to set up write access for an
>>>>> apt repo on the goldelico server (this is outside of the project
>>>>> management tool), it would be a good idea to host it where the
>>>>> infrastructure exists.
>>>>> 
>>>>> Some things to think about:
>>>>> * a different server needs to manage developer login twice
>>>>> * ideally users would add some www.qtmoko.net path to
>>>>>  /etc/apt/source.list
>>>>> * so we need to add a forwarding link
>>> 
>>> APT does not support http 301/302 redirection,
>> 
>> Hm. That is bad luck ...
>> 
>>> so if branding is important,
>> 
>> yes I think it is important. Small plants need a well defined home to
>> keep all parts together.
>> 
>> if we have a qtmoko.net home page downloads should come from the same
>> domain (until they are some day part of ftp.debian.org).
>> 
>>> then either services need to be established at your own hosts or
>>> "forwarding" means entries in domain name system.
>> 
>> Well, I can create a subdomain debian.qtmoko.net and direct it to
>> whatever IP address the server is sitting on.
>> 
>> At least in theory.
>> 
>> In practice the qtmoko domains are hosted in a package that does not
>> allow subdomains - but it can (an IMHO should) be changed (by paying
>> some one-time transfer fee...).
> 
> Why qtmoko.net?  Is this specific to qtmoko packages?

Puzzled...

We are discussing how to get QtMoko on top of Debian, aren't we?
And for that purpose we need a clearly distinguished apt repo.

In my view we are not missing Kernel or Debian for GTA04 but QtMoko
for Debian...

And QtMoko could be interesting for other projects/communities as well,
e.g. Maemo. Or Debian desktop...

So to clarify:

- QtMoko is a GUI software project using Qt on top of Debian
- Letux is a brand name for hardware by Goldelico
- Letux is also a Linux Distro (based on Debian) for portable devices (that is 
how it was created >10 years ago for an Acer n30 PDA)
- OpenPhoenux is our community where we can meet, discuss, have fun, create new 
ideas, ...
- Goldelico is a company - and just 1 member of the community

> 
> I suggest to setup a) deb.goldelico.com now, and consider working

Well, http://download.goldelico.com/quantumstep/debian/dists/ already exists.

This is not created by debian tools (and therefore packages are not signed and
not all features of apt are supported, e.g. no difference files).

Of course, the variants need some renaming to harmonize with Debian.

I could rewrite the scripts in a way that they are run by cron, and perhaps even
sign them automatically. So just uploading a new .deb could be recognised a 
little
later.

> towards b) deb.openphoenux.org when the community controls its domains
> and machines (not Golden Delicious, but perhaps sponsored by them).

I think we need to set up a repo that works with any name...
Then we can rename things.

> 
> 
>>> Most elegant setup involves root access (involves juggling low-port
>>> services, cron jobs, and installation of tools).  Can I be granted
>>> root on your server
>> 
>> No. There are other confidential projects running on the same server.
>> This is why I thought to run it on a different server and just
>> redirect the domain.
> 
> I am happy for that response - it means you care about security :-D

Sure.

> 
> 
>>> to set it up, or do I need to proxy all changes through someone else
>>> (read: more bothersome)?
>> 
>> Well, that might still be easier than all other setups.
> 
> Well, it sure is easier for me: I will then simply suggest you to follow
> this: https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro
> 
> When done (and you are not exhausted by then)

doesn't look difficult. The main task is to set up a virtual machine
on the server to run Debian on it... So please do not expect that it is
done in the next days or weeks. This is why using an existing apt
server and just redirecting the domain would be easier.

> , I can try isolate and
> explain details I did differently for my https://deb.jones.dk/

BR,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Community mailing list
Community@openphoenux.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.openphoenux.org

Re: [Community] PayPal issue update

[H. Nikolaus Schaller]

Hi Ryan,

> Am 21.03.2016 um 14:57 schrieb Ryan de Laplante (Personal) 
> :
> 
> I noticed the "uBlog" section of neo900.org says:
> 
>> Finally our PayPal trouble timed out, so we can focus again on making 
>> proto_v2. http://talk.maemo.org/showthread.php?p=1496288
>> Joerg, 2016-01-26 12:48:52
> 
> Can someone please confirm that the funds have been fully released and paid 
> out?   If that's the case then maybe the first news item shown on neo900.org 
> can be updated so that it doesn't start with "PayPal trouble delays project". 
>   Maybe a new news item can be written with an updated schedule and timeline. 
> I've been holding off buying my next phone for a while and am wondering if it 
> will be another 1 - 2 years before the Neo900 is shipped.

unfortunately, I can't comment on funds, schedules and timelines of Neo900.

But I can share this:
Jörg asked a while ago if we can now do the PCB layout and build the next 
prototype right after he solved the paypal issue.
Unfortunately, GDC is currently 120% busy polishing the Pyra hardware for mass 
production and other tasks are also far
behind schedule (e.g. the GTA04A5 schedule also suffers from the same lack of 
capacity).

Therefore, I had to decline to do anything immediately and could only offer to 
continue in third or fourth quarter of this year.

To speed things up, I also suggested that he himself continues to finish the 
schematics and PCB layout (I think he also had
bought an EAGLE licence). Or he converts the data into KiCAD format. Whatever 
is more appropriate to produce Gerber files.

If he comes up with final Gerber data, I can help to get some samples produced 
(we have a soldering machine optimally suited for
such fine-pitch BGA prototyping tasks). This is work for only a handful of 
days, which can always be inserted between other things.

So our bottleneck is that we have no spare capacity for finishing complete 
schematics and PCB layout in the near future.

BR,
Nikolaus


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

Re: [Community] [Gta04-owner] OpenPhoenux Letux/GTA04 Kernel- and Userspace-Hacking weekend

[H. Nikolaus Schaller]

Hi Xavi,

> Am 25.04.2016 um 13:09 schrieb Xavi Drudis Ferran <xdru...@tinet.cat>:
> 
> El Mon, Apr 25, 2016 at 11:54:19AM +0200, H. Nikolaus Schaller deia:
>> 
>> But I have no idea if the on-screen keyboard can be rewritten in a way that 
>> it works with all other GUI applications (not necessarily Qt based!). You 
>> would get a problem if you have network-manager and can't type IP 
>> addresses... So this might be a big challenge (who doesn't love challenges?).
>> 
> 
> I don't really know. But I took a look at the qtmoko keyboard a year
> or two ago (I hardly remember any detail) and got the impression that
> not as it is. But then I don't know anything that could do that. In X
> it is easier, I think. But without X what is the abstraction for a
> keyboard this application should plug into ?

Good question.

> Should there have to be a
> keyboard driver in the kernel or something? Should it pass as a tty ?

That would be an interesting approach. Or we use a pty (or mkfifo) and
symlinks to present a virtual /dev/event node where the keyboard process
can write to...

But I am not sure if X11 will find it because it likely scans /sys for input
devices and not /dev.

Another idea: the X11 protocol has a mechanism that an application can
send keyboard events to the X11 sever. The application that currently
has the focus should then receive them.

> Where does network-manager get it's keystrokes from ?

Looks like something that needs to be analysed. Fortunately it is open
source... Otherwise we would not have any chance.

> I don't know how
> many front-ends for network manager there are...
> 
> The Qtmoko keyboard was simpler that X with compose keys and all the
> possibilities to generate characters combining keys (that would be
> wellcome but wasn't there).

I hope that the team can study that before we meet for the workshop.

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

Re: [Community] [Gta04-owner] QtMoko Input Methods (Was: OpenPhoenux Letux/GTA04 Kernel- and Userspace-Hacking weekend)

[H. Nikolaus Schaller]

Hi,

> Am 25.04.2016 um 22:10 schrieb Xavi Drudis Ferran <xdru...@tinet.cat>:
> 
> El Mon, Apr 25, 2016 at 09:46:21PM +0200, Josua Mayer deia:
>> It appears to me that QtMoko was using the inputmethod functionality
>> provided by QT and just implemented the onscreen keyboard on top. Check the
>> code for it below:
>> https://github.com/radekp/qtmoko/tree/master/src/plugins/inputmethods/fingerkeyboard
>> 
>> So the current abstraction is InputMethod. And that should be operative no
>> matter which window-system QT was built for.
> 
> Yes, but I'm a bit lost. Didn't you want something you could use without Qt ?
> Or I misunderstood ? I'm not sure I know what the goal is now. 

I think we are still discussing the goal :)

The overall goal of QtMoko.net is to get a new and modernized QtMoko.

A subgoal is to have a good touch keyboard.

Depending on whether we

simply make QtMoko build again (a)
or port/rewrite it to be based on Qt5 libraries (b)

we either can use the existing touch keyboard code or have
to find something new (for b).

> 
> In fact I think QWSInputMethod is specific to Qt-Embedded in particular. 
> I think (but haven't looked) it is not in Qt for X11, for example. 
> 
> http://doc.qt.io/qt-4.8/qwsinputmethod.html

Yes, that is QtE only. And

"A Qt for Embedded Linux application requires a server application to be 
running, or to be the server application itself. All system generated events, 
including keyboard and mouse events, are passed to the server application which 
then propagates the event to the appropriate client."

> 
> I mean when you said: 
> 
> El Mon, Apr 25, 2016 at 11:54:19AM +0200, H. Nikolaus Schaller deia:
>> 
>> But I have no idea if the on-screen keyboard can be rewritten in a
>> way that it works with all other GUI applications (not necessarily Qt
>> based!). You would get a problem if you have network-manager and
>> can't type IP addresses... So this might be a big challenge (who
>> doesn't love challenges?).
> 
> I thought you mean to take the logic in the qtmoko keyboard and
> change the inputmethod for some other more widely available keyboard 
> abstraction. 

The problem is that there is no really widely available abstraction.
The most common denominator are the input events of the kernel.

All GUI libraries (Qt, GTK, wxWidgets, Xlib etc.) provide their own.

This is not a problem for standard applications that use an existing
system keyboard, like a desktop / notebook.

The problem I see arises if we want to present context dependent
keyboard layouts like it is done on other mobile OS. This would
mean that an application can send information to the keyboard
process.

BTW: I have pushed a very simple Qt5 "hello world" application
that can be easily built on and runs on a GTA04:

http://git.goldelico.com/?p=gta04-qtmoko.git;a=commit;h=e480c6a059e95af52feda75f07a35302a7ff448a

BR,
Nikolaus

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

Re: [Tinkerphones] Status GTA04A5 and miscellaneous

[H. Nikolaus Schaller]

Hi,
I have two small updates.

> Am 26.07.2016 um 11:20 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
> 
> Hi,
> there isn't much to report at the moment about the GTA04A5.
> 
> We are still waiting for all components to arrive and the PCBs
> to be produced. Let's hope that no news is good news and
> cross fingers that it happens soon.

I have got a feedback that all components should arrive by
August 22th.

Except the headset jack. This is currently not in stock at the
manufacturer or distributors. Estimated delivery in October :(

Well, we don't want to wait that long and it looks as if there are
brokers who can get them for us.

> 
> On the software side we have published letux kernel 4.7.0:
> 
>   http://download.goldelico.com/letux-kernel/letux-4.7/
> 
> It fixes the hdq driver so that we can again read the fuel gauge and
> battery state of charge. This is essential to be able to measure
> suspend current.
> 
> Unfortunately we are still struggling with the charging system.
> 
> The symptoms are quite puzzling. On some devices charging
> seems to work. While on others it simply fails, does not recognize
> cable insertion/unplugging and the ethernet gadget fails as well.
> 
> But installing our letux 4.3 kernel on the same SD card and rebooting
> makes it work.
> 
> What the real mystery is: there is no significant code difference in
> the charger driver between 4.3 and 4.4-rc (where it fails for the
> first time). So the difference lies somewhere outside the charger
> driver but we have not yet found where.

Thanks to the help from Andreas, we have found what is going wrong
and developed a partial solution. The problem is that the charger driver
assumes that the usb driver enables the OTG interface. This includes
a prescaler for the VBUS measurement. This should become enabled
if a cable is inserted.

But it isn't.

This has the following consequences for the charger:
* VBUS virtually remains at 0mV (although available)
* the automatic charging mode detects an illegal state and turns off after some 
milliseconds
* the measurement for the battery NTC is turned of as well and hence we see 
only 56°C

We have developed a hack for this (enable the prescaler before starting
charging). This makes charging (and interestingly also the ethernet gadget)
work again, so that we can better debug other issues.

It does not solve the underlaying problem of course, where we also
know that during suspend the USB driver does not turn off correctly.
Therefore we are not yet back down to the 25mA suspend current
we did have in the 3.7 kernel.

If you are interested in the patch it is here:


http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=b8c538e75c6dd034889bdb0d66e00ca6e128e616

And the discussions:

http://lists.goldelico.com/pipermail/letux-kernel/2016-July/thread.html

BR,
Nikolaus

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

[Tinkerphones] ASN.1 vulnerability?

[H. Nikolaus Schaller]

Hi,
you may have read about an issue with ASN.1 compilers:


https://github.com/programa-stic/security-advisories/tree/master/ObjSys/CVE-2016-5080

I have contaced Gemalto/Cinterion and got the feedback
that Qualcom says they have the bug but it can't be used
for an exploit because they reduce some length value
before the overflow can occur:


http://www.pcworld.com/article/3099692/security/devices-with-qualcomm-modems-safe-from-critical-asn1-telecom-flaw.html

The Option GTM601 and the PHS8/PLS8 modules we
use in our projects are based on Qualcom network software
so that we are on the safe side.

As long as we believe Qualcom - but we have no choice
unless someone develops a 2/3/4G module from scratch
with open software and gets it certified for operation.

So it is up to you if you still are worried or not. I am not.

BR,
Nikolaus

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

Re: [Tinkerphones] Tinkerphones...

[H. Nikolaus Schaller]

> Am 20.07.2016 um 00:02 schrieb Andrew Schenck <and...@springahead.com>:
> 
> On 7/8/2016 8:28, H. Nikolaus Schaller wrote:
>> 
>>> Am 08.07.2016 um 09:53 schrieb Radek Polak <pson...@seznam.cz>:
>>> 
>>> On Thursday 07 of July 2016 20:54:59 Adrien Dorsaz wrote:
>>> > Currently I'm using a Samsung Galaxy SIII. I would like to use my GTA04
>>> > as
>>> > before, but it has again an issue with the USB port.
>>> > 
>>> > This time, when I plug the cable of the OpenMoko charger, nothing
>>> > happens.
>>> > Before my USB port was moving and my local electronic shop was able to
>>> > solder it again. Unfortunately, this time the USB port doesn't move, so
>>> > I'm not
>>> > sure if it is an issue on hardware or software.
>>>  
>>> I bought magnetic reduction for my N900's micro usb port. Works perfectly, 
>>> no worries about breaking USB anymore.
>>>  
>>> http://www.wsken.net/productsinfo.asp?id=30
>>>  
>> 
>> Cool!
>> 
>> We would need such a thing with Mini-USB for the GTA04...
> I bought one of the micro USB ones because it seems neat, but I've searched 
> around and there doesn't seem to be any mini USB version anywhere.
> 
> -Andrew

I have also found only micro USB. And there was a standard-USB socket "JabNab" 
10 years ago (I even own one - was a marketing gift).

But I think about designing one ourselves and offer in our shop. Will not be as 
elaborated and tiny, but it appears to be doable.
The basic idea is to make a small PCB, solder the front part of an opened 
Mini-USB plug to it. This can be plugged into the GTA04 side and should stand 
out max. 2-3. mm.
A second PCB with a full mini/micro USB socket and pogo pins can be attached to 
a standard cable. Both can be put in contact.
The main area for experimentation is how to find and attach small but strong 
enough magnets to this assembly.

So this will be amongst the next tinkering projects :)

BR,
Nikolaus

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

Re: [Tinkerphones] Tinkerphones...

[H. Nikolaus Schaller]

> Am 08.07.2016 um 09:53 schrieb Radek Polak :
> 
> On Thursday 07 of July 2016 20:54:59 Adrien Dorsaz wrote:
> > Currently I'm using a Samsung Galaxy SIII. I would like to use my GTA04
> > as
> > before, but it has again an issue with the USB port.
> > 
> > This time, when I plug the cable of the OpenMoko charger, nothing
> > happens.
> > Before my USB port was moving and my local electronic shop was able to
> > solder it again. Unfortunately, this time the USB port doesn't move, so
> > I'm not
> > sure if it is an issue on hardware or software.
>  
> I bought magnetic reduction for my N900's micro usb port. Works perfectly, no 
> worries about breaking USB anymore.
>  
> http://www.wsken.net/productsinfo.asp?id=30 
> 
>  

Cool!

We would need such a thing with Mini-USB for the GTA04...

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

[Tinkerphones] Tinkerphones...

[H. Nikolaus Schaller]

Hi all,
after we have renamed the community, let's try to get
into more discussions again as every community lives
from members.

I for example have to admit that I use an iPhone. A very
old one because it is mechanically compatible to the car kit
of my car...

Newer ones aren't and I would have to replace the car kit
cradle for additional money. And, Apple had changed
the connector so that I also would have to replace power
supply and other things as well.

So I have a reliable device that works. But it is outdated.
Most modern apps don't work because they require a
newer version of iOS. Which is not available for that old
hardware. Argh...

I am locked out because I am not willing to throw away
that old but still well working device and buy a new one.

It is not my first experience being in that situation.

Therefore I am for years running the GTA0x projects
and permanently pushing for new device hardware (it
is much more difficult than buying a new iPhone :) and
getting software projects like QtMoko back on the rails.

So I still dream of a device that is modern enough and
can be owned and operated as long as I like and get
software updates for a very long time. It is also supported
well enough so that I can even try to repair something.

And, I would like to see a uniform user interface across
all portable devices, desktop devices and even web
access.

But not only user interface but API and SDKs. Why shall I
write software for mobile, the same app for desktop
and provice web pages for mobile plus desktop? Four
different pieces of code! All incompatible in different
languages, toolkits and libraries, but doing all the same
for the users - just in different screen dimensions.

It is a dream and I haven't found that it is fulfilled anywhere.
Therefore I am continuously tinkering with GTA04, Letux
kernels, Pyra-Handheld, QtMoko, QuantumSTEP and all
the other activities.

What are your motivations and dreams and thoughts?

BR,
Nikolaus

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

[Tinkerphones] Fwd: [Replicant] Replicant blog post: Media from 2016 Replicant talks

[H. Nikolaus Schaller]

FYI.

> Anfang der weitergeleiteten Nachricht:
> 
> Von: WordPress 
> Betreff: [Replicant] Replicant blog post: Media from 2016 Replicant talks
> Datum: 9. Juli 2016 um 15:03:56 MESZ
> An: undisclosed-recipients:;
> 
> Read the blog post online: 
> https://blog.replicant.us/2016/07/media-from-2016-replicant-talks/ 
> 
> Various media, including slides and video recordings, from recent talks about 
> Replicant are available on the Replicant wiki Conferences 
>  page, 
> including :
> 
> FOSDEM 2016 
> 
>  (slides and video)
> Coliberator 2016 
> 
>  (slides)
> PSESHSF 2016 
> 
>  (slides and video)
> Some of these presentations are great ways to get an overview of the freedom 
> and privacy/security issues associated with mobile devices, either in English 
> or French. They also offer an introduction to Replicant within that context. 
> Other presentations cover specific technical aspects related to liberating 
> devices at the lower levels.
> 
> ___
> Replicant mailing list
> replic...@lists.osuosl.org
> http://lists.osuosl.org/mailman/listinfo/replicant

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

Re: [Tinkerphones] Welcome to the Tinkerphones community

[H. Nikolaus Schaller]

> Am 01.07.2016 um 09:12 schrieb joerg Reisenweber <jo...@openmoko.org>:
> 
> Congrats!
> 
> This was overdue and the new name is absolutely to the point and has quite 
> some appeal. The definition of what is / is not a tinkerphone is very helpful 
> and should go to the frontpage at http://www.tinkerphones.org
> 
> I like it very much.

That is nice to hear :)

> 
> What about icons etc, generally the complete "corporate identity"? Has it 
> been 
> discussed what will change (beyond the obviously pending overhaul of 
> http://www.tinkerphones.org artwork/design), and are there already tasks 
> assigned to experts? Maybe even new logos etc established and available?

No, nothing. Just the the domain registration and minor changes to the mailing
list and home page.

So there is plenty of room for volunteers to make proposals and many topics for
our community to discuss.

> 
> Many thanks, Nikolaus - and whoever else been involved! :-)
> cheers
> jOERG

> 
> On Fri 01 July 2016 08:29:39 H. Nikolaus Schaller wrote:
>> Hi,
>> after several years of running the OpenPhoenux community, we
>> thought that it is time to refresh it a little and replace the awkward
>> name "OpenPhoenux" (it was always difficult to spell and pronounce)
>> with something new, self-explaining, that your mom understands.
>> 
>> "OpenPhoneux" was originally coined in ca. 2009 as the name of an
>> initiative, when it became clear that the Openmoko company would stop
>> to develop a successor of the Openmoko Freerunner. It finally brought
>> the GTA04 device to life.
>> 
>> Back then, this was a motivating allusion to the situation of building
>> something new on the remains of Openmoko, but nowadays probably
>> only some core members of our community are able to understand
>> this background.
>> 
>> Therefore we discussed in a small circle what the core of Openmoko
>> and Openphoenux is.
>> 
>> It was easy to find what it is not:
>> * it is not a 100% fair phone (we don't have the resources to track
>>  components - it is enough challenge to have it working and being produced)
>> * it is not a 100% open phone (we have not found a feasible solution for
>> WLAN and GPU)
>> * it is not a 100% secure phone (we can't do security audits of every
>>  component)
>> * it is not a cutting edge phone (we do not get the latest and greatest
>>  chips as mainstream manufacturers do)
>> * it is not a geeks (only) phone (we want everybody to be able to use
>>  it)
>> 
>> But then we found what the common denominator of all Openmoko
>> activities was and is:
>> 
>> It is a device that allows you to tinker with it, i.e. find out how it
>> works, to replace software and even hardware components for smaller or
>> bigger improvements and even repairs. It is designed in a way to enable
>> such changes instead of stopping you (e.g. by protected boot loaders,
>> undocumented code etc.).
>> 
>> All this is facilitated by being open (as far as NDAs and other limitations
>> allow) and using open source technology (e.g. GNU/Linux, Debian).
>> 
>> Here is a definition of what "tinkering" is [1]:
>> 
>>  "tinker or tinker around to make small changes to something in order to
>> improve or repair it" "tinker with: He spends hours tinkering around with
>> car engines."
>> 
>> So we are now happy to tell the world that we are members of
>> "the Tinkerphone community" :)
>> 
>> There is a new web domain representing this change:
>> 
>>  <http://www.tinkerphones.org>
>> 
>> I hope you will agree with us and stay here, contribute and share
>> your ideas and achievements. And invite new tinkerers to participate.
>> 
>> Happy tinkering,
>> Nikolaus
>> 
>> PS: it will need your help to update the documentation pages...
>> 
>> [1]: <http://www.macmillandictionary.com/dictionary/british/tinker_1>
>> 
>> 

BR,
Nikolaus

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

Re: [Tinkerphones] [Gta04-owner] Status GTA04A5

[H. Nikolaus Schaller]

Hi,

> Am 21.08.2016 um 09:25 schrieb Butrus Damaskus <butrus.but...@gmail.com>:
> 
> Hi Nikolaus!
> 
> I didn't read the datasheet yet so just a quick question: is it still 
> possible to read the raw data from the sensors (just in the case we can do 
> better interpolations in software than what the Boschs' MCU does)?

As far as I know: yes. BTW: we will also have the two other sensors.

BR,
Nikolaus

> 
> Thanks!
> Petr
> 
> On Tue, Aug 16, 2016 at 3:26 PM, Dr. H. Nikolaus Schaller <h...@goldelico.com 
> <mailto:h...@goldelico.com>> wrote:
> Hi,
> here a brief status update:
> 
> * components have all arrived, except one
> * the one is a new one which IMHO compensates for waiting some more days!
> 
> Thanks to generous support by Bosch Sensortec we got an option to buy the
> BNO055 intelligent 9-axis Absolute Orientation Sensor, which includes sensors
> and sensor fusion in a single package. It combines an accelerometer 
> (position),
> gyroscope (rotation speed) and compass (absolute position) and a 
> microcontroller
> in a single package. All data can be read through I2C.
> 
> So this means we directly get the orientation data e.g. for Replicant games 
> and
> augmented reality (which needs a working camera...) right from this chip and 
> do
> not need to run complex algorithms on our own.
> 
> https://www.bosch-sensortec.com/bst/products/all_products/bno055 
> <https://www.bosch-sensortec.com/bst/products/all_products/bno055>
> 
> This chip will be installed in addition to the BMC150 and BMG160 (because we
> already have bought them). And, the BME280.
> 
> We have already tested this chip on a Pyra handheld prototype mainboard which
> also has place for it and we have got someone who has written a first kernel 
> driver:
> 
> 
> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/test/bno055
>  
> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/test/bno055>
> 
> It is not perfect yet, but shows that the sensor will work.
> 
> All this mens that thanks to Bosch support, we will very soon have a very 
> modern
> orientation sensor in our open smartphone platform.
> 
> BR,
> Nikolaus
> 
> 
> ___
> Community mailing list
> Community@openphoenux.org <mailto:Community@openphoenux.org>
> http://lists.goldelico.com/mailman/listinfo.cgi/community 
> <http://lists.goldelico.com/mailman/listinfo.cgi/community>
> http://www.tinkerphones.org <http://www.tinkerphones.org/>
> 
> ___
> Gta04-owner mailing list
> gta04-ow...@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

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

Re: [Tinkerphones] [Gta04-owner] Status GTA04A5

[H. Nikolaus Schaller]

Hi,

> Am 21.08.2016 um 09:39 schrieb Butrus Damaskus <butrus.but...@gmail.com>:
> 
> On Tue, Aug 16, 2016 at 7:51 PM, H. Nikolaus Schaller <h...@goldelico.com 
> <mailto:h...@goldelico.com>> wrote:
> 
> > Am 16.08.2016 um 19:45 schrieb Xavi Drudis Ferran <xdru...@tinet.cat 
> > <mailto:xdru...@tinet.cat>>:
> >
> > El Tue, Aug 16, 2016 at 03:26:51PM +0200, Dr. H. Nikolaus Schaller deia:
> >> Hi,
> >> here a brief status update:
> >>
> >> * components have all arrived, except one
> >> * the one is a new one which IMHO compensates for waiting some more days!
> >>
> >> Thanks to generous support by Bosch Sensortec we got an option to buy the
> >> BNO055 intelligent 9-axis Absolute Orientation Sensor, which includes 
> >> sensors
> >> and sensor fusion in a single package. It combines an accelerometer 
> >> (position),
> >> gyroscope (rotation speed) and compass (absolute position) and a 
> >> microcontroller
> >> in a single package. All data can be read through I2C.
> >>
> >
> > And is the software that microcontroller runs free ?
> > Is it replaceable ?
> 
> not replaceable. It is fixed in the chip and described in the data sheet what 
> it does.
> It does not more than providing integrated coordinate data in registers
> that the CPU an ask for over I2C. So it can't do anything unexpected.
> 
> Are you really sure? I just noticed that there is something about "boot 
> loader" in the Datashit...

Yes of course there is a microcontroller inside which boots from some ROM/Flash 
on the chip.
There seems to be a variant which could be reprogrammed. But ours is the fixed 
one
(which RMS considers as "hardware" because we have no mechanism to change the 
firmware).

BTW: many sensors or other chips have such a built-in controller but you rarely 
know about
it. Sometimes a data sheet says something about a required delay time between 
ending the
reset and starting the first command. This is for some hidden microcontroller 
to boot and be
able to respond to commands sent from the host.

BR,
Nikolaus

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

Re: [Tinkerphones] [Firmware] Phone UI

[H. Nikolaus Schaller]

Hi,
I have cross-posted to some developers I know and the shr-devel and the 
tinkerphones list.


> Am 08.09.2016 um 14:29 schrieb Elena ``of Valhalla'' 
> <valhall...@trueelena.org>:
> 
> On 2016-09-07 at 17:18:57 +0200, H. Nikolaus Schaller wrote:
>>> If there are newer versions available, try to get those fixed in debian
>>> sid/unstable so that they migrate to stretch/testing, and then you could
>>> possibly get them into jessie-backports.
>> 
>> Well, I am only the messenger who tells that there might be a solution
>> for what potential Pyra users ask for. If it is buggy it is of course
>> something someone should take care of.
> 
> from a quick glance at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773586
> it doesn't seem as much "buggy" as "does not work at all"
> 
> One thing about Debian developement that maybe not everybody knows:
> since a few years there is a set of scripts that automatically removes
> from testing most packages that have had an open Release Critical (RC)
> bug for more than a few days [1]_ with no activity. This happens quite often,
> and in most cases packages get fixed and re-enter the testing archive a
> few days later. Sometimes this autoremoval happens close to the freeze
> of the next release, so the package won't be availble in stable.
> 
> This package, however, has been removed from testing on 2015-02-03,
> during the jessie (current stable) freeze and hasn't been brought back
> into stretch (current testing) even after a year and a half. This is
> usually a very bad sign of a package that has been abandoned either by
> its maintainer or by its upstream (or both).
> 
> In case you are interested to do the same in some other cases, the way I
> found out about it is by looking at the Debian Package Tracker:
> https://tracker.debian.org/pkg/phoneui-apps
> https://tracker.debian.org/pkg/phoneuid
> (there are also links from the BTS, at the top of the page for each package)
> 
> Going on from that page, I've noticed that there was an action needed
> "Problems while searching for a new upstream version" but it ended up
> being a red herring: I followed the link to the VCS in the left panel
> (which points to the VCS used for *debian package* developement, not
> upstream) and checked the file ``debian/watch``.
> In there, I expected to find the location of upstream releases in a
> format that allows for automatical checks for new versions, but it was
> empty with a note that upstream only uses git, with no releases.
> 
> Since I was already browsing the debian source, I opened the file
> ``debian/copyright`` which has the copyright informations, but also a
> pointer to where the source has been taken from, and that pointed to 
> http://git.shr-project.org/git/?p=phoneui-apps.git
> http://git.shr-project.org/git/?p=phoneuid.git
> 
> Sadly, it seems that the project has been abandoned upstream, with no
> non-trivial commits since 2013.

Yes, looks like.

> (And I'm not surprised at all, since the
> project comes from the OpenMoko community, which doesn't really have
> plenty of working hardware, right now.)

Indeed. Seems to be a hen problem. Not enough working hardware results
in even less developers and no users. Therefore there are no updates. And
because there is no standard PhoneUI, new hardware has to start from scratch...
And in the end the Users have nothing.

> 
>> Maybe the Pyra project can give the developers some new motivation to fix
>> issues.
> 
> Well, I wouldn't assume that this could happen automagically: upstream
> may not know about the Pyra (or they may do, since the open hardware
> world isn't that big, but that doesn't mean they are interested into it)
> 
> Maybe just telling the upstream authors about Pyra may help, but they
> may just not be interested in buying an expensive device just to
> continue developement of something they have lost interest into: in this
> case it will have to be somebody in Pyra's community who either revives
> this project or starts a new one to develop a suite of phone software.

Indeed this is my main idea: get the Pyra community interested to pick
up a project (must not necessarily be PhoneUI if a similar starting point
exists) and bring it back into activity, including upstream.

Another options is QtMoko (which is also Debian based) but does not fit
well into the Debian build system and PhoneUI is more advanced in that it
already is available in one Debian release. QtMoko isn't in any.

So I want to start this process with making the Pyra community aware that
a lot of code (potentially bit-rotting) exists for exactly what is needed
to use the Pyra as a Phone.

The other option would be to wait until someone from the Pyra com

[Tinkerphones] Open Source (GPL) search engine

[H. Nikolaus Schaller]

Hi,
I have found an interesting project that IMHO deserves some support by
other communities like ours. Although Germany focussed (if I understood
correctly he limits the crawler to German pages?).

There is a German developer running an open source search engine with
his own search index (2.1 billion pages indexed):

https://deusu.de/

It respects privacy (no storing of IP addresses, no cookies, https only).

And the source code is open:

https://github.com/MichaelSchoebel/DeuSu

He runs it from private budgets and collects really minimal amounts per month:

https://deusu.de/unterstuetzen.html

So I think we should at least spread the word that DeuSu.de exists.

BR,
Nikolaus

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

Re: [Tinkerphones] [Gta04-owner] Status GTA04A5 production

[H. Nikolaus Schaller]

Next progress: it looks as if the first 20 units are built before end of next 
week.
They will notify me and I can go there to make some videos.

BR,
Nikolaus

> Am 05.09.2016 um 14:26 schrieb Roland Häder <rol...@mxchange.org>:
> 
> Hi,
> 
> good to hear about the progress. :-)
> 
> Roland
> 
> 
> H. Nikolaus Schaller – Mon., 5. September 2016 13:49
>> Hi,
>> production time is coming very close. Last Friday we discussed the final 
>> fine-tuning for the
>> stencil for printing the solder paste.
>> 
>> And now I got the confirmation that all components (incl. PCBs and BNO055) 
>> now have
>> arrived. So I am eagerly awaiting when they have time on their production 
>> machines to
>> build the first 20 units. I will go there and try to make some videos.
>> 
>> So you can probably feel my excitement :) And nervousness (because I don't 
>> know if
>> there is still one catastrophic mistake or bug in the design).
>> 
>> BR,
>> Nikolaus
>> 
>> Preorders:
>> http://shop.goldelico.com/wiki.php?page=GTA04
>> http://shop.goldelico.com/wiki.php?page=GTA04%20Complete
>> 
>> ___
>> Gta04-owner mailing list
>> gta04-ow...@goldelico.com
>> lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>> 

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

Re: [Tinkerphones] QtMoko 2 : cross compiling with Debian Sid amd64

[H. Nikolaus Schaller]

Hi,

> Am 28.08.2016 um 17:54 schrieb Adrien Dorsaz :
> 
> Hello,
> 
> Finally, I was able to finish the build of qtmoko2-qte.

Congratulations!

> 
> As I thought, I had to force use of version 5 of gcc instead of the default 
> version 6.

Yes, there seems to be some incompatibilities between gcc-4.9 (Debian stable) 
and gcc 6...
But I haven't tried myself.


> I've added these links into a personal bin path and all worked:
> 
>> adrien@bureau:~/.local/bin$ ls -l
>> total 28
>> lrwxrwxrwx 1 adrien adrien   34 aoû 27 22:01 arm-linux-gnueabihf-cpp -> 
>> /usr/bin/arm-linux-gnueabihf-cpp-5
>> lrwxrwxrwx 1 adrien adrien   34 aoû 27 22:00 arm-linux-gnueabihf-g++ -> 
>> /usr/bin/arm-linux-gnueabihf-g++-5
>> lrwxrwxrwx 1 adrien adrien   34 aoû 27 22:00 arm-linux-gnueabihf-g++-5 -> 
>> /usr/bin/arm-linux-gnueabihf-g++-5
>> lrwxrwxrwx 1 adrien adrien   34 aoû 27 22:01 arm-linux-gnueabihf-gcc -> 
>> /usr/bin/arm-linux-gnueabihf-gcc-5
>> lrwxrwxrwx 1 adrien adrien   37 aoû 27 22:01 arm-linux-gnueabihf-gcc-ar -> 
>> /usr/bin/arm-linux-gnueabihf-gcc-ar-5
>> lrwxrwxrwx 1 adrien adrien   37 aoû 27 22:01 arm-linux-gnueabihf-gcc-nm -> 
>> /usr/bin/arm-linux-gnueabihf-gcc-nm-5
>> lrwxrwxrwx 1 adrien adrien   41 aoû 27 22:01 arm-linux-gnueabihf-gcc-ranlib 
>> -> /usr/bin/arm-linux-gnueabihf-gcc-ranlib-5
>> lrwxrwxrwx 1 adrien adrien   35 aoû 27 22:02 arm-linux-gnueabihf-gcov -> 
>> /usr/bin/arm-linux-gnueabihf-gcov-5
>> lrwxrwxrwx 1 adrien adrien   40 aoû 27 22:02 arm-linux-gnueabihf-gcov-tool 
>> -> /usr/bin/arm-linux-gnueabihf-gcov-tool-5
> 
> Regards,
> Adrien


BR,
Nikolaus

> 
> Le sam 27 aoû 2016 à 12:10, Adrien Dorsaz  a écrit :
>> Hello,
>> 
>> I've tried to compile the QtMoko2 project and I had some issues.
>> 
>> First of all, I was able to cross compile without any errors the 
>> qtmoko2-kernel.
>> 
>> Then, I've tried to compile the qtmoko2-qte package and I had errors (see 
>> attached file).
>> 
>> My setup is a Debian Sid 64bits with armhf architecture enabled in dpkg.
>> I've installed following armhf packages from amd64 packages:
>> 
>>> $ apt list | grep armhf | grep installé
>>> crossbuild-essential-armhf/testing,testing,testing,unstable,unstable,unstable,now
>>>  12.2 all  [installé]
>>> libasan2-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now 
>>> 5.4.0-6cross1 all  [installé, automatique]
>>> libasan3-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now 
>>> 6.1.1-9cross1 all  [installé, automatique]
>>> libatomic1-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  6.1.1-9cross1 all  [installé, automatique]
>>> libc6-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now 
>>> 2.23-1cross1 all  [installé]
>>> libc6-dev-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  2.23-1cross1 all  [installé]
>>> libgcc-5-dev-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  5.4.0-6cross1 all  [installé, automatique]
>>> libgcc-6-dev-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  6.1.1-9cross1 all  [installé, automatique]
>>> libgcc1-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now 
>>> 1:6.1.1-9cross1 all  [installé, automatique]
>>> libgomp1-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now 
>>> 6.1.1-9cross1 all  [installé, automatique]
>>> libstdc++-5-dev-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  5.4.0-6cross1 all  [installé]
>>> libstdc++-6-dev-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  6.1.1-9cross1 all  [installé, automatique]
>>> libstdc++6-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  6.1.1-9cross1 all  [installé, automatique]
>>> libubsan0-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  6.1.1-9cross1 all  [installé, automatique]
>>> linux-libc-dev-armhf-cross/testing,testing,testing,unstable,unstable,unstable,now
>>>  4.6.2-2cross1 all  [installé]
>> 
>> and these ones from armhf packages:
>>> $ root@bureau:/var/log# dpkg --get-selections | grep ":armhf"
>>> gcc-6-base:armhfinstall
>>> libasan3:armhf  install
>>> libatomic1:armhfinstall
>>> libc6:armhf install
>>> libc6-dev:armhf install
>>> libgcc-6-dev:armhf  install
>>> libgcc1:armhf   install
>>> libgomp1:armhf  install
>>> liblzo2-2:armhf install
>>> libsqlite3-0:armhf  install
>>> libsqlite3-dev:armhfinstall
>>> libstdc++-6-dev:armhf   install
>>> libstdc++6:armhfinstall
>>> libubsan0:armhf install
>>> 

Re: [Tinkerphones] [Gta04-owner] Status of GTA04A5 production

[H. Nikolaus Schaller]

Hi,
"next week" has arrived and it looked good for Friday
and I just waited for the final confirmation to take
my handy-cam and make a video of the production run.

Now I got an info that everything is prepared.

But it has turned out that the dipping machine for the
package on package memory chip is defective. It will
be repaired and is planned to arrive on Monday.

So production run will be Tuesday or Wednesday.

Please cross fingers :)

BR,
Nikolaus Schaller


> Am 07.09.2016 um 19:21 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
> 
> Next progress: it looks as if the first 20 units are built before end of next 
> week.
> They will notify me and I can go there to make some videos.
> 
> BR,
> Nikolaus
> 
>> Am 05.09.2016 um 14:26 schrieb Roland Häder <rol...@mxchange.org>:
>> 
>> Hi,
>> 
>> good to hear about the progress. :-)
>> 
>> Roland
>> 
>> 
>> H. Nikolaus Schaller – Mon., 5. September 2016 13:49
>>> Hi,
>>> production time is coming very close. Last Friday we discussed the final 
>>> fine-tuning for the
>>> stencil for printing the solder paste.
>>> 
>>> And now I got the confirmation that all components (incl. PCBs and BNO055) 
>>> now have
>>> arrived. So I am eagerly awaiting when they have time on their production 
>>> machines to
>>> build the first 20 units. I will go there and try to make some videos.
>>> 
>>> So you can probably feel my excitement :) And nervousness (because I don't 
>>> know if
>>> there is still one catastrophic mistake or bug in the design).
>>> 
>>> BR,
>>> Nikolaus
>>> 
>>> Preorders:
>>> http://shop.goldelico.com/wiki.php?page=GTA04
>>> http://shop.goldelico.com/wiki.php?page=GTA04%20Complete
>>> 
>>> ___
>>> Gta04-owner mailing list
>>> gta04-ow...@goldelico.com
>>> lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>>> 
> 

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

[Tinkerphones] making the Tinkerphones community more active

[H. Nikolaus Schaller]

Hi all,
I hope everyone is well back from holidays and summer activities.

Now, I think it is time to think about how to activate the community,
i.e. attract more people to it.

Ons factor is certainly that we have more discussion on this list.
So please feel free to raise any topic around tinkering here the little
it may look.

Also important is to report stories about your current activities
tinkering with your phone. Good ones, bad ones, funny ones, unexpected
things.

And, if you have some knowledge you think it should be shared here,
please feel free to do so. You can even post links to interesting
blogs and articles. Not everybody is actively reading Reddit or
twitter channels etc. So good old e-mail sometimes reaches new
listeners...

So this are my thoughts about this topic. What are yours?

BR,
Nikolaus

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

Re: [Tinkerphones] [Gta04-owner] Status of GTA04A5 production

[H. Nikolaus Schaller]

> Am 14.09.2016 um 11:16 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
> 
> Hi,
> "next week" has arrived and it looked good for Friday
> and I just waited for the final confirmation to take
> my handy-cam and make a video of the production run.
> 
> Now I got an info that everything is prepared.
> 
> But it has turned out that the dipping machine for the
> package on package memory chip is defective. It will
> be repaired and is planned to arrive on Monday.
> 
> So production run will be Tuesday or Wednesday.

It is now scheduled for Thursday... We have to wait 2 more days.

> 
> Please cross fingers :)
> 
> BR,
> Nikolaus Schaller
> 
> 
>> Am 07.09.2016 um 19:21 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>> 
>> Next progress: it looks as if the first 20 units are built before end of 
>> next week.
>> They will notify me and I can go there to make some videos.
>> 
>> BR,
>> Nikolaus
>> 
>>> Am 05.09.2016 um 14:26 schrieb Roland Häder <rol...@mxchange.org>:
>>> 
>>> Hi,
>>> 
>>> good to hear about the progress. :-)
>>> 
>>> Roland
>>> 
>>> 
>>> H. Nikolaus Schaller – Mon., 5. September 2016 13:49
>>>> Hi,
>>>> production time is coming very close. Last Friday we discussed the final 
>>>> fine-tuning for the
>>>> stencil for printing the solder paste.
>>>> 
>>>> And now I got the confirmation that all components (incl. PCBs and BNO055) 
>>>> now have
>>>> arrived. So I am eagerly awaiting when they have time on their production 
>>>> machines to
>>>> build the first 20 units. I will go there and try to make some videos.
>>>> 
>>>> So you can probably feel my excitement :) And nervousness (because I don't 
>>>> know if
>>>> there is still one catastrophic mistake or bug in the design).
>>>> 
>>>> BR,
>>>> Nikolaus
>>>> 
>>>> Preorders:
>>>> http://shop.goldelico.com/wiki.php?page=GTA04
>>>> http://shop.goldelico.com/wiki.php?page=GTA04%20Complete
>>>> 
>>>> ___
>>>> Gta04-owner mailing list
>>>> gta04-ow...@goldelico.com
>>>> lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>>>> 
>> 
> 
> ___
> Gta04-owner mailing list
> gta04-ow...@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

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

Re: [Tinkerphones] Letux Cortex 15

[H. Nikolaus Schaller]

Hi,

> Am 21.09.2016 um 22:59 schrieb Paul Bryan :
> 
> I can't find many details about this little board.

It is the OMAP5 CPU (Dual Core Cortex A15) board designed for the Pyra 
Handheld, but offered separately.

The special thing is that it is not only a replacement part, but gets support 
by an evaluation version that can be operated stand-alone.

And a blueprint design file (EAGLE) will be available with proper placement of 
the connectors for some to-be-designed motherboard. For simple applications a 
2-layer board will suffice and 4-layers should be enough for everything.

> I think it has a lot of potential. Are there any specs on this?

Yes, here is a rough one: 
http://shop.goldelico.com/wiki.php?page=Letux%20Cortex%2015

• Dimensions: 33 x 81 mm
• 2.4 mm thickness (components on one side only!)
• OMAP5432AAN (1.5 GHz Dual Core Cortex A15)
• Power management (TWL6037)
• Audio (TWL6040)
• 2 GB DDR3 RAM
• eMMC
• USB3503 USB hub
• 2x100 pin B2B connector and 1x20pin
• Interfaces
• 1x USB3 OTG
• 3x USB2
• 1x SATA
• 1x MIPI
• 1x HDMI
• 1x CSI (2 lane)
• 4x I2C
• nx McBSP
• nx SPI
• nx GPIO (McBSP and SPI can also be used)
• RGB display (by muxing GPIOs and other signals)
• 3.2 - 4.2V VSYS input
• 3x MMC (bus width 4 bit, 1.8/3.3V)
• 1x SDIO (1.8V)
• regulated 1V8 output
• Audio interface for: headset with mic, 2 handsfree speakers, 
microphone
• ...
• EVAL version adds: 2 µSD slots, 1x µUSB for power and FT232 console, 
2 LEDs, 4 buttons, 5.5mm total thickness
• Letux kernel support: http://projects.goldelico.com/p/gta04-kernel/

> Will there be additional boards available when the Pyra goes to full 
> manufacturing run?

Yes, they will be diverted from Pyra mass production.
So availability is strongly connected.

BR,
Nikolaus


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

Re: [Tinkerphones] [Gta04-owner] Status of GTA04A5 production

[H. Nikolaus Schaller]

Hi,
we are coming closer...

I had a short meeting to discuss placement of some components today.
For example the position of the two LEDs is not easy to determine because
they are tilted a little.

But the whole GTA04 design is more complex than they thought, so that
they had much more work than planned to program the Siplace system.
This was intersting to see.

Basically they have a CAD system where they read in the Gerber files
and overlay Pick positions and component packages. Components
can be shifted and rotated manually if needed. This is automatically
replicated for a multiple panel. 

I have already seen the boxes with all components. Those are tempered
tonight and tomorrow they do the setup. Depending on how long it needs,
they can start tomorrow. Or Monday latest.

All this means they are again behind schedule. But not much and we can
be happy to have someone who produces so small quantities for us with
such elaborated machinery. And they have already produced many OpenPandora
devices so they know how to solder the PoP chips.

Anyways I will take a camera with me tomorrow so that I can show some
scenes from setting up GTA04 production then.

It remains thrilling :)

BR,
Nikolaus
 

> Am 20.09.2016 um 09:04 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
> 
> 
>> Am 14.09.2016 um 11:16 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>> 
>> Hi,
>> "next week" has arrived and it looked good for Friday
>> and I just waited for the final confirmation to take
>> my handy-cam and make a video of the production run.
>> 
>> Now I got an info that everything is prepared.
>> 
>> But it has turned out that the dipping machine for the
>> package on package memory chip is defective. It will
>> be repaired and is planned to arrive on Monday.
>> 
>> So production run will be Tuesday or Wednesday.
> 
> It is now scheduled for Thursday... We have to wait 2 more days.
> 
>> 
>> Please cross fingers :)
>> 
>> BR,
>> Nikolaus Schaller
>> 
>> 
>>> Am 07.09.2016 um 19:21 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>>> 
>>> Next progress: it looks as if the first 20 units are built before end of 
>>> next week.
>>> They will notify me and I can go there to make some videos.
>>> 
>>> BR,
>>> Nikolaus
>>> 
>>>> Am 05.09.2016 um 14:26 schrieb Roland Häder <rol...@mxchange.org>:
>>>> 
>>>> Hi,
>>>> 
>>>> good to hear about the progress. :-)
>>>> 
>>>> Roland
>>>> 
>>>> 
>>>> H. Nikolaus Schaller – Mon., 5. September 2016 13:49
>>>>> Hi,
>>>>> production time is coming very close. Last Friday we discussed the final 
>>>>> fine-tuning for the
>>>>> stencil for printing the solder paste.
>>>>> 
>>>>> And now I got the confirmation that all components (incl. PCBs and 
>>>>> BNO055) now have
>>>>> arrived. So I am eagerly awaiting when they have time on their production 
>>>>> machines to
>>>>> build the first 20 units. I will go there and try to make some videos.
>>>>> 
>>>>> So you can probably feel my excitement :) And nervousness (because I 
>>>>> don't know if
>>>>> there is still one catastrophic mistake or bug in the design).
>>>>> 
>>>>> BR,
>>>>> Nikolaus
>>>>> 
>>>>> Preorders:
>>>>> http://shop.goldelico.com/wiki.php?page=GTA04
>>>>> http://shop.goldelico.com/wiki.php?page=GTA04%20Complete
>>>>> 
>>>>> ___
>>>>> Gta04-owner mailing list
>>>>> gta04-ow...@goldelico.com
>>>>> lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>>>>> 
>>> 
>> 
>> ___
>> Gta04-owner mailing list
>> gta04-ow...@goldelico.com
>> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
> 
> ___
> Gta04-owner mailing list
> gta04-ow...@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

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

Re: [Tinkerphones] [Gta04-owner] GTA04A5 and News from the Kernel

[H. Nikolaus Schaller]

Hi,

> Am 03.11.2016 um 18:58 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
> 
> Hi,
> 
>> Am 03.11.2016 um 18:18 schrieb Ларионов Даниил <scumco...@yandex.ru>:
>> 
>> Dear NIkolaus,
>> 
>>> Here they finally are
>> 
>> Thanks a lot for the x-rays, but I didn't get this part:
>> 
>>> A first measurement of the boards shows shorts in one case and some missing 
>>> connections in others.
>> 
>> Does this mean that one of the boards *does* have a short-circuit, but it 
>> didn't show up on the x-ray?
> 
> At least the first impression was so. I have to verify if it is really the 
> case or was a wrong measurement.
> I just did it quickly after getting the X-ray images and writing this mail.

finally I did the planned measurements and it can be confirmed that there are 
short circuits on one
board which isn't visible in X-Ray. Either they are very tiny whiskers or we 
have mixed up the X-Ray
screen shots.

Anyways there is a very clear pattern.
If we have (almost) no flux there are many unconnected pads.
If we have (too) much flux there are shorts in the middle.

Therefore the most promising approach appears to reduce the amount of flux in 
the middle.

This either means using a stencil with smaller openings in the middle or close 
them completely.

I will discuss that with the production line and then I think the risk of 
building some more
broken boards is no longer high. Wen can then use this result for final 
fine-tuning.

BR and sorry for the slow progress. It is unlike software where we just have to 
run the
compiler, download the result to the device and test. Within minutes...

It is more like old FORTRAN style with punched cards where they were handed 
over to the
operator who did run the task over night and next day you got a pile of 
computer printouts
showing errors or results. Then you did punch some replacement cards to modify 
the card deck :)

BR and thanks for your patience,
Nikolaus



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

[Tinkerphones] Fwd: Ten years anniversary of Openmoko

[H. Nikolaus Schaller]

Wow,
is it really 10 years?

> Von: Belisko Marek 
> 
> http://laforge.gnumonks.org/blog/20160920-openmoko_10years/

yes it is 10 years!

The first time I heard about Openmoko was through an invitation
to some telecoms conference in London where there was an
N.N. person presenting a talk about some exciting new
mobile phone.

Unfortunately I wasn't able to attend this conference.

It turned out that it was the announcement of the Openmoko
GTA01 by Sean Moss-Pultz.

And this was just weeks before Apple announced the first
iPhone in January 2007.

Back then Openmoko project was welcome by the press and found
quite some coverage:

http://www.nytimes.com/2008/07/10/technology/personaltech/10phone.html

Sinc eit is really 10 years, let's celebrate this also with our
www.ohsw.org event in less than 2 weeks in Garching near Munich :)

And let's try even harder to disprove Harald's statement:

"We're stuck with a smartphone world in which we can hardly escape any vendor 
lock-in. It's virtually impossible in the non-free-software iPhone world, and 
it's difficult in the Android world. In 2016, we have more Linux based 
smartphones than ever - yet we have less freedom on them than ever before."

Projects like Replicant, Pyra, Neo900, GTA04A5 are still
inhabitants of the small Gaulish village teasing the Roman
empire :)

BR,
Nikolaus

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

[Tinkerphones] GTA04A5 and News from the Kernel

[H. Nikolaus Schaller]

Hi,
finally we got a time slot tomorrow to do the next
soldering tests for the GTA04A5. The reason why it
took so long is that these pick machines
sometimes run for several days with the same program
producing some 10 thousand PCBs for other customers...

So they can't easily stop and do experiments like
we need.

The plan for tomorrow is try to solder 4 PoP systems
with different preparation:

1. without (almost no) solder paste and no flux. The
idea is to see if the effect comes from too much flux
added or is inherent to the DM3730 package.

2. with solder paste in the outer ring of the DM3730
package and no paste in the middle (where the shorts
usually occur). The idea is to reduce the amount of
flux in the critical area.

3. with a tiny snippet of Kapton under the DM3730
and doing the same flux dipping as we tried before.

4. with a tiny snippet of Kapton under the DM3730
and full solder paste as one would usually do.

Puh. Quite costly to produce scrap since we will not
solder any other components and therefore we can
only do X-ray inspection and measure for short circuits.
There is no possibility to test if the DM3730 SoC would
work well and has really all pads connected.

Anyways I hope this will give a lot of insights and finally
will allow to decide how to do the real production
run. Probably we need to run 4 full boards and test
them before doing the remaining ones...

On the kernel side there is also some news.

Nothing for those readers who are strong advocates of
FLOSS and do never want to run any binary from unknown
sources. Those can skip this section...

The reason is that it is about the PVR/SGX530 3D GPU
inside the DM3730 chip.

The whole 3D system is made of four components, two
of them are binary blobs only, one is GPL open source
and the fourth unknown is the SGX hardware.

The news is about the open source kernel driver. I
have finally managed to get it compiled again on
letux-4.9-rc2. And in a way that it is a simple kernel
module. Well, if you want to call a 4 MByte .ko "simple".

modprobing on the GTA04 almost succeeds, except an
error message from the "reset framework". This was
expected, since it is one of two parts which need
adaptation to newer kernel APIs. One is the "reset
framework" and the other one is about dma/cache
interaction where the TI driver calls some very very
low level (even assembler) code directly. This has
been declared private API some time ago and so it
has to be rewritten to use some more official API.

If someone wants to dig into this topic, the
source code is here:


http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/gpu/pvr-v2

Now back to the topic of FLOSS. This driver is of
course free. But it will need / load firmware binaries
into the GPU part of the SoC. These binaries are
on one hand some "microkernel" running on the SGX
GPU and the ARM libraries for OpenGL etc.

So thats it for today. And I hope I can bring some
news about the GTA04A5 tomorrow.

BR,
Nikolaus

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

Re: [Tinkerphones] [Gta04-owner] GTA04A5 and News from the Kernel

[H. Nikolaus Schaller]

> Am 27.10.2016 um 23:13 schrieb Boudewijn <wankelwan...@yahoo.com>:
> 
> On Thursday, October 27, 2016 7:43:27 PM CEST H. Nikolaus Schaller wrote:
>> Hi,
>> finally we got a time slot tomorrow to do the next
>> soldering tests for the GTA04A5. 
>> The plan for tomorrow is try to solder 4 PoP systems
>> with different preparation: (...)
>> Puh. Quite costly to produce scrap since we will not
>> solder any other components and therefore we can
>> only do X-ray inspection and measure for short circuits.
>> There is no possibility to test if the DM3730 SoC would
>> work well and has really all pads connected.
> 
> Costly indeed and frustrating to have (out of necessity) so much time between 
> test runs!

It is much easier to run the compiler, boot a device and check
for errors :) So open software is much easier...

> 
>> On the kernel side there is also some news.
>> The news is about the open source kernel driver. I
>> have finally managed to get it compiled again on
>> letux-4.9-rc2. And in a way that it is a simple kernel
>> module. Well, if you want to call a 4 MByte .ko "simple".
>> 
>> modprobing on the GTA04 almost succeeds, except an
>> error message from the "reset framework". This was
>> expected,
> 
> As it is the letux-kernel, does the same go for modprobing on the Pyra?

Not yet, but I have planned to do it the same way - if possible.
There is some work by others who have helped but it is not yet
integrated. For example you can find the omap5 sgx firmware as
a debian package here:

http://packages.pyra-handheld.com/debian/pool/main/o/omap5-sgx-ddk-um-linux/

> 
>> So thats it for today. And I hope I can bring some
>> news about the GTA04A5 tomorrow.
> 
> Thanks, and good luck tomorrow!

Thanks, we will need it :)

BR,
Nikolaus

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

Re: [Tinkerphones] [Gta04-owner] GTA04A5 and News from the Kernel

[H. Nikolaus Schaller]

Hi,

> Am 03.11.2016 um 18:18 schrieb Ларионов Даниил <scumco...@yandex.ru>:
> 
> Dear NIkolaus,
> 
>> Here they finally are
> 
> Thanks a lot for the x-rays, but I didn't get this part:
> 
>> A first measurement of the boards shows shorts in one case and some missing 
>> connections in others.
> 
> Does this mean that one of the boards *does* have a short-circuit, but it 
> didn't show up on the x-ray?

At least the first impression was so. I have to verify if it is really the case 
or was a wrong measurement.
I just did it quickly after getting the X-ray images and writing this mail.

BR,
Nikolaus

> 
> -- 
> Daniil Larionov
> 
> 
> 
> 03.11.2016, 20:11, "H. Nikolaus Schaller" <h...@goldelico.com>:
>>> Am 28.10.2016 um 18:59 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>>> 
>>> As soon as I have the X-rays I can share them as well.
>> 
>> Here they finally are:
>> 
>> The problem is that none of them has shorts between the balls but they are 
>> different.
>> 
>> A first measurement of the boards shows shorts in one case and some missing 
>> connections in others.
>> 
>> I have not yet made up my mind with which variant we should go into 
>> production...
>> 
>> BR,
>> NIkolaus
>> 
>> ,
>> 
>> ___
>> Community mailing list
>> Community@openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/community
>> http://www.tinkerphones.org
> ___
> Community mailing list
> Community@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org

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

Re: [Tinkerphones] [Gta04-owner] GTA04A5 and News from the Kernel

[H. Nikolaus Schaller]

Hi all,
there wasn't anything new to report because we are waiting for the production
line.

> Am 07.11.2016 um 10:32 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
> 
> Anyways there is a very clear pattern.
> If we have (almost) no flux there are many unconnected pads.
> If we have (too) much flux there are shorts in the middle.
> 
> Therefore the most promising approach appears to reduce the amount of flux in 
> the middle.
> 
> This either means using a stencil with smaller openings in the middle or 
> close them completely.

But today I got a phone call from production that they have a time slot today
to do the next attempt.

So I went there immediately (fortunately it is not far away) and we worked 3 
hours
to produce 4 more complete GTA04A5 boards.

Unfortunately, we still have no working PCB :(

* one of them have short circuits - but much less than before.
* one of them has a rotated memory chip (which can very likely be fixed)
* one has a short under the tps65950 power controller.
* and one has no shorts to measure.

So we placed an µSD card into the one without shorts and connected a battery.
But no LED did light up yet. It could be possible that there is something
with the GTA battery I took with me or the µSD card.

I would have needed an oscilloscope and some RS232 cable to look what the board
is really doing when being powered on (are all
voltages available, are the oscillators running etc.).

Then we did X-Ray and as expected the shorts in the middle of the DM3730
processor are gone :) But this time some boards have visible shorts in the
outer ring which we did not have in earlier experiments.

So this means we are on the right track, but still not there to risk
mass production. The idea is to get another stencil (we did this work
with the same stencil as for all attempts before) where we reduce the
openings for in the outer ring to have less solder paste there.

Again this will need some time. We need to talk to the stencil manufacturer,
have the stencil built (this takes the shortest time: 2 days) and then
wait for another time slot in the production line.

Talking about risk. Well, so far we have spent money for ca. 15 GTA04 boards
and only one of them shows activities. But it wasn't populated completely
and has solder openings in the outer ring. Therefore I wasn't able to
test it completely. But it did boot, makes the LEDs blink, shows X11 on
the display.

But 14 of these are scrap with low probability that they can ever be
repaired. As you know what each working GTA04A5 costs this is already
a lot of money that wasn't in the financial plan in this amount.

So let me ask for donations to support this experiments which need to be
done to really fix production issues.

What is your benefit:
a) it supports getting the GTA04A5 to a success,
b) success of the GTA04A5 means the most free hardware becomes available again,
c) the device is well supported by mainline kernel,
d) since the Neo900 wants to use exactly the same DM3730CBP chip it will
   run into the same soldering problems, unless we solve them here.

Here is a link to the goldelico shop where you can donate for this project:

http://shop.goldelico.com/wiki.php?page=GTA04%3ADonation

Thank you,
Nikolaus

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

Re: [Tinkerphones] [Gta04-owner] GTA04A5 and News from the Kernel

[H. Nikolaus Schaller]

Hi Paul,

> Am 29.11.2016 um 16:26 schrieb Paul Boddie <p...@boddie.org.uk>:
> 
> On Tuesday 29. November 2016 16.01.43 H. Nikolaus Schaller wrote:
>> 
>> What is your benefit:
>> a) it supports getting the GTA04A5 to a success,
>> b) success of the GTA04A5 means the most free hardware becomes available
>> again, c) the device is well supported by mainline kernel,
>> d) since the Neo900 wants to use exactly the same DM3730CBP chip it will
>>   run into the same soldering problems, unless we solve them here.
>> 
>> Here is a link to the goldelico shop where you can donate for this project:
>> 
>> http://shop.goldelico.com/wiki.php?page=GTA04%3ADonation
> 
> Firstly, thank you for your efforts in pushing this project forward, despite 
> it costing you quite a bit of time and money. I am already a supporter of 
> Neo900, but before that initiative started I had considered pre-ordering the 
> GTA04 instead. (I held off because there didn't seem to be a reliable route 
> to 
> getting a complete device, at least not without getting a GTA02 first.)

Well, we have ca. 40 case kits so this time we will have for the first time
complete devices. But also for the last time since we can't get any more.

> 
> It certainly seems important to Neo900 to get these issues resolved, and I 
> guess the Neo900 people are aware of this,

I hope so.

> but I also wondered whether the 
> Pyra had any similar issues and how they might have been resolved there. I 
> see 
> that the Pyra uses an OMAP5 SoC, not the OMAP3 SoC used here, so the 
> conditions are obviously not identical,

yes, they are very different.

The key problem is that the DM3730CBP (OMAP3) is a Package on Package chip
and soldering it is a very critical process. Texas Instruments has a lot of
guidelines, but they are more on a level of describing what could get wrong
so that you don't lack ideas about that. But it lacks a clear recipe for
solving issues - just sort of "please think of this and that". So we end
up in a pure empirical approach.

The OMAP5 is a hard plastic package and the memory chips are solders around
it. This has different issues in PCB layout, but the production process is
much easier and stable.

> but since you were involved in getting 
> the Pyra's hardware finished, maybe there are some things that keep recurring 
> with these TI parts and that might be applicable here.
> 
> I'm just speculating, really, but also trying to offer some moral support, 
> too.

This is important and welcome as well! Especially as we now have 10 years
Openmoko...

BR,
Nikolaus

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