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!

Allwinner A10-A20 CAN bus is working and with mainline drivers!

58_can_bus_2

CAN (controlled area network) bus is communication protocol bus standard widely used in Automotive industry. It uses only two wires for communication and is very robust and noise immune. This is why it also is used in industrial robotics and other areas where reliable communication for small amounts of data is needed.

A10 and A20 SoCs are known to have CAN bus controller inside but few years ago when we started the A10/A20 OLinuXino design nobody knew what is this CAN driver neither how to use it.

This is why when I read message on Twitter –

can1

I reply: “indeed, but on purpose, as no one has used this CAN or know how to use it, this would be just waste of components ”

Obviously things changed for the last couple of years as we have been feed with info about A20 CAN driver!

There is mainline CAN driver for A10/A20: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/sun4i_can.c?id=refs/tags/v4.4-rc8

CAN is documented http://linux-sunxi.org/images/f/f5/Sun7i-CANbus.pdf in fact it’s same as NXP SJA1000.

Sunxi-Can-Driver is on Github: https://github.com/btolfa/sunxi-can-driver

Linux-Sunxi mainlining efforts: http://linux-sunxi.org/Linux_mainlining_effort#Merged_into_4.4

Can4Linux is available also.

We quickly setup test with CAN transciever from AM3352-SOM-EVB and A20-OLinuXino-MICRO and build kernel with CAN support. Everything works!

Now we work on small board with CAN transciever on it which will enable CAN to be used on A20-OLinuXino-MICRO, A20-SOM-EVB, A10/20-OLinuXino-LIME and A20-OLinuXino-LIME2.

Fortunately when we made the board we kept same GPIO pin numbering on all boards so the CAN signals are on same places on all these boards and this makes the extension CAN board easy to route.

This will allow all our A10/A20 OLinuXinos to be used in CAN applications.

Friday Free Board Quiz – the prize is A20-OLinuXino-LIME

A20-OLinuXino-LIME-1

A20-OLinuXino-LIME is Open Source Hardware Linux board, it has native Ethernet, native HDMI, two USB hosts, USB-OTG and native SATA . Build in LiPo charger and DCDC step up allow to LIME to work on simple LiPo battery while keeping all peripherials like Ethernet, SATA, USB powered by the battery which makes it perfect for small home server.

You can win this board! To participate in the Quiz is enough to re-tweet the Twitter Quiz announcement message.

To double your chances you have to answer the Quiz question :)

The Quiz question is: What makes one project OSHW?

You have time to re-tweet and/or answer until Monday 11th of January.

In Monday we will post the correct answer and ask random.org to generate random number in range then announce the winner and ship the board by post/airmail.

Good Luck!

Previous Older Entries