FOSDEM and TERES I update

fosdem-1

FOSDEM was great place to present the TERES I, as there were the right people who share open source values.

We got lot of people passing through our table and got tons of feedback and suggestions. Thanks guys!

One of the most asked questions was: “can you make it with more RAM memory?”  The answer is yes, we can and we even have the memory chips which easily allow TERES I to be with 2GB RAM, but these are quite expensive than the mainstream memories as they are just two 4Gb memory chips put in one package with two Chip Select signals which A64 supports. As these memories are not so used their prices is more than double of the normal DDR memory price and this is why we though initially that this will be expensive option to consider. If we put 8Gb DDR memories on TERES I instead of 4Gb and make the RAM memory 2GB this will affect the price with EUR 15. Perhaps we should just add this as option when we assembly the main boards and people can decide what to buy 1GB or 2GB RAM version.

The 4GB mainboard eMMC flash is also quite humble for storage. Micron who manufacture this eMMC has also 16GB and 32GB versions, but they are very slow to deal with, just to receive quotation from their sale reps here needs weeks and even if you order they will tell you something like 20-30 weeks delivery time. For the moment this is no go. We use these 4GB eMMC in our other boards this is why we decided to use here too. The 4GB eMMC is in stock and we can produce right now. The micro SD card connector kinda solves the storage issue as you can use up to 128GB micro SD cards, but they are not so fast as the eMMC on board. Anyway if we could make deal with Micron later we could offer mainboards with more on board eMMC.

Another interesting suggestion was to add small SPI flash on the mother board. Initially as hardware guys we decided to not do this when we designed the main board. our though was: if you have eMMC 4GB on board which you can read with 100MB/s and write with 10MB/s why would you need slow serial SPI flash with small capacity like 4MB on board? We got explanation at FOSDEM why some people would love to have it. The SPI Flash could be used to have boot code from which A64 will always boot first. The SPI Flash could be hardware write protected, i.e. you will be always sure that your processor boots trusted software and no one could overwrite it except if he has physical access to your laptop and open the plastic and put the SPI to read/write mode again. The mainboard eMMC could be overwritten from user space, so considered as compromised media for secure boot by the people who care about their security.

One more good feedback was that A64 has OTP bits, one of which once set A64 will refuse to boot unsigned code, and no one knows how to sign code for A64 yet, so this effectively bricks your device and all existing A64 boards and tablets and laptops suffer from this problem. One could now write malicious software which to set this OTP bit and brick the A64 devices on the market. Fortunately there is A64 pin which enables and diables the OTP writting at hardware level, so we are going to disable OTP write by hardware.

Another question was “can I have better display with higher resolution?” Sure you can! TERES1 laptop has eDP interface which all laptop LCDs share, so any LCD with eDP interface will work, and of course will require proper Linux setting. Right now if you do not like the current 1366×768 resolution you can search for other 11.6″ with eDP connector and spend almost as the cost of the TERES I for LCD with IPS and 2K or 3K resolution, but franky we do not see the point of fancy graphics as TERES I would never be laptop for graphics developers anyway.

Other  people were asking: “can I have 16GB of RAM, SSD disk” No, unfortunately this is not possible. A64 is humble low cost processor, it has no SATA, so SSDs are not possible to connect except via USB which spoils the SATA speed. And IIRC 4GB RAM is the max A64 can address, but needs total mainboard rerouting. At this stage TERES1 would never be developer laptop which you can use to build Linux kernels, or do fancy graphics etc. We see it more like hacker tool. We made it lightweight, our target is to run on battery for long time, so you can get it while you travel. We work on FPGA internal board which you will be able to program with FOSS and to add Oscilloscope and Logic Analyzer capability at later stage while keeping all other hardware intact so it will be add-on board. We think of TERES1 as to become portable lab for hackers, to may program Arduino boards, sniff protocols at hardware level, capture analogue signals etc. it will be still good to browse internet, edit text files, code embedded software, but do not expect it to replace your desktop.

Good suggestion was to bring out the debug UART console so developer could see kernel messages without opening the laptop and solder wires. So we decided to add multiplexer and will bring Serial UART TX, RX, GND on the audio headphone jack which will be multiplexed by software, so the developers could just plug serial cable to Audio jack and debug.

Some people suggested us to place Arduino connectors near the touchpad where you add Arduino shields, this need a bit of consideration. When you do prototype work and experiments there is always possibility to damage your hardware, even now when we use Arduino we always put USB-ISO between it and the computer we use to program. With this protection we are sure that if we short something or feed high voltage to the shield by accident we will not damage our computer. So this is great idea but needs a bit of thinking.

Some people were asking: “do you think if this will be commercial success project, your laptop is so expensive, there are Chinese laptops for $50, $60, $100?”

Frankly we do not care too much about this, our core business is development boards and if you follow our blog you see that we have enough work. We spend more than year on TERES I so far and it was fun project and we learned a lot during the development. Now if it will be liked by many people or not is not so important, the important thing is that we made first step to bring to people, who appreciate open source an platform and template which they can use and improve both harware and software wise.

This is why we selected KiCAD as our CAD for designing TERES I. What is the point to release OSHW made with Altium or Eagle which will require your community to spend thousands of EUROs if want to study or modify your files? Every time you use proprietary tool to make Open Source you just decrease your community base just to people who can afford to buy the tools you used to design.

Now TERES I gives freedom to everyone to download KiCAD,  the CAD files from GitHub and people can view how it’s done, learn something new, and if you do not like something you can modify it up to your taste. You can’t do with any other laptop on the market.

Note that this is just the first step, the development and the fun will continue. Once we finish the software, add on boards we will look around for more new SOC candidates as well.

Not at least everyone was asking “when it will be available for sale?”. We build our first three prototypes 3 days before FOSDEM. While we worked more than year on the harware and we solved all issues there, the software is in quite initial state.

For the moment the only working Linux Kernel which supports all A64 features is the Allwinner Android Kernel. This Kernel is full of binary blobs, but the only one which could be used for demo. Beside the binary blobs many other things are broken, like the power management, different drivers like the LCD backlight PWM, wake up from suspend, eDP converter is not set properly and works just in 15 bit color mode etc etc. We have the hardware for 50 laptops ready (developer edition), but we do not want to ship before we take care for the software. At other hand we do not want to ship TERES I with Android or RemixOS also which are complete with binary blobs and will never be Open Source.

So let’s hope we will have good enough Linux support in couple of months and we can start the shipments, until then please wait patiently, we spend over an year and now we are close to the final 🙂

All above suggestions requiring the hardware modifications for the debug console, OTP lock, SPI Flash will be implemented in the next run when the software is completed.

 

TERES I Do It Yourself Open Source Hardware and Software Hacker’s friendly laptop is complete

teres

We are proud to announce that our TERES I laptop is complete. We have assembled units and now working on the software.

The building instructions are uploaded here and you can see that it’s pretty easy to build one yourself.

This weekend in Bruxell at FOSDEM we will have table in Hall AW where every one could touch and play with the very first built laptops.

All spare parts are uploaded at the web.

Hardware CAD files and Linux build scripts are on GitHub. TERES I is completely designed with KiCAD FOSS so everyone can download and learn, study, edit, modify.

Hardwarewise everything is OK and works, the software need some care to be completed, power supply management, Linux distribution, and few more details need attention, but we hope everything to be complete till Friday!

Final updates on A64-OLinuXino GMAC and eMMC, we are ready to launch production

A64-OLinuXino-1

We complete our test with Rev.B

Good news is that Gigabit interface works well with Micrel/Microchip PHY and result is real Gigabit bandwidth. A20 although having Gigabit interface can’t make more than 700 Mbit I guess this is related to A20 capability to handle the data from GMAC. With A64 the speed is  932Mbit i.e. very close to 1Gb:

root@A64-OLinuXino:~# iperf -s 
 ------------------------------------------------------------ 
 Server listening on TCP port 5001 
 TCP window size: 85.3 KByte (default) 
 ------------------------------------------------------------ 
 [  4] local 10.0.0.4 port 5001 connected with 10.0.0.1 port 41144 
 [ ID] Interval       Transfer     Bandwidth 
 [  4]  0.0-10.0 sec  1.09 GBytes   932 Mbits/sec

 

For eMMC we followed the advice to make it dual voltage 3.3V and 1.8V with aim to have faster transfers and we implemented it in the hardware, but the tests show that transfer is same even at 1.8V is a bit lower. I don’t know if this is due to lame software settings we do in the eMMC drivers, or just the eMMC we use have same transfer on both voltages (we check datasheet and the eMMC we use have same speed quoted on both voltages), so this may be useless for our eMMC chip:

eMMC clock: 52 Mhz

eMMC@3.3V 
root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/mnt/output conv=fdatasync bs=384k count=1k; rm -f /mnt/output 
1024+0 records in 
1024+0 records out 
402653184 bytes (403 MB, 384 MiB) copied, 33.0437 s, 12.2 MB/s 
 
eMMC@1.8V 
root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/mnt/output conv=fdatasync bs=384k count=1k; rm -f /mnt/output 
1024+0 records in 
1024+0 records out 
402653184 bytes (403 MB, 384 MiB) copied, 37.9408 s, 10.6 MB/s 
 
SDMMC clock: 40MHz 
 
SDMMC@3.3V 
root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output 
1024+0 records in 
1024+0 records out 
402653184 bytes (403 MB, 384 MiB) copied, 41.1578 s, 9.8 MB/s 
 

With SDMMC as we don’t know what SD card will be inserted the clock is set to default 40Mhz.

After re-checking that everything works, we make last cosmetic changes to audio part we noticed in the last moment and will run Rev.C in production.

TERES-I DIY Open Source Hardware hacker’s Laptop update

keyb

It’s have been long time since I blogged about our laptop project.

What is the status – we have first PCBs prototyped and most of parts works fine.

We had to make Matrix keyboard + I2C touchpad to USB converter board. We did this with small AVR.

For this project we couldn’t use any of our standard connectors – we had to source all new: mini HDMI connectors, USB host connectors, power jack, audio jack connectors all they had to be low profile and embedded inside the PCB, hence this off form of the main PCB:

PCB

The LCDs used in laptops are not as the normal LCDs, they are very thin only 3mm or less and as their cable is special as must have as low as possible number of thin wires knitted together in very thin round cable, is has to go through laptop plastic’s hinges and normal cable can’t fit there. This is why all laptop LCDs are not parallel RGB neither LVDS but use eDP interface.

For bad luck A64 do not support such interface so we start to search LVDS/HDMI/RGB to eDP converter ICs. What we found is that Western suppliers solutions (TI etc) are more expensive than A64 chip itself so no go. We found Chinese solution for $1 NCS8801 and we said – well this is our solution 🙂 we made PCBs prototype and sourced few chips then we struggled by the lack of documentation 🙂 The ‘datasheet’ is 30 pages and the only code which is on the net initializes registers at addresses not mentioned in the datasheet, after spending almost 4 weeks on this we gave up and start looking for another solution. We found ANX6345 which is a bit more expensive but has some code in Linux Kernel and seems used with Rockchip ICs, so we hope this to solve LCD issue. We designed new board and got the new prototypes few days ago so they wait open window on assembly line to be assembled, crossing fingers everything to work 🙂

The mechanical parts has their history too. In June we placed orders to several different suppliers for the plastic parts, speakers, touchpads, power adapters, screws, hinges, total 40 different parts which are inside the laptop. The orders were complete in July and consolidated as one shipment on August 6 they were expressed with TNT and 2 days later were at Sofia airport, but the troubles just began 🙂

To import something may seems very easy for outsiders, but has it’s tricks. Usually every component can be classified in several positions in customs tariff, for instance LCDs have at least 7-8 different codes at which they can be imported, like they can be classified as display for computing equipment, as display for TV, as display for signage, as display for metal processing machine, etc etc. The trouble is that all these positions had different import tax 🙂 and of course Bulgarian customs try to force you to pay on the highest tariff code unless you prove them other. Another issue is that there work mostly people with economic education and very few know electronics matter. Import tax starts from 0% for computer parts and go up to 4-5% for TVs and machines, not small amount when you talk for $200 laptop parts! So laptop parts were sitting on customs 3 weeks as customs officers were trying to tariff every hinge, screw, plastic etc part as different product to tariff it with the highest code. Fortunately after 3 weeks of thinking somebody with common sense allowed all laptop spare parts to be imported as such with 0% tax and we got them today, but the fight will continue as this was only 10% of the order which we wanted to receive promptly paying expensive air transport, remain 90% parts still travel by sea and will arrive end of September, so let’s see how they will tariff these when arrive 🙂

We get lot of request when the laptop will be done and we love all our impatient customers 🙂

Guys be sure that we do anything humanly possible to release it as soon as we can, but to design something from scratch which you had never did before is not easy, once we do this I’m sure we will easily make 10 other laptops, but first time is always more difficult, to arrange logistic of so many parts and produce is not less challenging.

 

P.S. I hope you like the “Super” key on our new keyboard above 🙂

A64-OLinuXino update, the Rev.B design will be possible to produce in industrial grade -40+85C, dual voltage eMMC 3.3/1.8V

А64-1cut

A64-OLinuXino first prototypes were made in March and lot of people wonder why we do not release for mass production this board yet 🙂 so we got lot of e-mails and I see there is need for blog post with update.

Here is the recap from the first prototypes:

  • RAM memory works at amazing 667Mhz clock much more than A20 and other boards and the board works stabile under stress tests for many hours
  • eMMC works fine, we didn’t test NAND Flash due to the missing Linux support probabbly this will stay just as option and we will assembly the boards with eMMC which is faster, better and in industrial temperature
  • Linux Kernel is 3.10.65 and works fine, we managed to run all peripherials
  • Audio In and Out is working
  • HDMI is working
  • USB host is working
  • USB-OTG is working
  • WiFi+BT is working
  • MIPI interface – no display which to use to test, any ideas?
  • HSIC interface – don’t know how to test, any ideas?
  • LiPo charger and step up works
  • LCD works
  • Ethernet Gigabit interface works just in master mode

While we worked on this board we found new PHY from Microchip which can be ordered in industrial temperature, we tested it with A20 and it works fine (we already have LIME2 version with it which is on prototype), so we decided to re-design the Ethernet part of A64-OLinuXino with it, this will allow us to produce A64-OLinuXino in industrial temperature grade -40+85C.

Another major upgrade for Rev.B is around eMMC interface, we re-designed it as per your feedback to be possible to work on programmable 3.3V and 1.8V thus to allow faster transfers.

Rev.B is routed at 90% we need 1 more week to complete it and run new prototypes. If everything goes smoothly we will be ready by end of the month.

 

Appnotes and Tutorials about Debugging UEFI and Linux Kernel on Intel SoCs with OpenOCD and ARM-USB-OCD-H or ARM-USB-TINY-H

INTEL-OPENOCD

Intel made nice video tutorial how to use OpenOCD and our JTAGs with their SoCs! This explains the frequent purchases they do from many Intel locations all around the world of ARM-USB-TINY-H , ARM-USB-OCD-H and ARM-JTAG-20-10.

Searching bit more there is application note How to setup ARM-USB-OCD-H with Intel Quark SoC X1000 and tutorials about Low-cost UEFI debugging options for Intel and How to debug Linux Kernel on Intel Quark

How to root any Allwinner device running Android and most of the Chinese “Pi” clones which bet on Allwinner Android Linux Kernel

3

I got this interesting Tweet this morning from Ken Tindell @kentindell

I decided to check what is this about and expand the message … then LMAO!

1

David Manouchehri ‏@DaveManouchehri found interesting code in the Allwinner GitHub https://github.com/allwinner-zh/linux-3.4-sunxi

What does this means? If string “rootmydevice” pass through sunxi_debug process it assigns you root privileges.

My first though was who the hell will use the original extracted from Android Linux Kernel 3.4 made by Allwinner which contains binary blobs, when there is completely Free Open Source alternative developed by Linux-Sunxi community?

…and while thinking on it, scrolling down I found this:

2

some guy decided to try it on his Orange Pi – you see the result, he got root access to the device by simple echo command!

Damn! and this is put with non-conditional flags i.e. embedded always in the kernel you can’t remove it!

If the guys from Allwinner were smart enough they would at least hide this in the binary blobs, so no one could see it!

This is just yet another example what you are exposed to when use kernels which are with binary blobs inside, not speaking of the security quality of the code which Allwinner developers produce!

Fortunately we use Linux-Sunxi community kernel which is 100% open source and no binary blobs!

(well if you want hardware acceleration GPU drivers are still with binary blobs and no one knows what is inside, but this looks like heap of works and no one is interested to liberate them so far).

here is what OLinuXino Kernel responds on the same command:

4

What does this means? All devices which run Allwinner Linux Kernel 3.4 are subject to this backdoor security flaw and you can easily gain root access on any on them!

Previous Older Entries