bozden

Tesla MCU1 eMMC failure
https://tesla-info.com/blog/tesla-mcu1-emmc-failure.php
 
 

Follow-up:
 
After compiling the kernel with usbtouchscreen as module and enabling it + apt-get xinput & xinput-calibrator , my touchscreen worked.
Axis were inverted, so a transformation matrix is needed on /etc/X11/xorg.conf.d/99-calibration.conf:
 
        Option "TransformationMatrix" "0 -1 1 1 0 0 0 0 1"
 
On the other hand it needs some scaling as I cannot reach the screen's edges. As far as I can see it can only be done by trial-error - a very tedious task.
 
By looking into /var/log/Xorg.0.log I can see the TransformationMatrix is read, but not other parameters suggested by xinput_calibrator mentioned in the log, so I'm not sure if they are relevant (modifying them had no effect).
 
That's it for now...
 

I fully understand this, that quote was attribute to "No end-user support: built from trunk" wording in motd
 
I learned linux playing with these SBC's, mainly Armbian and it is a hobby for me. I have several installations at my home-office as hobby projects. If I ever earn some money from these stuff I'll donate it. But for this or helping others on the forums, I need to learn first  
 
Things like chroot environment, kernel parameters, kernel compiling are very new to me. The build script is very high quality code from my perspective. Last week, by examining it I learned a lot. For example the "wait_for_package_manager" function in general.sh provides solution for some of my problems. Kudos for @Igor and everybody contributed.
 
I'll try to "document" my adventure for other newbies.
 

Yep  For years I ran away from that, too much detail for me - and I was afraid to fail, Linux is my second language . I spent last night on reading and applying, as of now I already have build all default images for all my boards.
 
I was using scripting to modify the default setup, probably I will be able to create special purpose images (I think, I hope, ...).
 

I feel so dumb !
 
After many hours of tcpdump'ing and log tailing I found my mistake... Just to record this unfortunate event:
I first installed pihole DHCP for the exterior network (192.168.100.0/24) then moved to home-network (192.168.64.0/24) side.
On the web interface there is a "Router (gateway) IP address" and my router is in at 192.168.100.2 - I left it as it is  That should be on the same subnet of course  Changed it  and it worked...
 
Sorry for your time 

I have just watched the documentation of this swiss guy, he not only explains in detail, he also puts massive load on the cable and film it with a infrared camera.
 
As a rule of thumb, 50cm maximum length and at least AWG 22 copper leads are the bare minimum
 
but hey, watch it yourself and see with your eyes
https://www.youtube.com/watch?v=n70N_sBYepQ
 

I managed to test the 1.4 version with the set up in the image attached.
 
I admit the ti sensor tag thermopile sensor is not at all a good way to test it.
 
The test I ran:
I let the device cool down completely between tests, then set the power supply to a selected voltage (for powering AVCC/RTC) and logged in. Then I waited for about 3 minutes while looking at the output of the armbianmonitor -m for the temperature to stabilize. Then I ran the following command:
sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) while watching the remote sensing temperature output from the sensor tag.
 
here is what I got:
 
 
and :
 
 
....According to the results, it runs faster and hotter at the expected temp of 3.3V.
 
I only tested a few times, but I am now of the opinion that these chips will run hot one way or another.
 
For my application, I will be giving it a 3.3V regulator and a nice heatsink.
 
Further testing would probably benefit from a more directly attached temperature sensor/ more accurate thermopile & logging.
 

Just a heads up, I think the bigger issue between the revision 1.1 and 1.4 is that they removed the "U5" buck AVCC/RTC 3.3V converter, Instead in its place they put a "R9" 0 ohm resistor from the GPIO 3.3v regulator "u55". As such it makes sense that they removed the "Q11" gpio voltage enable switch, since now that switch must always be on.
In testing the voltages, the Rev 1.1 GPIO VCC is 3.37v, whereas the AVCC/RTC Vcc is 3.27v.
For Rev1.4 though, the GPIO/AVCC/RTC Vcc is actually 3.4v.
I am currently removing "R9" from rev 1.4 and installing a diode to drop some voltage. It may help to keep the device from overheating. If that doesn't help, perhaps adding a secondary 3.3v buck regulator can fix the issue.
 
Update: With the diode to drop voltage, the resulting voltage on AVCC/RTC is 2.91V.
This results in the following temp readings stable/finger tested:
19:02:53: 1200MHz  0.71  19%  11%   6%   0%   1%   0%   -2°C
19:02:58: 1008MHz  0.73  19%  11%   6%   0%   1%   0%   -4°C
19:03:03:  240MHz  0.67  19%  11%   6%   0%   1%   0%   -9°C
19:03:08:  240MHz  0.62  19%  11%   6%   0%   1%   0%  -10°C
19:03:13:  240MHz  0.57  18%  10%   5%   0%   1%   0%  -11°C
19:03:18:  240MHz  0.52  18%  10%   5%   0%   1%   0%  -17°C
19:03:24:  240MHz  0.48  17%  10%   5%   0%   1%   0%  -20°C
19:03:29:  240MHz  0.44  17%  10%   5%   0%   1%   0%  -21°C
This leads me to believe that the temperature may not be significantly if at all different between v1.1 and v1.4. It would make sense for the slight voltage difference of voltage on the AVCC pins would change the internal temperature readings. They probably don't have any sort of voltage reference internally, and that would lead to any sort of internal reading based on analog voltages to be affected by voltage changes of the AVCC power.
I will test this with a power supply on the seperated AVCC/RTC to see if it does indeed result in different internal readouts.
 
 
Alright, here's what I found:

All of these results are running the armbianmonitor right after start up and each show a "finger test" draw represents draw on the Avcc/rtc  from the power supply, and is quite stable.
 
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.27 about 50mA draw during test:
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.4V about 50mA draw during test:

Orangepi v1.4 test: r9 removed, AVCC&RTC=2.90V about 40-50mA draw during test
 
Results: The internal temperature sensing cannot be trusted, especially since there is no voltage reference.
Tomorrow I will try to place a 150mA 3.3V LDO regulator instead of "r9" and see if I can find a way to actually test temperature.

PS: I would add images if I could figure out how to do so outside of hosting them somewhere else.
 
Sidenote:
"R9" is glued down, so to minimize chance of lifting pads when desoldering try this:
1- apply generous amounts of flux from flux pen.
2) use solder wick to remove as much solder as possible
c Once all the solder is gone, rotate the part 90 degrees with flat end needle nose pliers while slightly pushing into the board.
 
If you managed to get enough solder off, the part should break free without lifting the pads. And if they do lift, you can always solder onto the test points on the board.

I did take a look for an overview ( http://orangepi.com.tr/destek.html )  and all I could see was fine
They also added the R1 which before wasnt there

..and I would also thank @bozden for contacting OrangePi.com.tr in native turkish language ;-)

Hello
 
We very thank you for your studies on Orange Pi items.
 
Orange Pi Turkey organisation is managed by “Sersa Teknoloji”. Sersa Teknoloji is a company which serves in technology sector since 1991.
 
We support personel and institutive studies in Turkey with Orange Pi items. We send items to all European Countries, not onlyTurkey.
 
The main reason of providing download links from our servers in orangepi.com.tr web page is that the users in Turkey can not download via orangepi.org. There were same problems in Europe side as well.  
 
We would like to activate another web page for providing the files to solve these problems. But then, since orangepi.org provided the alternatives of  “Google drive and Mega”, we keep only serving “Armbian” ones.
 
Our aim is to provide accessible download web page for the users, we dont have any other aim.
 
We support Armbian OS because they provide easier experience for users.
 
We are very thankfull to Igor and other persons in the Project.
 
We also very thank you to “Guido Imran Lehwalder”  who contacted with us for needed arrangements.
 
Regards
Volkan Bahçeci

I've got confirmation that the links are corrected, I waited for them to announce it here but anyway. @Igor can you please cross-check it if you have time

I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...
 

I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...
 

Here in turkey they got a own webpage for/from Orange Pi:
http://orangepi.com.tr/index.html
 
On their download-pages for the Orange Pis they have mostly armbian-images linked.
OK, old 5.25 ones - but they refer for other Operating Systems the normal Orange Pi webpage.
Download Page is http://orangepi.com.tr/destek.html , but you have to select the model of the OPi.
 
Orange Pi Türkiye Armbian İşletim Sistemi'ni önerir.
Orange Pi Turkey Suggests the Armbian Operating System.
 
The NAS-Expansion for my OPi Zero/R1 did I get from the distributor here in Turkey (Türkiye):
https://www.robotistan.com/orange-pi
 
For me the new best way to buy OPis here (1-2 day delivery against more than a month from china)

I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...
 

Well, I'm pretty sure they can understand English. But I'm here to help of course... We are already in contact with @guidol
 

Maybe @bozden can help here? IMO it's really important that if 3rd parties try to directly link to Armbian images (and not the download pages) that they use those generic links like 'Ubuntu_xenial_default.7z' which will be resolved automagically to most recent OS image in the background. It's sad to see outdated images being spread...

For what it's worth, and one of the most discussed topics can now hopefully finally closed: Mali in mainline
 
Did not try it, but the source is trustworthy to my humble knowledge... Still no open source release, but I guess it silences a lot of people questioning for Mali support!
 
For the real Mali die hards, here is a link to some more background info: Free Electrons

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

I used the case yesterday with a v1.1 PCB OPi zero for testing. It was just running "aplay" looping though some songs (strictly less than %5 CPU load). The test started at 46 C and reached 65 C in 10 minutes (full power limit). And 5 minutes after that I had a full system failure and it did not start again (I'll look into it when I have time). So I threw the case away.
 
In this current status the box is not usable without active cooling. As the expansion board covers the SOC a fan on the top does nothing and the sides are also not an option. One side is covered by the expansion board's header and I wanted to spare the other side for I/O as you will do - and that would require a ribbon cable which also should prevent airflow. 
 
I asked for an alternative design in their forums but I think a 3D-printed case designed for you application is the only viable option as @chwe suggests.
 

Well, I'm not a developer from the OS perspective, I'm merely a learner writing in C and providing solutions with arm boards and Armbian.  From the end-user perspective,  something like this would be invaluable for me:
https://www.w3schools.com/cssref/css3_browsersupport.asp
 
If I have an idea to implement I look at the board/feature matrix and choose a board/branch combination. IMO that would decrease the noob questions tremendously.  A board manufacturer says "very good for desktop" for a board with 256 MB RAM, but having this matrix would correct it. Just use the red-yellow-green colors in the matrix cells
 
2c
 
 
 
 
 
 

Well, I'm not a developer from the OS perspective, I'm merely a learner writing in C and providing solutions with arm boards and Armbian.  From the end-user perspective,  something like this would be invaluable for me:
https://www.w3schools.com/cssref/css3_browsersupport.asp
 
If I have an idea to implement I look at the board/feature matrix and choose a board/branch combination. IMO that would decrease the noob questions tremendously.  A board manufacturer says "very good for desktop" for a board with 256 MB RAM, but having this matrix would correct it. Just use the red-yellow-green colors in the matrix cells
 
2c
 
 
 
 
 
 

Well, I am the only poor guy to have the board.  ;-)
 
 

I just want to share what I examined yesterday...
 
Background:
I used OPi one to output HDMI video when a button is pressed. It has an attached fan, a remote shutdown button and a remote switch to turn power off-on (OPi is hidden and operated through these buttons). It worked on breadboard, produced 2 working examples, tested the first two with a 24h test. All fine...
 
Problem:
On a third installation after the "circuits" are built, I made a last test. HDMI output had problems  Sound comes and goes with a hick-up...
 
Debugging:
Checked wiring, checked with other video, checked with other OPi etc. Nada... The problem persisted.
 
Lastly I checked the voltages. The output from the 2A power supply is 5.3V, (it goes to the switch and comes back) and the input to OPi is about 4.7-4.8 V !!!!!
 
What the heck...
I measured the full two way resistance of the power switch "circuit" as 1.2 Ohms. Well, not much
 
Ohms law does not say so. Opi amperage is around 0.3-0.55 A in my application depending on video usage.
Assuming 5 V and 0.5 A, the voltage drop on 1.2 Ohms line is 0.6 volts. Huh, this makes it 4.7 V on OPi... 
Knowing possible issues beforehand I used quality 23 AWG full copper FTP CAT6 cables for data lines, but just used simple 2x1.5mm2 power cable - a 5.4 mt long two way trip. But it was not the problem either... Measured the switch, measured the 5.4 mt cable... But:
 
I used some cheap jumper cables (which I ordered from China), and connected the switch to a protoboard with them (easy to solder and plug), and those 2x20 cm cables had a huge resistance... 
 
I connected the switch with a thick cable and voila, the voltage at OPi is 5.0 V...
Other installations did not have this issue because the wire lengths were now so high.
 
Just wanted to share for those having issues... Bad voltage may manifest itself in very different ways.
 
Actually, the most problematic part while working with *Pi's is usually the USB power cable quality. What happens to your phone (did I hear you complain on slow charging?) also happens here. In my experience a simple SMPS with 2A rating usually works well in those amperage, but cheap power cables suck !
 
Did we get through all our copper resources on this planet? Damn!