Development of Teres-2

[kreyren]

I am done waiting for tsvetan, lets make our own

---

WIP i will update this post with proposal abstract for discussion

[kreyren]

RESERVED

[kreyren]

RESERVED

[kreyren]

For context i am working on a new PCB basically since i got teres, but when brainstorming the idea it showed up more issue that needs to be handled so i am now working on addressing these and will then publish the proposal.

[DiTBho]

When might it be available? with RISC-V?

[kreyren]

When might it be available? with RISC-V?

Short answer: Yes, i am planning TH1520 and XuanTie C906 (if i get a design reference and documentation for it) in addition to other chips with main focus on RISC-V. Will be available when all highlighted problems are solved and by default will have A20 or A64, because we know these chips well and how to make them work reliably. I am also trying to get design reference for A527.

Development is currently tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues (see teres-2 milestone), current projection is that teres-2 will have a System On Module ("SOM") oriented design meaning that you will buy a "module board" that will only have:
1. the chip
2. DRAM
3. eMMC
4. SPI, maybe?
5. pins for serial console

That will be socketed e.g. with MxM socket in "platform board" which is going to be a 1~4 layer PCB which will be changable so that teres could be a laptop, netbook, phone, 3D printer, CNC, drone, etc..

The economy of this solution is that the "module board" is designed to be mass produced and be very modular so that it can be used for many use-cases as making 6+ layer pcb gets very uneconomical so doing small PCB and higher quantities will cut down the fabrication cost to the point where you should be able to get the module board with just the price of the components + up to 10% depending on the implementation so lets say doing similar design to teres-1: ~15 EUR for module board and up to 30 EUR for platform board, where the platform board is designed and expected to be fabricated locally by the user. I touched on this solution in https://git.dotya.ml/kreyren/OSHW-System-On-Module and doing prototypes to figure out how to do this.. current way will likely be a tiny PCB that gets "attached" (likely soldered or maybe there will be a socket) on MxM connector (among other options..) as that way it will enable compact designs needed for a phone formfactor and alike. So teres-2 should be way more economical than teres-1 both to make and to modify. But nothing is set in stone yet i wanted to publish a write out about the project but i need to still investigate few problems and their solutions. The SOM management is tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues/9

But first i need to handle maintanance issues (see the same-named milestone) which should all but https://linux-sunxi.org/Olimex_Teres-A64#Broken_ANX6345_on_Linux_6.5.2B_.28non-LTSi_version.29 and adjustments to the DTS should be fixed already (if you have any other issue on teres then please let me know!) which took a lot of the time as i was footprinting the kernel's modules to figure out how to document them and i work on a re-organizing system to navigate through the confusing sunxi naming that is projected to complicate the usability of teres-2 as each platform board will need to have it's DTS and exactly figured out needed modules as that's currently the biggest problem on teres-1 to get distribution support to work reliably e.g. currently HDMI doesn't work consistently across distros, CEDRUS is rarely enabled in the distro kernel and people keep using wrongly compiled u-boot (i am trying to address that via https://www.olimex.com/forum/index.php?topic=9368.0 but so far no response from OLIMEX) and i want to address the inconsistencies with documenting the kernel configuration on https://linux-sunxi.org/Olimex_Teres-A64#Linux_Kernel_Configuration_Reference and contribute the fixes to all major linux distros as i am already doing maintanance there anyway and this will ensure that the kernel will remain functional and reliable on teres.

Worth mentioning that before teres-2 i will be releasing what i call teres-1.5 which will have adjustments to the current design which is projected to:
1. have a faster eMMC -- Currently the major bottleneck in teres's responsibility and processing ability, there are multiple options that are pin-compatible with the teres-1 mainboard revision C (likely same case for rev. B) so the user could just swap the chip and get significantly better teres, tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues/3

2. 4G modem -- when looking through the kicads i found that the mainboard has pins for a sim card which can have a sim card slot added, but the board doesn't have a modem to address that i want to adjust the IO board to add Quactel EG25-G as the chip is used in pinephone and the community reverse-engineered the f*ck out of it so that it should be running open-source firmware, tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues/6

3. USB-C -- To address the common issue on teres where the barrel jack connector starts to expire after ~1000 re-insertions, when discussing the design with sunxi we figured out that the AXP803 doesn't support USB-C, but it doesn't care if it's wired to a USB-C port for us to be able to use it, but we might not even need to go this way because of the next point, tracked in https://git.dotya.ml/KREYLIMEX/TERES/issues/7

4. Hot-swappable battery -- It was advised that the AXP803 can address up to 11K mAh battery and that shouldn't be exceeded as we don't know what it will do + even if can make it support a bigger battery it's still going to be limited on LiPO unless more destructive experiments are done so instead we can implement additional Battery Management System board that will connect to the teres's power adapter for power and in USB-OTG for data (so that we can flash the eMMC and interact with the device) which would be charging the independent battery management which would enable teres to have a 99Wh battery that can be hot-swapped assuming that we reduce the current LiPo battery so that it can keep the laptop powered off for long enough until the battery swap is finished or that won't be needed to be handled as all if we use two 49Wh batteries (because you can get maximum of 99Wh in an airplane), tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues/18

5. New case -- There is a 3D printable case by Jeff Moe on https://code.forksand.com/forksand/olimex-teres-case, but it's very difficult to print that on a consumer-grade 3D printers as the case by itself is bigger than the bed of prusa, ender and even the biggest 3D printer in local hackerspace can't fit it + it's impossible to split bcs of how thin the bottom part is so i am working on an alternative design to fit in the battery, but it's likely that it will be done for teres-2 instead of teres-1.5 as logistics wise it doesn't make much sense to focus on that rn, but i will likely implement a way to add the solution in the current teres's case, tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues/18

6. Kill Switches for Mic and Camera -- The IO board can have them easily implemented and they are kinda a must have feature for me, tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues/8

7. UEXT connector -- Currently i have to jumper-wire any additional devices to the mainboard which is really annoying, OLIMEX invented a standard to address this exact problem, but didn't use it in teres itself.. So i want to implement it in the IO board, tracked on https://git.dotya.ml/KREYLIMEX/TERES/issues/15

[DiTBho]

It's my opinon that Allwinder should be avoided.

[kreyren]

It's my opinon that Allwinder should be avoided.

Can you recommend a better chip for the usecase?

[DiTBho]

Can you recommend a better chip for the usecase?

Allwinner not only messes things up with kernel, dts, firmware, etc., but releases chips with hardware bugs(1), and worse doesn't even fully comply with Open Source licenses!

Rockchip is a better company, and RK3328 is decent enough to be called "better".

(1) I am working with { Neo, NeoAir } SBCs ... umm, inside the SoC there is a buggy "OpenRisc" MPU, which has so many serious hardware bugs that, not only can it not be programmed in C because it requires manual programming in assembly to work-around its bugs (when it is possible, of course), but for safety it ends up that it is better to force it into perpetual iddle because if it were going crazy it could potentionally access all of the SoC's RAM with catastrophic consequences.

[DiTBho]

6. Kill Switches for Mic and Camera

What is the purpose of Mic and Camera on a laptop like the Teres?

If I have to do a video conference, or a video call, I certainly don't use the Teres1 but the smartphone.

The Teres2 should be an economic thing designed for development (kind of vt220 / X11 terminal), for taking notes at university, not for vatching video or making video calls.

One really useful thing would be to have an Ethernet network port.

I understand that the RJ45 connector is too large for the shell low-profile, but you can do this like on the Carbon X1 2017. Lenovo sees an optional "kit" that is nothing more than a cable that connects the eight Ethernet wires to an RJ45 adapter.

Umm, also ... I find it very inconvenient to have the serial port (uboot console) on the headphone connector. It also needs to be "configured" by a C program that runs on GNU/Linux and sets the GPIO configuration.

Can't we have a dedicated connector which doesn't have to have anything to do with the GPIOs? why add complexity to something that should work without any configuration?!?

[kreyren]

What is the purpose of Mic and Camera on a laptop like the Teres?

If I have to do a video conference, or a video call, I certainly don't use the Teres1 but the smartphone.

I use mine for calling, but would agree that the camera is somewhat pointless.. for teres-2 i would like to include a better camera so that it can be functional

The Teres2 should be an economic thing designed for development (kind of vt220 / X11 terminal), for taking notes at university, not for vatching video or making video calls.

my teres is my daily, it struggles playing videos from e.g. youtube, but mpv appears fine and with CEDRUS it seems to work even for the youtube videos without an issue.. i mostly use mine as a hardened system to manage my infra and i do freecad/kicad engineering on it and software development through nixos infra, with cedrus it seems to handle also handle AAA games assuming game streaming, but i have yet to figure out the cedrus part.. So kinda the point of netbook that's meant to have a great battery life and not restrict the user on workflow though outsourcing so i wouldn't treat it only as a portable console, for me it's functional enough to get rid of a smartphone and if it can do cloud gaming then of a desktop as well (assuming workstation/gaming server paired with it).

I agree that the economy is critical e.g. i would like to make mine more functional to add things like IR TX/RX sub-GHz etc.. so that it can be a portable laboratory for hardware designs but the mainboard PCB is too painful to self-fabricate for this usecase in small quantities. Which the SOM management should address.

One really useful thing would be to have an Ethernet network port.

I understand that the RJ45 connector is too large for the shell low-profile, but you can do this like on the Carbon X1 2017. Lenovo sees an optional "kit" that is nothing more than a cable that connects the eight Ethernet wires to an RJ45 adapter.

Teres can already have that through the mod: https://www.olimex.com/Products/USB-Modules/USB-GIGABIT/open-source-hardware

But i agree that having it integrated in teres would be better solution

I understand that the RJ45 connector is too large for the shell low-profile, but you can do this like on the Carbon X1 2017. Lenovo sees an optional "kit" that is nothing more than a cable that connects the eight Ethernet wires to an RJ45 adapter.

I don't like the idea of dongles for such a trivial thing, i feel like it would make sense for a USB-C or thunderbold, but for teres-2 i was instead thinking about using the origami ethernet connector: https://www.theverge.com/circuitbreaker/2017/12/8/16750574/pop-out-ethernet-jack but i am not sure how fragile they are

Umm, also ... I find it very inconvenient to have the serial port (uboot console) on the headphone connector. It also needs to be "configured" by a C program that runs on GNU/Linux and sets the GPIO configuration.

6. Kill Switches for Mic and Camera

What is the purpose of Mic and Camera on a laptop like the Teres?

If I have to do a video conference, or a video call, I certainly don't use the Teres1 but the smartphone.

The Teres2 should be an economic thing designed for development (kind of vt220 / X11 terminal), for taking notes at university, not for vatching video or making video calls.

One really useful thing would be to have an Ethernet network port.

I understand that the RJ45 connector is too large for the shell low-profile, but you can do this like on the Carbon X1 2017. Lenovo sees an optional "kit" that is nothing more than a cable that connects the eight Ethernet wires to an RJ45 adapter.

Umm, also ... I find it very inconvenient to have the serial port (uboot console) on the headphone connector. It also needs to be "configured" by a C program that runs on GNU/Linux and sets the GPIO configuration.

Can't we have a dedicated connector which doesn't have to have anything to do with the GPIOs? why add complexity to something that should work without any configuration?!?

I also don't like it, i have in TODO to experiment with standardizing a port for serial console that can be easily accessed.

Allwinner not only messes things up with kernel, dts, firmware, etc., but releases chips with hardware bugs(1), and worse doesn't even fully comply with Open Source licenses!

The A64 and possibly A20/A33 are the only chips that i am using from allwinner and i consider the others an unusable garbage tbh

The A64 because it doesn't have a known vulnerability to CPU bugs e.g. spectre, meltdown, etc.. and because it's cheap and documented chip that runs libre software stack (arm trusted firmware, crust, uboot) with an exception of the FEL protocol that is proprietary, but is easily auditable and it doesn't seem to be an issue of willingness to open-source rather that open-sourcing such a thing is kinda difficult to do in a usable way as it's an integrated thing in the chip that you can't really easily change and is there as a last resort to prevent hard brick situations..

So the idea of using it for development is that there won't be any surprices that will take time out of hardware development, if i mess up traces somewhere then the chip costs ~2 EUR to replace and so it's kinda really good solution for hardware development as it provides a robust foundation to use from which we can then implement additional modules and have a transition on riscv, bcs currently i am not aware of a single riscv64 chip that is not major pita or doesn't have major issues to be used.. the TH1520 is like the least broken imho and seems to get a decent mainline, but has issues with riscv implementation https://github.com/revyos/revyos/issues/17#issuecomment-1867110963 and the NPU/GPU is currently proprietary and it's not clear if it will get open-sourced and from me trying to implement compatibility for the TH1520 in armbian it's a constant show of surprices that would take the time off of hardware development.

and worse doesn't even fully comply with Open Source licenses!

The list that i help to maintain is on https://en.wikipedia.org/wiki/Allwinner_Technology#Linux_controversies

The GPL controversy seems to be a case of incompetence from what i read about it, it doesn't seem to be willful to me.

The Backdoor controversy seems as a kinda nothing burger to me.. Everyone knows that the backdoor is in the development version of allwinner kernel and it appears clearly documented that it's for development and none ships it in the final product and the allwinner kernel is mostly used as a reference for sunxi development

Please let me know if i am wrong on these or if i am missing something

(1) I am working with { Neo, NeoAir } SBCs ... umm, inside the SoC there is a buggy "OpenRisc" MPU, which has so many serious hardware bugs that, not only can it not be programmed in C because it requires manual programming in assembly to work-around its bugs (when it is possible, of course), but for safety it ends up that it is better to force it into perpetual iddle because if it were going crazy it could potentionally access all of the SoC's RAM with catastrophic consequences.

Ye i was very afraid of similar scenario in TH1520, but the statement by XuanTie seems that it's unlikely that it will affect interpretation of assembly code though i am skeptical

---

Feel free to discuss these further it's a huge help to be able to brainstorm the ideas.

[DiTBho]

I don't like the idea of dongles for such a trivial thing, i feel like it would make sense for a USB-C or thunderbold, but for teres-2 i was instead thinking about using the origami ethernet connector: https://www.theverge.com/circuitbreaker/2017/12/8/16750574/pop-out-ethernet-jack but i am not sure how fragile they are

I've also been working for years on a Japanese 2000s PDA that literally fits in your shirt pocket.

Like Teres1, it doesn't have any Ethernet port.
There are two options

• A) to buy a usb cable to its custom propietary connector (which exports, USB + lvTTL serial), and plug-in a usb-Ethernet module
• B) to buy a microPCMCIA (same connector as used in Hitachi microDRIVEs) ethernet card with a foldable RJ45 connector

I bought the PDA in Japan and thought B) was a better idea as the foldable RJ45 connector makes the whole ultra-portable and saves valuable space in your pocket case.. but then I was disappointed with that kind of Origami connector (maybe I'll take a photo) because it's really flimsy, and sometimes make unreliable contacts with the RJ45 cable, so I'm back to A) at the moment.

I got a second hand Lenovo Carbon X1 2017, which I use every day for a living, and I can say that "the optional (lenovo) cable that wires out the ethernet port" is very reliable and practical, and, being built-in ethernet, it is also already supported by the firmware, that means you can litteraly netboot.

[DiTBho]

[kreyren]

A) to buy a usb cable to its custom propietary connector (which exports, USB + lvTTL serial), and plug-in a usb-Ethernet module

OLIMEX has a solution for USB-to-Ethernet which is open-source https://www.olimex.com/Products/USB-Modules/USB-GIGABIT/open-source-hardware

I bought the PDA in Japan and thought B) was a better idea as the foldable RJ45 connector makes the whole ultra-portable and saves valuable space in your pocket case.. but then I was disappointed with that kind of Origami connector (maybe I'll take a photo) because it's really flimsy, and sometimes make unreliable contacts with the RJ45 cable, so I'm back to A) at the moment.

I see, hmm like it's not that much of an issue to fit full sized ethernet in the teres's formfactor in the worst case and in case the fujitsu's origami ethernet is not robust enough there is always this https://youtu.be/GAgWqkrmmZg?t=32 which i so far have a good experience with

maybe I'll take a photo

I looked into these too before would agree that they are very flimsy

[kreyren]

Though tbh for teres-2/1.5 case i was thinking more into something alike https://youtu.be/aNycEsAN5ys?t=101 basically i want to make an option that is reliably rugged so that it can survive a fall on earth at terminal velocity, getting ran over by a car, etc.. and other that is for office-like environment

for the development the current plan is to start with something easy to 3D print and simple in design and then move from there, i did experiments with PP+GF30 seems to be the optimal material for the rugged option as i was/am developing a additive fabrication method that makes the material significantly strong while being in this kind of limbo between brittle and ductile material as the PP wants to bend and absorb any kind of force applied to it, but the Glass Fibre if the fibres are aligned in square pattern which is achieved by custom ironing paths will prevent it from deforming too much at which point it has a characteristics of a brittle material.. from my tests the sample survived being ran over by a truck at ~3 T and it made a significant dent in the tire without reaching plasticity




Manufacturer recommended settings, which was mostly crumbling apart at slight force and has major issues with layer adhesion^




Due to over-heating of the material that causes bubbles forming during the print (recommends to be printed at insane 543K while polypropylen seems to adhere best at ~440K)



which also translates to other layers causing major structural issues^



My optimization of the first layer by pre-heating the bed at 85C for ~10 min and then heating up the nozzle to magic 447K for ~10min and then printing it



^ Other layers with squarical ironing pattern to adhere the fibre glass fibres in a squarical pattern



Layer adhesion as viewed from the side^ Makes it kinda feel like it's an injection molded piece



Fillamentum black PLA for comparison, printed on stock Prusa MK3S with pre-defined settings^

The issue is that it's problematic to fit the case on a regular 3D printer as i found out even trying to fit the forksand case on a heavily modified printer with a larger bed that is not realistic to expect from people to have so i am was working on a resign where the bottom would be supplemented with a injection-molded material or something strong in general e.g. plexiglass and the sides were printed in pieces and then adhered together with a 2 part epoxy in mortise and tenon-like connection so that it would be printable on common 3D printers