I am done waiting for tsvetan, lets make our own 8)
---
WIP i will update this post with proposal abstract for discussion
RESERVED
RESERVED
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.
When might it be available? with RISC-V?
Quote from: DiTBho on March 11, 2024, 07:16:59 PMWhen 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
It's my opinon that Allwinder should be avoided.
Quote from: DiTBho on March 12, 2024, 10:56:26 PMIt's my opinon that Allwinder should be avoided.
Can you recommend a better chip for the usecase?
Quote from: kreyren on March 13, 2024, 07:01:01 AMCan 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.
Quote from: kreyren on March 12, 2024, 03:49:14 AM6. 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?!?
Quote from: DiTBho on March 13, 2024, 10:29:45 AMWhat 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
Quote from: DiTBho on March 13, 2024, 10:29:45 AMThe 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.
Quote from: DiTBho on March 13, 2024, 10:29:45 AMOne really useful thing would be to have an Ethernet network port.
Quote from: DiTBho on March 13, 2024, 10:29:45 AMI 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
Quote from: DiTBho on March 13, 2024, 10:29:45 AMI 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
Quote from: DiTBho on March 13, 2024, 10:29:45 AMUmm, 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.
Quote from: DiTBho on March 13, 2024, 10:29:45 AMQuote from: kreyren on March 12, 2024, 03:49:14 AM6. 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.
Quote from: DiTBho on March 13, 2024, 10:06:57 AMAllwinner 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.
Quote from: DiTBho on March 13, 2024, 10:06:57 AMand 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
Quote from: DiTBho on March 13, 2024, 10:06:57 AM(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.
Quote from: kreyren on March 13, 2024, 12:58:39 PMI 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.
(https://i.ibb.co/QNZM3rF/IMG-20240314-212936577.jpg)
(https://i.ibb.co/QNYnXcG/IMG-20240314-212948882.jpg)
(https://i.ibb.co/vhhHvVk/IMG-20240314-213211987.jpg)
(https://i.ibb.co/sKQbqHY/IMG-20240314-213224947.jpg)
Quote from: DiTBho on March 14, 2024, 08:31:29 AMA) 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
Quote from: DiTBho on March 14, 2024, 08:31:29 AMI 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
Quote from: DiTBho on March 14, 2024, 08:31:29 AMmaybe I'll take a photo
I looked into these too before would agree that they are very flimsy
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
(https://i.imgur.com/8eZoreF.png)
Manufacturer recommended settings, which was mostly crumbling apart at slight force and has major issues with layer adhesion^
(https://i.imgur.com/1j5idvy.png)
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)
(https://i.imgur.com/ZM0dBY6.png)
which also translates to other layers causing major structural issues^
(https://i.imgur.com/t0adc1A.png)
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
(https://i.imgur.com/qTbmLid.png)
^ Other layers with squarical ironing pattern to adhere the fibre glass fibres in a squarical pattern
(https://i.imgur.com/qt5Xrhu.png)
Layer adhesion as viewed from the side^ Makes it kinda feel like it's an injection molded piece
(https://i.imgur.com/LPA4yra.png)
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
Quote from: kreyren on March 18, 2024, 03:01:58 PMOLIMEX has a solution for USB-to-Ethernet which is open-source
For the teres-1 I prefer the USB-ethernet adapter sold by Apple for their old Book-Air/Intel.
It's a chip that works very well with Linux (I still have to understand if uboot has support), consumes very little energy and is much more aesthetically pleasing too.
Just checked, the pinetab2 uses the Rockchip RK3566 SoC
Quote from: DiTBho on March 20, 2024, 05:34:51 PMJust checked, the pinetab2 uses the Rockchip RK3566 SoC
Afaik the reason why OLIMEX didn't provide the RK3399 and RK3566 is that they were very unreliable software-wise (afaik they release the chip and then rely on the community to mainline them while not providing sufficient amount of documentation?) and tsvetan not wanting to support that as the resulting mainline is often very problematic and takes long time to get implemented in a way that is acceptable in industrial settings (OLIMEX's main focus)
For me in terms of arm architecture only use Cortex A7/53/55 and consider everything else garbage due to the CPU vulnerabilities, but i plan on supporting all chips as long as the required docs to make boards for these are available or unless someone wants to do the adventure of reverse-engineering them and contributing that (that's what the SOM management is meant to be for)
Quote from: DiTBho on March 18, 2024, 05:20:08 PMQuote from: kreyren on March 18, 2024, 02:51:20 PMQuote from: olimex on March 14, 2024, 08:01:19 PMA64 Ethernet is shared with the LCD, so if you want to use the build in Ethernet you lose the LCD, quite annoying decision but Allwinner made A64 thinking for tablets where Ethernet is not mandatory
As far as i was told that applies only for the LCD interface, you could still use the display over MIPI-DSI to enable the ethernet which might even be the more power efficient solution that could do touchscreen over e.g. I2C
So, could you check, and it's possible, could you do it for Teres-v1/Rev${next} and/or Teres-v1.5?
Not for teres 1.5 as it would require a redesign of the whole mainboard and the resulting product would be too costly for fabrication in small quantities due to the amount of mainboard layers and size (~250 EUR for 5 boards that don't have components on them).
For teres 1.5 i want to mainly extend the functionality and life of the existing devices as teres by itself is very functional netbook once you put a faster eMMC into it and i want it to be a reliable device for an open-source development so that it's by it's own a portable laboratory.
The mainboard redesign is meant for teres 2.0 as it will enable additional form-factors and i want the SOM solution to always provide a method to wire up an ethernet port while the user should be able to easily adjust the platform board to the computing they want (ideally at home as i am working on a cheap 2-layer PCB fabricator)
--
In terms of engineering the IO board is nearly done and I am researching eMMCs that are compatible with teres and trying to figure out how to document them for users to be able to easily find and replace while making a catalog of open-source friendly technicians that would for a small fee (decided that up to 15 EUR max is good deal especially if the user removes the mainboard from the case and hands that out to the technician to work on) replace the chip for them if the user lacks the skill to reflow the chip on a hot air station.
The 3D printable case has a bottom part nearly done just needs a better management for the keyboard to maintain the ~2mm key travel (adjustable) and then i need to adjust the display part. If you have access to the 3D printer (or want to get the parts fabricated locally which is projected to be around 8 EUR) to test the case design then let me know and i try to publish the prototype of the case soon. (I have to take care of a sick family member so that makes the work take longer than i would like atm)
Optionally if you have a recommendation for laptop hinges that would also be helpful as i am trying to make a design that re-uses the original as those seems to be superior to the hinges in consumer common laptops (based on me using the laptop as a workout tool and continuously opening and closing it to see if it will cause any damage for multiple weeks and it surviving without any noticable change in behavior), but it would be a good information to have for comparison in case there is one that is sufficiently economical and performs better.
In terms of teres 2.0 development I read through the https://neo900.org project and trying to get a hold of the designers.
If you can get a hold of any of them and ask them what is the state of the gerber files meaning if they are expected to provide basic functionality once fabricated (judging by the kicad files) then that would help a lot as the kicads seems to be exported from eagle and it seems very sketchy as they require minor adjustments to show up correctly in kicad and it seems like there are probably a lot of fabrication adjustments for those to work without issues.
Few days ago i was able to source the spare parts for Nokia N900 to partially re-construct the body to get reference for the dimensions and placements of IO and other components and I am currently trying to figure if:
* Re-use the Nokia N900 case and make a PCB that fits into the existing phone
* Make a new design inspried by the Nokia N900
The re-using of the Nokia N900 case seems kinda like a bad idea, it's using a very ancient display technology and it looks very comical in my large hands :D If i were to use it i would probably scale that up 150% for me, but i was thinking that if there is an interest e.g. in maemo community that i could try making that
Alternatively I feel like making a Nokia N900-inspired design that can be 3D printed is a better option to have a constraint for the System On Module solution to be able to fit in the chip while being economical to self-fabricate and probably making 2 versions one that tries to match the dimensions of N900 and other that better fits in my hands.
Beyond this last year i talk with beagledevs (non-profit open-source hardware developer) about SOM and there seemed to be an interest in at least exploring that option so i plan on making a proposal to pitch to them so that in ideal scenario they would be providing a BeagleV-Ahead-SOM that fits in the teres design as that would outsource lot of management-induced pain off of me and having beagledevs and OLIMEX contributing and helping designing the SOM standard would be the dream.
I also talked with community member about the ability to stick a beagle cape at the bottom of teres (mainly about placing a CNC cape to aid the design of CNC router), which doesn't seem to be realistic for teres 1 and 1.5 as it would require jumper wiring to the mainboard, but it's an interesting direction for the SOM standard so that teres 2.0 could use it e.g. standard connector on the module board that can be connected to the pcb that accepts beagle cape or making a reference designs with platform boards that have this integrated.. or (their proposal) taking my idea of turning all OLIMEX's SBC into a thing that can slot into an MxM slot (from https://git.dotya.ml/kreyren/OSHW-System-On-Module#use-of-edge-connectors) and placing pins all over it that can slot into beagle-cape but that would probably look hilarious and wouldn't be too functional and/or require a lot of additional engineering bcs some chips need cooling and the size is very important to be kept as compact as possible, for teres 2.0 it might work if we make a custom heatsinks and place the module board below the platform board, but i am not sure that is a good idea
In terms of software for A64: https://git.dotya.ml/KREYLIMEX/TERES/issues/19 and https://github.com/NixOS/nixpkgs/issues/297358 which seems to be the same issue are currently the major problem as it seems that u-boot introduced a regression that broke regulators during u-boot phase that also affect the OS even when the kernel seems to have them implemented correctly, it seems that (with a major help from sunxi-linux people) the problem was found and i am working on a patch.
https://git.dotya.ml/KREYLIMEX/TERES/issues/17 (Adjust the kernel for all distros) i am struggling with getting CEDRUS to work, but beyond that the configuration seems to be understood and i will update the sunxi wiki with it soon
https://git.dotya.ml/KREYLIMEX/TERES/issues/2 (Adjust the DTS for sun50i to fix thermal trips for all A64 chips) -- I have a patch kinda ready, but it seems that diego is handling that so i am monitoring it.
https://git.dotya.ml/KREYLIMEX/TERES/issues/1 (Make HDMI To Work On All Distros Reliably) -- Can't get that to work on nixos, itycodes said that she's interested in trying to fix it, but doesn't have the device so i am trying to adjust my infrastructure to enable the development for it.
https://git.dotya.ml/KREYLIMEX/TERES/issues/4 (Fix Audio on NixOS) -- This seems to be a distro-related problem that has lower priority over the mentioned atm