Armbian customization

[tkaiser]

Any way I am trying to find stable Armbian build for Lime2-eMMC board.

This includes the best DRAM settings of course.

So any help in this direction is welcome.

 

As already said: You need a large sample size and the correct test setup, then validation of the results to get sane defaults (using some safety headroom). Or a methodology to determine DRAM settings for individual boards (also possible to test for reliability individually as part of a 'burn in' process -- applies to dvfs/cpufreq stuff too)

 

For sane defaults I would say we need at least 30 boards to test with. And in the meantime we (as Armbian devs) should again think about decreasing u-boot DRAM clockspeeds where it's known to ask for troubles (Cubieboard 2 as another example)

[chradev]

Thanks Tkaiser,

As already said: You need a large sample size and the correct test setup, then validation of the results to get sane defaults (using some safety headroom). Or a methodology to determine DRAM settings for individual boards (also possible to test for reliability individually as part of a 'burn in' process -- applies to dvfs/cpufreq stuff too)

 

For sane defaults I would say we need at least 30 boards to test with. And in the meantime we (as Armbian devs) should again think about decreasing u-boot DRAM clockspeeds where it's known to ask for troubles (Cubieboard 2 as another example)

From my point of view individual testing and casting of DRAM, CPU etc. parameters for each board is not acceptable.

To prepare and fulfill large sized tests is not feasible  without Olimex interest and share for the moment as well.

 

As a part of my effort I will try to prepare appropriate test setup and a methodology to assess results.

I will apply them for the boards passing through my hands.

When the staff is ready I will publish it for testers willing to spend a time for testing on their boards.

In addition I can try to talk to Olimex for expanding the tests over a number of batches as a part of their production cycle.

 

Unfortunately, above is a long term task so I need of short term solution based on limited resources (2x Lime2-4GB rev. C and 3x Lime2-eMMC rev. E boards).

 

The good news is that decreasing of DRAM speed to 384MHz solves the hanging problem and it is probably good figure.

BTW the build with 384MHz DRAM speed I started yesterday is working without any hangs at high load for more than 10+24h.

 

One more question: I have noticed that max CPU frequency in U-Boot v. 2016.07 is decreased (912MHz) - can it be correlated with the hangs observed?

 

Best regards

Chris

[tkaiser]

From my point of view individual testing and casting of DRAM, CPU etc. parameters for each board is not acceptable.

 

Well, in the long run I want to have exactly these abilities included in Armbian. Providing an easy way to fire up an automated set of tests to test for individual reliability boundaries. For DRAM reliability testing a bunch of different u-boot debs is all that's needed and a test setup that incrementally increases DRAM clock until the first error is reported.

 

For CPU clockspeed limits it's somewhat harder since with all more modern SoCs it's necessary to temporarely improve heat dissipation a lot (read as: heatsink and most probably also an additional fan) to test reliability of higher cpufreq operating points at lower VDD_CPUX voltages. Have a look at http://forum.armbian.com/index.php/topic/1493-add-armbian-test-reliability-package-to-our-repo/ if details might be interesting for you.

 

If I were you I would join linux-sunxi IRC and try to get in touch with ssvb and oliv3r since the latter has access to huge amounts of Lime2 boards and the former might already have prepared a test suite.

Then regarding clockspeeds: 384 MHz for DRAM are most probably too low, Lime2 should be able to be clocked higher. No idea what changed why in u-boot (since I do not trust in many/most settings there for the boards we support)

[chradev]

Thanks Tomas,

 

I take a brief look on the links you point. It is very interesting an I will read them more carefully. I will try to get in touch with ssvb and oliv3r as well.

As a beginning I see some obstacles to use some of the components because I use highly customized headless system based on mainline kernel.

 

Thanks to my previous experience I know that the memory problems are the most difficult to find especially if they occur very rarely.

The best results will be achieved if all CPU cores are 100% busy in parallel with intensive DMA access (like at disk and net operations).

That is why I use a combination of 'stress', 'iperf' tools and RPI Monitor. Of course it is very important to have good enough cooling.

 

In our use case the cooling is passive but very efficient because a massive Al cooler is attached to all Lime2 chips (PMU, CPU, DRAM and eMMC Flash) and to the wall of big Al box.

As an example using the test setup described in my previous post I have succeeded to hang the system (at 480MHz DRAM speed) for 40 and 10 minutes in 2 consecutive runs.

In test case when system hangs after 40 min CPU load gets up to 6.5-7, network bandwidth - up to 450Mbps while heating rises with 6.5°C for PMU, 3°C for CPU and 2.7°C for Cooler.

 

After some consideration I suppose that above test setup with combination of series of U-Boot images having different DRAM settings (not only speed) are good instrumentation.

I will try to arrange some HW setup for testing a few boards in parallel to get better test performance.

 

BTW can I check DRAM speed from running system?

 

Best regards

Chris

 

[tkaiser]

BTW can I check DRAM speed from running system?

 

With mainline kernel I doubt. When I'm doing these sorts of tests I try to ensure that everything is setup correctly. You should at least execute tinymembench automatically and log results before each run (since you can only adjust DRAM clockspeed from u-boot a reboot is necessary). And IMO it's a good idea to check how lima-memtester works (executing intensive stuff on the GPU which has to start a battle for DRAM access with the memtester running on the CPU cores)

[neomanic]

I have 5 Lime2-emmc boards sitting on my desk (for future installs), and I can run DRAM tests on them next week.  I'm running mainline, and was pretty sure that the RAM speed was set to 384 MHz, but will double-check my u-boot compile.

 

Having a varying cpufreq definitely caused crashes, so I've locked it at 960 MHz.
 

I will do what @chradev suggests; stress, iperf and RPi monitor, but if anyone has a preferred option, I'm all ears.

[splite]

Hey !

 

I have experienced a lot of crashes as well with no idea from where it was coming from. I used over 50 Olimex Lime2 (no NAN, no eMMC) boards from several revision.

 

The one I have now are Rev. C, but I had boards hanging with Rev. E as well

 

I tested Armbian with legacy and mainline Kernel and different flavor of U-boot (2015, 2016) with no improvement...

 

An easy tool to stress and test the system is stress : stress -c 2 -i 2 -m 1 --vm-bytes 300M -t 60m

This test was enough to make the board hang after 20-30 min.

 

I read @chradev was experiencing hang with his boards and I try to reduce CONFIG_DRAM_CLK at 374Mhz instead of 480Mhz. I then created a new image and boot my lime2 with this new image (A reboot was needed to take the new clock speed).

Result : The system is stable, stress run over an hour and half with no hang !

 

Thanks for the tip !

 

I'd like now to use Lima-memtester as @tkaiser said in order to find the right setting.

 

How badly the performance can be reduce from downgrading the clock speed to 374Mhz ? I can't find over Internet (mostly GitHub) an other setting than 480Mhz...

[chradev]

Hi Neomanic,

 

It is good idea to do memory tests on the 5 boards you have.

 

As mentioned before 960MHz DRAM speed is probably too low.

That is why tests with bigger speeds have to be made for finding the biggest reliable value.

Unfortunately, much more boards (30 as mentioned above) has to be used for spreading the result to all Line2 products.

 

I have to mention that Lime2 has 3 production options (with 4GB NAND, eMMC and without flash) and a few HW revisions (C, E and upcoming F and G).

So both flash option and HW release (related to PCB changes and more important) have to be added to the tests results.

 

On the other hand as found in my temperature tests good cooling is very important in case of using the board in closed box or for intensive tests.

The Al heat-sink offered by Olimex is definitely insufficient. Fortunately, Lime2 is well designed for efficient cooling but the board fixture is terrible.

So the solution found by me is proven to be good even while charging the battery at long term very intensive CPU and network load.

 

For being clean the cooling solution used by me is based on a big 15mm thick aluminum thermal conductor (cooler) with appropriate shape for contacting to all chips (CPU, PMU, DRAM and flash) via thin (less than 1.5 mm) thermal pads (6 W/mK). Cooler also contacts with its other side to the box wall via ARCTIC MX-4 thermal compound (with carbon micro-particles). The board is pressed by Al plate and 4 rubber pads (6mm thick) agglutinated to the bottom board side. Al plate is fixed with 4 bolts and bushes with exact length (20mm in case of 15mm collier thickness) for achieving enough pressure. For better fixture bolts and bushes are placed in the 4 big semi-holes provided for fixing the board into Olimex' plastic Lime box. In one of my use cases for fitting in 31.5 mm box the SATA SSD is used for pressuring the board instead of Al plate and cooler is 12mm thick instead of 15mm. For comfort placing of all staff 160x165x51.5 mm Al box is used but smaller (160x125x31.5) one can also fit.

 

Cooler shape and mounted board picture can be found in the attached files.

 

One drawback in used solution is inability to use additional board directly plugged to Lime2 connectors.

That is why a plane cable (from Olimex) can be used to connect extension board(s) as visible on the picture.

The alternative is to use board to board connection but extension board has to be bigger with hole for the cooler.

 

Best regards

Chris

 

ThermoConductor.pdf

[chradev]

Hi Splite,

Hey !

 

I have experienced a lot of crashes as well with no idea from where it was coming from. I used over 50 Olimex Lime2 (no NAN, no eMMC) boards from several revision.

 

The one I have now are Rev. C, but I had boards hanging with Rev. E as well

 

I tested Armbian with legacy and mainline Kernel and different flavor of U-boot (2015, 2016) with no improvement...

 

An easy tool to stress and test the system is stress : stress -c 2 -i 2 -m 1 --vm-bytes 300M -t 60m

This test was enough to make the board hang after 20-30 min.

 

I read @chradev was experiencing hang with his boards and I try to reduce CONFIG_DRAM_CLK at 374Mhz instead of 480Mhz. I then created a new image and boot my lime2 with this new image (A reboot was needed to take the new clock speed).

Result : The system is stable, stress run over an hour and half with no hang !

 

Thanks for the tip !

 

I'd like now to use Lima-memtester as @tkaiser said in order to find the right setting.

 

How badly the performance can be reduce from downgrading the clock speed to 374Mhz ? I can't find over Internet (mostly GitHub) an other setting than 480Mhz...

 

It is good to hear about your experience.

 

Some notes:

  * DRAM speed of 384MHz is properly too low

  * You have to use DRAM speed divisible by 24MHz.

  * U-Boot 2016.05 and newer and latest mainline Kernel are preferable

 

For finding the best speed tests with many boards (30 as mentioned above) has to be made with speeds between 384 and 480 MHz.

 

Do you have such number of boards with the same HW revision (latest E preferable)?

 

Best regards

Chris

[arox]

This SOC are designed for smartphone, aren't they ? In a smartphone, cooling has to be done by the (back of) enclosure without ventilation. I would guess, if the SOC is usable in a phone, that you need for passive cooling a heatsink with the (total) surface of the back of a smartphone.

[tkaiser]

This SOC are designed for smartphone, aren't they?

 

A20 was meant for tablets, OTT boxes and automotive use and is in my opinion the last Allwinner SoC that does not even need passive heat dissipation at all. If you want to overclock/overvolt it (using higher clockspeeds and non-standard dvfs operating points) or are able to use the GPU (Android use case) or cramp it in a very small enclosure without any cooling then you should take care of heat dissipation otherwise not.

 

When I started testing I soon realized that A20's companion, the AXP209 PMU, gets way more hot in certain situations (depending on power requirements of connected stuff, that means CPU utilization adds to this as well as all other consumers powered through the PMU... and the Lime boards are the few that really power everything through the PMU with step-up converters, that's why you always get 'full UPS mode' by simply connecting a battery to any Lime board since PMU + step-up converters then power a connected SATA disks and every consumer on every USB port).

 

So while adding a heatsink to the SoC is not wrong taking care of AXP209 is IMO more important on Lime/Lime2 (and that's what Christo did with his large metal cooler that should be sufficient for high loads while charging the battery which could already trigger overheat protection of AXP209 in a small enclosure )

[splite]

Hi chradev,

 

I'm going to compile 5 U-boot (v 2016.07) version with those frequency :

• 384
• 408
• 432
• 456
• 480

and stress the board for at list an hour. I have around 20 boards with me, more to come. However this is quit a crazy job to to...

 

I'm starting with one to get an idea

[tkaiser]

I have around 20 boards with me, more to come. However this is quit a crazy job to to...

 

Maybe post #4 and #11 of this thread help: http://forum.armbian.com/index.php/topic/31-problems-with-gigabit/?p=150

 

I automated this stuff when we tested through 64 different u-boot combinations a while back, you could use something like this and prepare a single Armbian installation that stress tests Lime2 for an hour then exchanges u-boot with different settings, reboots and reports results somewhere in a file.

 

BTW: Just looked through device tree stuff for Lime2 and as a comparison Banana Pro. Lime2 takes default dvfs settings from sun7i-a20.dtsi while Banana Pro uses custom ones (copy&paste from Banana Pi) that are 50mV higher at lower clockspeeds (144 - 864 MHz). And also the respective voltage look different:

 

Lime 2:

vdd_cpu: dcdc2 {
        regulator-min-microvolt = <700000>;
        regulator-max-microvolt = <2275000>;
        regulator-always-on;
};

vdd_int: dcdc3 {
        regulator-min-microvolt = <700000>;
        regulator-max-microvolt = <3500000>;
        regulator-always-on;
};

Banana Pro:

&reg_dcdc2 {
        regulator-always-on;
        regulator-min-microvolt = <1000000>;
        regulator-max-microvolt = <1400000>;
        regulator-name = "vdd-cpu";
};

&reg_dcdc3 {
        regulator-always-on;
        regulator-min-microvolt = <1000000>;
        regulator-max-microvolt = <1400000>;
        regulator-name = "vdd-int-dll";
};

[chradev]

Hi to All,

 

 

@Tkaiser

In my first tests I have observed Lime2 (put in Lime box) hangs without stress load - simply normal CPU load while battery is charged. Temperatures measured by CPU and PMU sensors did not not exceed 60°C. One of the findings was that the hangs have been provoked from CPU and DRAM overheating. On the other hand PMU was noted as hottest chip because of its small size, potential bad soldering of its thermal pad taking the heat to the board and whole power passing through it in discharge mode.

 

Later on increasing the test load and adding other peripherals like SATA SSD and USB WiFi adapter in the same box, taking into account power dissipated in charge and discharge modes and the results from tests at higher temperatures (in thermal camera), bring me to a conclusion that even in big Al box some of the heat will stay in the box overheating all chips.

 

For solving the overheating of all chips in the best and simpler way we decided to use thick Al conductor taking the heat passively and efficiently from all chips to the box wall. In addition using such a conductor help us to mount easily and reliably the board to the box which will be used on the field at heavy conditions like high temperatures at direct sun heating, humidity, dust, vibration etc. In final tests the solution shows very good results against very low price and additional advantages.

 

@Splite

It is good range of speeds for testing and 20 boards are good number as a beginning.

 

BTW you can add 504MHz for curiosity because Olimex have been posted that Lime2 rev. E will be able to work at speeds higher than 500MHz.

 

@Tkaiser

Do you think that Lime2 voltage settings have to be changed?

If yes are Banana Pro values good for a better reliability?

 

Best regards

Chris

[splite]

Hey,

 

I'm not able to reproduce the hang on the board. I think I mess something.

I'm currently compiling with KERNEL_ONLY="yes", so I got this in my output dir :

-rw-r--r-- 1 root root  1081558 août   2 12:47 armbian-firmware_5.17_armhf.deb
-rw-r--r-- 1 root root  1572820 août   2 13:00 armbian-hostapd-jessie_5.17_armhf.deb
-rw-r--r-- 1 root root    66218 août   2 13:01 armbian-tools-jessie_5.17_armhf.deb
drwxr-xr-x 2 root root     4096 août   2 12:24 extra/
drwxr-xr-x 2 root root     4096 août   8 10:45 jessie/
-rw-r--r-- 1 root root    68742 août   8 10:44 linux-dtb-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root    58596 août   8 10:44 linux-firmware-image-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root  7055090 août   8 10:44 linux-headers-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root 15140844 août   8 10:45 linux-image-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root   177898 août   8 10:40 linux-u-boot-next-lime2_5.17_armhf.deb

I'm only copying and installing linux-u-boot-next-lime2_5.17_armhf.deb on my board in order to test the DRAM frequency. After rebooting the board I'm lunching the test. I guess this should be enough to modify U-boot, unfortunately the board (DRAM 480) does not hang...

 

Should I install other *.deb ?

 

Thanks

[chradev]

Hi Splite,

Hey,

 

I'm not able to reproduce the hang on the board. I think I mess something.

I'm currently compiling with KERNEL_ONLY="yes", so I got this in my output dir :

-rw-r--r-- 1 root root  1081558 août   2 12:47 armbian-firmware_5.17_armhf.deb
-rw-r--r-- 1 root root  1572820 août   2 13:00 armbian-hostapd-jessie_5.17_armhf.deb
-rw-r--r-- 1 root root    66218 août   2 13:01 armbian-tools-jessie_5.17_armhf.deb
drwxr-xr-x 2 root root     4096 août   2 12:24 extra/
drwxr-xr-x 2 root root     4096 août   8 10:45 jessie/
-rw-r--r-- 1 root root    68742 août   8 10:44 linux-dtb-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root    58596 août   8 10:44 linux-firmware-image-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root  7055090 août   8 10:44 linux-headers-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root 15140844 août   8 10:45 linux-image-next-sunxi_5.17_armhf.deb
-rw-r--r-- 1 root root   177898 août   8 10:40 linux-u-boot-next-lime2_5.17_armhf.deb

I'm only copying and installing linux-u-boot-next-lime2_5.17_armhf.deb on my board in order to test the DRAM frequency. After rebooting the board I'm lunching the test. I guess this should be enough to modify U-boot, unfortunately the board (DRAM 480) does not hang...

 

Should I install other *.deb ?

 

Thanks

If your linux-u-boot-next-lime2_5.17_armhf.deb exists probably it will not be recompiled.

Try to delete it before recompilation.

 

Best regards

Chris

[splite]

Thanks for the tip @chradev

 

Do you know if there is anyway to check the DRAM frequency once the system is started in order to be sure of value ?

[chradev]

Hi Splite,

Thanks for the tip @chradev

 

Do you know if there is anyway to check the DRAM frequency once the system is started in order to be sure of value ?

I have already asked this questions above in this thread and the answer was probably not for mainline kernel.

I did not find a way to test DRAM speed in running system (with mainline kernel) as well.

 

Best regards

Chris

[chradev]

Hi to All,

 

After strange hangs (discussed above) with my 3-rd Lime2-eMMC board I have observed 2 more strange effects on it.

 

First one is much bigger variation of the consumption observed with RPI Monitor with some 5V/1A PSUs from Olimex in idle system state.

RPI Monitor charts of 2 Lime2-eMMC boards with PSU swapping ware shown in the attached file.

 

The other strange effect is 'false' CPU load observed on the same Lime2-eMMC board in idle state and gone after system restart.

Neither CPU frequency and/or temperature nor board consumption increase is observed as seen on the charts in the attached file.

 

What can provoke described strange effects?

Can described above effects be relevant to the board hangs at 480 MHz DRAM speed?

 

BTW I have one old problem with USB OTG on all Lime2 boards discussed before here and on the other forums.

It is working only in host mode but halting the driver periodically and requiring system restart.

In addition at bigger USB traffic (~50 MB/s in FS connection) false interrupts rises system warnings.

Unfortunately, these USB OTG problems ware not solved till now.

 

In theory the board differences (caused by PCB, components and/or assembling process) can provoke:

• bigger noise - causing DRAM access to fail at higher speeds,
• dc-dc convertors excitation - increasing board consumption and the noise,
• false interrupts - increasing CPU load, rising MUSB warnings and halting USB OTG etc.

Can observed problems and effects be explained this way?

 

 

Best regards

Chris

 

lime2-emmc-hangs+other-effects.pdf

[tkaiser]

CPU load

 

Since we're talking about Linux there is no such thing like 'CPU load'. It's called average load and it's absolutely useless to look at on any SBC since on Linux to average load add processes that are in uninterruptible sleep states (disk IO, anything that got stuck in IO, a crappy USB thumb drive connected increasing IRQs, whatever -- it's still only useful as indication that 'there happens something' but totally unrelated to CPU utilization especially when we're talking about SBC)

 

Simply do a google search for 'brendan gregg average load' to get the idea how weird it is to look at this number (only interesting for sysadmins to quickly check the output from 'uptime' to see whether load is increasing, decreasing or remaining -- for that you need 1min, 5min and 15min value -- apart from that average load on Linux especially running on SBCs is absolutely useless and it's only a waste of time to look at it)

[chradev]

Thanks Tkaiser,

Since we're talking about Linux there is no such thing like 'CPU load'. It's called average load and it's absolutely useless to look at on any SBC since on Linux to average load add processes that are in uninterruptible sleep states (disk IO, anything that got stuck in IO, a crappy USB thumb drive connected increasing IRQs, whatever -- it's still only useful as indication that 'there happens something' but totally unrelated to CPU utilization especially when we're talking about SBC)

 

Simply do a google search for 'brendan gregg average load' to get the idea how weird it is to look at this number (only interesting for sysadmins to quickly check the output from 'uptime' to see whether load is increasing, decreasing or remaining -- for that you need 1min, 5min and 15min value -- apart from that average load on Linux especially running on SBCs is absolutely useless and it's only a waste of time to look at it)

I do not cite the CPU load as a measure of its utilization but as a sign of something it is happened in one of the boards in opposite to the other.

Without matter of the fact how we will call it or its usefulness such a difference in the behavior is telling me that there is something wrong in that board.

The source of that wrong behavior can cause problems which is the goal of my investigation because there are no neglectful problems in embedded systems.

 

Any way you probably is knowledgeable about how average load seen in RPI Monitor and 'top' command is calculated.

 

Is it possible the reason causing this activity to be determined and how?

 

And mainly can this help to determine the reasons of and to solve the main problems in that board(s):

• DRAM faults at higher speeds causing system hangs,
• bigger board consumption with some PSUs and
• USB OTG problems

and how?

 

Finding the real reasons of the main problems can help us to increase reliability by solving or overcoming them. So if for example:

• the main source of the problems is board manufacturing process it is better to use another board from other manufacturer or
• the problem comes from bad SW support of given peripheral it is better to avoid its usage or to use the board with other CPU.

 

Best regards

Chris

[tkaiser]

I do not cite the CPU load as a measure of its utilization but as a sign of something it is happened in one of the boards in opposite to the other.

Without matter of the fact how we will call it or its usefulness such a difference in the behavior is telling me that there is something wrong in that board.

 

Now I got it, thanks for insisting!

 

Something came to my mind since I do consumption tests since a few days (basically using your setup: A20 board + mainline kernel + RPi-Monitor -- I misuse a Banana Pro as 'Monitoring PSU'). When I tested with RPi 3 I noticed two strange things:

• RPi 3 draws between 340 and 430 mW after a 'poweroff' or 'shutdown -h now'
• When consumption went down average load increased but as soon as I started RPi 3 again it immediately went back to normal level

 

So maybe we're dealing here with the same symptom: Something strange happening with power (in my case the RPi 3 noisily demanding power from Banana Pro?) which leads to overloading of AXP209 (and the higher load being a symptom of our monitoring attempts)?

[chradev]

Thanks Tkaiser,

Now I got it, thanks for insisting!

 

Something came to my mind since I do consumption tests since a few days (basically using your setup: A20 board + mainline kernel + RPi-Monitor -- I misuse a Banana Pro as 'Monitoring PSU'). When I tested with RPi 3 I noticed two strange things:

• RPi 3 draws between 340 and 430 mW after a 'poweroff' or 'shutdown -h now'
• When consumption went down average load increased but as soon as I started RPi 3 again it immediately went back to normal level

 

So maybe we're dealing here with the same symptom: Something strange happening with power (in my case the RPi 3 noisily demanding power from Banana Pro?) which leads to overloading of AXP209 (and the higher load being a symptom of our monitoring attempts)?

Did you try to look on power tracks (before and after dc-dc convertors) with oscilloscope for extraordinary noise.

 

In my opinion it is possible some PSUs (bad once) powering some boards (with lower noise immunity) to cause dc-dc convertors excitation.

Such excitation from the one hand will make the board to draw more power and from the other hand will increase fails (like at DRAM access).

 

Noise immunity of the board is definitely correlated with assembling process and the quality of PCB and components.

This can explain different behavior of the boards even from the same producer.

 

I will try to look for a noise in my 3rd Lime2 board (having described problems).

 

BTW while reading your post I have found some interesting ideas but a few question raised around my problems with USB OTG on Lime2 as well.

 

Did you succeed to set and use USB OTG on Lime2 (or other A20 based board) like in BPi M2+ - in device mode but on mainline kernel with g_ether module?

 

My second and main problem is that when USB OTG is set to host only mode it works but the musb driver prints warnings and hangs at even small connection load.

Did you observe such a problem on Lime2 or other A20 based board with mainline kernel?

If yes and have a solution (dts, patches etc.) could you share it because it is short-stopper in my project?

 

Best regards

Chris

[chradev]

Hi to All,

 

These days I have changed my USB WiFi adapter form Ralink to Realtek (rtl8192cu) one.

Unfortunately, while booting I get an error:

rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available

For solving the problem I have to install 'firmware-realtek' Debian package.

 

BTW In Armbian there is a target to compile and download some fiirmware packages.

Some time ago Ralink fimware was part of it but gone in some reason.

 

Which is better for Ralink and Realtek USB WiFi adapters - to install them form Debian site or to compile them locally?

If it is better to compile them locally could it be done in main Armbian staff instead from the users?

 

Best regards

Chris

[splite]

Hey all,

 

I have been running 5 Lime2 during more than 48 hours, downloading and processing data. 

I set the DRAM just below 480 which is 456. So far I had no hang, no freeze, nothing wrong.

 

This might be not the best value but at least I have a working board, which is a really good news.

 

I'll try the DRAM value 504 as soon as I have a rev E in hand.

 

Best

Florian

[chradev]

Hi Florian,

Hey all,

 

I have been running 5 Lime2 during more than 48 hours, downloading and processing data. 

I set the DRAM just below 480 which is 456. So far I had no hang, no freeze, nothing wrong.

 

This might be not the best value but at least I have a working board, which is a really good news.

 

I'll try the DRAM value 504 as soon as I have a rev E in hand.

 

Best

Florian

Thanks for the effort and shared good news but it will be really useful if the tests ware run on all boards you have as you have offer.

It is a question of statistics taken from as more as possible boards from the same HW revision (30 is good number as discussed above).

 

On the other hand if you have Lime2 HW rev. C only the same tests have to be done on any new revision - currently E but G is coming.

 

This is really hard work and a large number of boards have to be available ~30 boards from every HW revision.

It is really possible with Olimex collaboration only and as a part of their product change process.

 

Unfortunately, as I have mentioned before Lime2 is not of big interest for them so I am not sure if real collaboration is possible.

It means that good SW support of their Lime(2) boards from Armbian or any other community is not possible as well.

 

It is up to the users to make their own support or to migrate to other better supported board / manufacturer.

 

Best regards

Chris

[tkaiser]

I set the DRAM just below 480 which is 456. So far I had no hang, no freeze, nothing wrong.

 

Just for your info: http://forum.armbian.com/index.php/topic/1853-rfc-images-for-new-boards/?view=getlastpost

 

Edit: archive with u-boot .debs from 384-528 MHz available: http://kaiser-edv.de/tmp/4U4tkD/lime2-u-boot-384-480-mhz.tar.bz2

 

 

root@armbian:/var/git/Armbian# tar tf lime2-u-boot-384-480-mhz.tar.bz2 
2016.03/
2016.03/linux-u-boot-lime2_5.17_armhf_528.deb
2016.03/linux-u-boot-lime2_5.17_armhf_480.deb
2016.03/linux-u-boot-lime2_5.17_armhf_456.deb
2016.03/linux-u-boot-lime2_5.17_armhf_504.deb
2016.03/linux-u-boot-lime2_5.17_armhf_432.deb
2016.03/linux-u-boot-lime2_5.17_armhf_408.deb
2016.03/linux-u-boot-lime2_5.17_armhf_384.deb
2016.07/
2016.07/linux-u-boot-lime2_5.17_armhf_528.deb
2016.07/linux-u-boot-lime2_5.17_armhf_480.deb
2016.07/linux-u-boot-lime2_5.17_armhf_456.deb
2016.07/linux-u-boot-lime2_5.17_armhf_504.deb
2016.07/linux-u-boot-lime2_5.17_armhf_432.deb
2016.07/linux-u-boot-lime2_5.17_armhf_408.deb
2016.07/linux-u-boot-lime2_5.17_armhf_384.deb 

 

 

[chradev]

Hi to All,

 

After some pause I have to rebuild my custom Armbian and found following problem:

 

Armbian v. 5.20 build uses kernel 4.7.5 but 'uname -a' prints:

Linux egpr 4.7.3-sunxi #26 SMP Wed Sep 14 19:50:18 CEST 2016 armv7l GNU/Linux

The build date is also strange.

 

Downloaded, patched and built source is 4.7.5 while installed is 4.7.3 (not clear where it is coming from).

 

Debian files in output/debs are with kernel 4.7.5 while image files in '/var/cache/apt/archives/' are with 4.7.3.

Try to install Debian packages from output/debs says:

linux-image-next-sunxi is already the newest version.

Trying to add to userpatches/lib.config

KERNELBRANCH="v4.7.3"

for getting, patching and building right source finished with error:

[ error ] ERROR in function fetch_from_repo [ general.sh:185 ]
[ error ] Error in configuration: v4.7.3 

I have made many clean builds in different directories without success.

 

What is missing or wrong?

 

Best regards

Chris

[zador.blood.stained]

What is missing or wrong?

There was an internal change and git cloning function was replaced. Now you need to specify

KERNELBRANCH="tag:v4.7.3"

for tags (and

KERNELBRANCH="branch:master"

for branches)

[zador.blood.stained]

Armbian v. 5.20 build uses kernel 4.7.5 but 'uname -a' prints:

Linux egpr 4.7.3-sunxi #26 SMP Wed Sep 14 19:50:18 CEST 2016 armv7l GNU/Linux

5.20 was built with 4.7.3 as far as I see

 

 

Debian files in output/debs are with kernel 4.7.5 while image files in '/var/cache/apt/archives/' are with 4.7.3.

Try to install Debian packages from output/debs says:

linux-image-next-sunxi is already the newest version.

apt-get won't install kernel since package name and package version (=Armbian build version) are the same, you need to use dpkg to install from local .deb file or "apt-get install --reinstall" to reinstall kernel from repository