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

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.

Ethernet-Be-Gone with RT5350F-OLinuXino-EVB

We proudly announce that we got new product – LAN killer🙂

We found this new feature during our normal development work. If you power up RT5350F-OLinuXino-EVB connected to local network and you do not up the Ethernet interface within 5 minutes (like if you loading new firmware in the SPI Flash or debug) the local LAN stops working! All attempts to hit sites outside return DNS error.

It’s weird as if you up the Ethernet interface everything is fine, also this DNS block begins not immediately but about 5 minutes after you power the board connected in the network.

Our internal LAN is hairball for sure, but we are puzzled why this happens?

Can someone with RT5350F-OLinuXino-EVB try and confirm our findings?

We did another experiment with USB-Ethernet-AX88772B, we plug it to one of our Linux boards with USB host like A33-OLinuXino and do not up the interface and same problem is reproduced.

I’m sure this is probably our intranet lame settings, but it will be interesting people with more experience to share what cause this problem.

Meantime if you want to piss off your boss or colleague … you know what to try :D

 

A64-OLinuXino-eMMC rev.B OSHW 64 bit ARM development board prototypes are testing

What you see is our improved REV.B of A64-OLinuXino. What’s new:

• Gigabit PHY is now KSZ9031 from MICROCHIP/MICREL which allow board to be produced in both commercial and industrial grade!
• DDR3 is now DDR3L for lower power
• we add SPI flash footprint U12
• Audio input now is jumper selectable between LINE-IN and MIC-IN
• eMMC now can work on software selectable voltage 3.3V or 1.8V which would allow faster speeds
• status LED is attached to port PE17
• size 90×60 mm

Now we do final software tests and if everything is OK we will run production.

 

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

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:

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🙂

Free Electrons add mainline Linux kernel support for the A13 Allwinner VPU

Posted today on Free Electrons blog.

19 years old intern in Free Electrons took the Cedrus reverse engineering of Allwinners proprietary CedarX video driver who is around since mid 2014 and made patches for mainline Linux kernel.

I’m sure we use these since they were made first available and they are build in our images, so I’m really puzzled why they have made their way to mainline just now and not earlier?

Isn’t it time Linux-Sunxi community to stop working on kernel fork and start to send all development and patches upstream like Rockchip developers do already for 2 years?

Looking at mainline kernel Rockchip has way better support now than Allwinner although Linux-Sunxi community to seem many times bigger than Rockchip community.

Rockchip devices are in many Chromebooks and Google push them to send all their work upstream to latest kernels.

None of newer Allwinner chips found it’s place in Chromebooks and this is the problem, for Android kernel 3.10 is enough and they will not move from it, neither they learn (or are capable to generate quality code) to upstream all work they do.

This is pitty as since A10/A20 we can’t see anything which to beat Rockchip as productivity.

RK3288 is mainline and although Cortex-A17 still faster than any chip Allwinner have.

Now Rockchip work to release their new super duper RK3399 (2x Cortex-A72 and 4x Cortex-A53) and again they upstream code before even selling the chip.

With two USB3 hosts this chip is good candidate for next OLinuXino🙂

 

EDIT1: after the posting there were interesting comments from  Chen-Yu Tsai (a.k.a. wens213) who point me that what Free Electrons did is not simple commit to already existing project but did from scratch v4l2 mem-2-mem codec driver! So I appologise for the underestimated efforts!

EDIT2: I admit that what I wrote about Linux-Sunxi repository was about Kernel 3.4 which I was using two years ago and which was developed “wild west” style. I was assuming as the repositories are still there this continues, but I was wrong!

Our boards are with A10/A13/A20 and have mainline support, so I didn’t followed closely what happens with Linux-Sunxi lately.

Chen-Yu and Siarhei explained that this repo is kept there for historical reasons and now all development is focused to upstream too! Good to know🙂

At Linux-Sunxi there is very clear table about what is done ( light green) and on what is working (ornge)

 

 

iCE40HX8K-EVB OSHW prototypes are ready to test

What you see is our new iCE40HX8K-EVB prototype.

It has same layout as our first iCE40HX1K-EVB board with same 34pin bus connector where iCE40-IO, iCE40-DIO, iCE40-ADC and iCE40-DAC modules could snap together.

We made all connections backward compatible so all code for 1K will work on 8K too. just here you have much more resources and more GPIOs which are wired to 4 small 40 pin 0.05″ step connectors. These can be connected to external boards either with cable either with female matching connectors which are in our shop.

Now we are testing for silly mistakes, if everything is OK will run it in production next month.

The price will be EUR 39.95

 

CT800 – embedded FLOSS Chess computer made with STM32-H405 OSHW board

We got interesting project link from Rasmus Althoff: CT800 is Free/Libre Open Source Software CHESS computer made with STM32-H405 Open Source Hardware board inside.

It has around 2100 ELO, maximum search depth 20 plies. The software is done in C and released under GPL3 licensee.