ssvb
-
Posts
30 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by ssvb
-
-
First, it looks like the calibrated ZQ value is the same in all tests (reported as 0x5294a00).
We can try to force dqs_gating_delay to 0x06060606 instead of autodetection and check if this improves anything. This can be done via the CONFIG_DRAM_DQS_GATING_DELAY option in U-boot defconfig, see http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/Kconfig;h=e1d4ab148f0838d746889775cfbab5bed57838bf;hb=a705ebc81b7f91bbd0ef7c634284208342901149#l196
Also it may be a very good idea to add CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y or CONFIG_DRAM_TIMINGS_DDR3_1066F_1333H=y to the defconfig too.
-
Freezes are more connected to DCDC3 voltage because if it is high enough, then the freezes usually disappear and you only have to deal with just data corruption alone.
There is one more trick. DRAM configuration is not deterministic because ZQ calibration is run at the initialization time. You can get the current results of ZQ calibration and a lot of other settings by running the a10-meminfo tool from https://github.com/ssvb/a10-dram-tools
This may explain why sometimes you have a reliable board and sometimes it fails. ZQ calibration usually differs between cold start and warm reboot. It is also possible to bypass the ZQ calibration step and hardcode ZQ settings directly via the CONFIG_DRAM_ZQ parameter. This way the DRAM controller configuration will become deterministic. Some extra information can be found at https://linux-sunxi.org/User:Ssvb/pcDuino2_with_HYNIX_DDR3_reliability_test
-
Ok, first results from me on Cubietruck3 fpr 384MHz-DCDC3-13v: To compare to earlier results I started limatester with 100MB.
Don't know if it is "More reliable" ... it runned around 1,5h andfreezed in the 5th loop, but some errors from testing occured:
Sun Feb 19 15:48:22 UTC 2017 This is a simple textured cube demo from the lima driver and a memtester. Both combined in a single program. The mali400 hardware is only used to stress RAM in the background. But this happens to significantly increase chances of exposing memory stability related problems. Kernel driver is version 14 Detected 1 Mali-400 GP Cores. Detected 2 Mali-400 PP Cores. FB: 1920x1080@32bpp at 0x44001000 (0x00FD2000) Using dual buffered direct rendering to FB. memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffff000 want 100MB (104857600 bytes) got 100MB (104857600 bytes), trying mlock ...locked. Loop 1: Stuck Address : testing 7FAILURE: possible bad address line at offset 0x05319ae0. Skipping to next test... Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : testing 6WRITE FAILURE: 0x55555555 != 0x5555d755 at offset 0x01437f20 (checkerboard). Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok
Freezes and memory corruption errors are very likely two different types of problems (and both are bad). If DCDC3 voltage is insufficient, then we get freezes. If the clock speed is too high (or too low), then we get memory corruption errors. Yes, the clock speed also affects freezes to a smaller extent.
-
You can set CONFIG_AXP_DCDC3_VOLT=1300 in the configs/Cubietruck_defconfig file before compiling U-Boot.
-
Freezing is not a very good symptom. Normally one would see data corruption getting reported by lima-memtester (and a glowing red background with the cube spinning animation). You could also try to increase DCDC3 voltage (from 1.25V to 1.30V) and check if this helps to improve reliability.
-
Since we are testing the DRAM settings in U-Boot, the choice of kernel does not really matter. For the sake of convenience, the Orange Pi PC testing had been done via a special FEL boot package: https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test
I can easily prepare something like this for the Cubietruck too.
-
@tpm8 - Yes, reducing the DRAM clock speed too much can also cause problems if the DRAM chips in question had been designed for very high clock speeds (DDR3-1600). Moreover, the default ZQ settings are very non-optimal for the Cubietruck board and it is possible to clock even to 600 MHz with DRAM chips from GT and tuned ZQ settings, while the defaults have relatively bad reliability - http://lists.denx.de/pipermail/u-boot/2014-July/183981.html
@apollon77 - If I understand it correctly, you have never used the lima-memtester stress test, which is specifically designed to quickly identify DRAM problems/misconfigurations. You might want to give it a try, especially considering that you have a nice set of 4 boards.
-
OK, lower DRAM clock frequency can explain why stability problems disappeared. Why was it lowered in armbian in the first place? Was it there to address reliability problems? If yes, then why hasn't it been reported to mainline yet?
In order to figure out what is going on, I think that we need to have some test results similar to https://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit
Done separately for different brands of DRAM chips (GT vs. HYNIX).
Edit: Various reports in this discussion thread are very confusing and contradict each other. For example, tpm8 mentioned that the mainline U-Boot was stable with the 432MHz DRAM clock speed, while armbian was not. Please get your act together.
-
Fortunately for the current boards with SPi flash (Zero and PC2) SD slot has higher boot priority than SPI flash, so it's impossible to brick the device by writing an incompatible u-boot to the SPI flash (if you have physical access to the board).
Yes, these boards are designed to be unbrickable. They can either boot from the SD card (there is a special sd card bootable image in sunxi-tools, which activates FEL mode), or have a dedicated FEL button.
And main problem with Zero is its OTG port which serves as the main power input at the same time, so to reliably power the board for the FEL boot from a standard PC port you have to use microUSB Y-cable or power it through GPIO pins.
The CPU is running at a really low clock speed in FEL mode (something like 384MHz?) and never uses more than one core. The current draw is much lower than 500mA. Idle FEL mode only shows ~80mA on my board. Unfortunately SPI NOR flash is not populated on my OpiZero board, but you can try to measure the current draw while flashing via sunxi-fel and report the results here.
We are experimenting for now, and flashrom is convenient enough on the legacy kernel images since it works out of the box, doesn't require another PC, board or VM running Linux or compliing sunxi-tools for Windows (which may be a problem for an average user of this forum)Yeah, but you first need to boot the board from the SD card to use flashrom, so pick your poison
As for the Windows version of sunxi-tools, you can try http://linux-sunxi.org/FEL/USBBoot#Using_sunxi-fel_on_Windows and provide some feedback. -
H5 is still not supported in U-Boot, that's why it is WIP. The required changes are trivial though.
The sunxi-fel tool (from my branch) has full H5 support. It is not merged to the upstream sunxi-tools because some code cleanups are necessary (in fact they are already done). And also it would be best to have a high level firmware upgrade functionality implemented rather than just raw read/write support.
If this is inconvenient for you, then just let me know. In fact, I have added the basic flashrom information to the wiki page in order to discourage everyone from using it. How did it end up having the opposite effect?
-
I heard that capability for writing to SPI flash might be added to sunxi-fel so it will be even easier. I forgot what is the current state regarding this.
Of course it works. And was working fine since the very beginning. You can find the detailed step by step instructions here: https://linux-sunxi.org/Bootable_SPI_flash#Using_the_sunxi-fel_tool
Please note that the flashrom method is not very foolproof. The sunxi-fel tool may provide some nice high level features in the future. Such as the installed bootloader identification, extra checks if the old and new u-boot configurations are compatible, SPI speed tuning for faster boot (right now it is working at 6MHz in U-Boot) and maybe even larger SPL sizes via an additional loader stub. Not to mention that U-Boot may enforce write-protection for itself before passing control to the linux kernel (write-protection is enforced until the next power-down/power-up cycle), and in this case the flashrom tool will become completely useless.
-
Keep in mind that different units may have slightly different tolerances and overclocking potential even if it's the same board model. For example, have a look at https://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit
Some Orange Pi PC boards pass the lima-memtester test with DRAM clocked at 720 MHz, while the others fail it at 672 MHz. The same is very likely true for the Cubietruck.
Also ""Works stable" means a minimum complete run of lima-memtester and cpufreq-ljt-stress-test (cpuburn-arm)" is not good enough. Ideally we want at least a bit of extra safety headroom. Which means that you should stress test the board at slightly higher settings than intended to be used in production.
Still if you have some differences depending on the U-Boot version, then we need to investigate this too. Ideally we need to identify the exact problematic commit (via git bisecting).
-
How it can be HW related when it works rock solid with one version of u-boot and instable with an other ?!
Just try to find the exact commit which introduced the problem, and we will know more.
-
Could you please give me some advise
- how to identify DRAM chips (dmesg? armbianmonitor?)
You can't get this information in a software way. Just check the markings on the four DRAM chips on the board. For example, the original https://linux-sunxi.org/Cubietruck used GT8UB512M8EN-BG chips and you can find them on the pictures.
Could you please give me some advise
- how to modify DRAM clock speeds? (do I have to compile an individual kernel for that? boot.cmd parameter?
It is necessary to recompile U-Boot for this after changing the DRAM clock speed settings in the 'configs/Cubietruck_defconfig' file. You can find some instructions here: https://linux-sunxi.org/Mainline_U-Boot#Compile_U-Boot
-
I don't think it's power or hardware related, because same configuration works fine with 5.20 u-boot. lima-memtester runs without problems for hours...
Maybe I used the wrong words. Calling lima-memtester does not crash itself but immediately freezes / crashes the kernel. The cube is shown on the screen.
Anyway I've ordered another cubietruck to completely rule out individual hardware problems.
It would be best if you could compile U-Boot yourself and bisect this problem. You can check http://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination or any other tutorial about using git bisect.
Just using an older U-Boot release is only a workaround. This is unhealthy in the long run.
-
I'm using this repository: https://github.com/linux-sunxi/u-boot-sunxi
Its the only one I managed to work on my cubie.
It is very old and all the development has moved to the mainline U-Boot since at least 2 years ago. The mainline U-Boot should work fine and I believe that this is what is used by Armbian already.
Is it dangerous to run MBUS 400 MHz @ 1300 mV? Can this cause any damage on the board?MBUS should work at 400MHz too, I believe that this information is from Allwinner - https://irclog.whitequark.org/linux-sunxi/2013-11-06#5472690;
Moreover, the A20 datasheet specifies some voltage limits and for VDD-DLL it is 1.4V
Also, it looks like I dont understand what is mainline. Could you please explain to me? I read mainline many times here, but I dont know if they are all the same thing.Mainline is the only true U-Boot from http://git.denx.de/?p=u-boot.git;a=summary
All the other U-Boot variants are forked versions with local patches.
I will test this on the weekend. This week I have some tests at university and I will be very busy.
I will only need to test 456, since 432 and 480 have already been tested.
Did you have time to test anything?
-
Of course, this is more or less what I wrote above but that would require the use of a separate FAT partition which is something we currently do not implement on most OS images since there was no necessity for it (unlike RPis where it's mandatory since VideoCore 4 can not deal with anything else than FAT).
I just put together an USB flashing tool for H3 devices connected to OS X hosts (based on Zador's fel-mass-storage preparations) just to realize that NanoPi AIR has also no FEL button
So in case FriendlyARM ships these devices with a pre-populated eMMC there's no easy way without flashing a separate SD card.
Well, it was Allwinner who introduced their reference design, which relies on having a FEL button and doing firmware upgrade/recovery over the Micro-USB cable using their LiveSuit software. Many tablets and other devices are compatible with this reference design. And it looks like you and Zador are implementing your own open source alternative to LiveSuit.
And of course, a few ugly ducklings or very specialized devices exist. They may need some special treatment.
-
The 'problem' with this from an Armbian point of view is that we don't want to rely on a setup where the user needs keyboard + display to do the initial setup. It should work in a way where the device boots up on its own and is then accessible through SSH afterwards. So auto detection would be ok but no user interaction to let the user choose his device (BTW: it happened not just once that users try the wrong OS images for their boards and discover after lengthy threads that they do not own an Orange Pi PC but an OPi 2 instead).
The user interaction part is optional. We can easily tweak the code not to require any confirmation when there is only a single suitable choice available. For example, if the installer is only targeting Cubieboard1 / Cubieboard2 / Cubietruck, then there is just a single choice for the user (approve the installation or don't do it).
As for the users doing a wrong choice, this is a universal problem and no better solution exists anyway. If you have multiple SD card images on the download page instead of a unified one, then the user still can download a wrong image and use it. The unified installer is in fact reducing the chance of a user error, because it does not allow the user to select Cubieboard2 when his/her SoC is detected as Allwinner A10 at runtime
Moreover, the unified installer tries to provide instructions to the user at each step and explains how to make a correct choice.But this all is an ancient history
Fast forward to the present days. Now I think that a proper solution is to have the exact board identification information available in the SPI flash or eMMC. There was some discussion about this in the Olimex blog: https://olimex.wordpress.com/2016/09/01/a64-olinuxino-emmc-rev-b-oshw-64-bit-arm-development-board-prototypes-are-testing/And I suggested a patch for U-Boot to make the device model identification easy: https://patchwork.ozlabs.org/patch/629172/
The 'problem' with this from an Armbian point of view is that we don't want to rely on a setup where the user needs keyboard + display to do the initial setup. It should work in a way where the device boots up on its own and is then accessible through SSH afterwards. So auto detection would be ok but no user interaction to let the user choose his device (BTW: it happened not just once that users try the wrong OS images for their boards and discover after lengthy threads that they do not own an Orange Pi PC but an OPi 2 instead).
It depends on the intended use of the device. If the user wants to run a desktop Linux system on the device, then we can expect a USB keyboard and a HDMI monitor to be normally available. You seem to be talking about the headless use case here. And it may (or even should?) have a different installer, or just the plain and boring board-specific SD card images.
And the horror continues: if we want to support NanoPi AIR we have to tweak the OS image for this device in a way that it's accessible through USB serial gadget like we do it already with Orange Pi Lite (no UART pins soldered, no HDMI, no USB ports other than OTG which is used to power the device, no Ethernet).For the AIR I also thought about enhancing our toolchain, providing utilities for Windows, Linux and OS X relying on https://github.com/zador-blood-stained/fel-mass-storage and then simply allowing the user to pre-fill WiFi authentication data. But that would require Armbian images that use a small FAT partition since mounting ext4 is IMO too unreliable on Windows and OS X.
This seems to be a very specialized device. The users of such device are expected to know what they are doing.
-
Hi all,
I'am looking at creating a single unified H3 DietPi image (currently using ARMbian build tools), rather than one for each board. Would allow us to support all H3 devices, reduce work load and simplify DietPi source code.
Basically I need to know if its possible, and which unique files/configurations would need changing to achieve it.
It's not quite related to ARMbian build tools, but it is technically possible to have a generic bootable image / installer for all Allwinner devices. I had implemented a prototype a long time ago:http://linux-sunxi.org/SD_card_based_installer
The sunxi-bootsetup demo only supports a set of A10/A10s/A20 boards, but in principle all the Allwinner chip generations can be covered (including H3). For example, you can try a simple helloworld binary, which can be written to the SD card instead of a bootloader (the source code is also available in github):
wget https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/uart0-helloworld-sdboot.sunxi dd if=uart0-helloworld-sdboot.sunxi of=/dev/sdX bs=1024 seek=8
Unfortunately none of the Linux distribution maintainers was interested in this feature back in 2014, probably it was way too unorthodox for them to accept. And of course, later the Raspberry Pi people have introduced an universal SD card image of their own, which can boot on all Raspberry Pi generations. Just because they probably do care about their users a little bit more
-
ondemand is wrong for Allwinner BSP kernels:One could say, Allwinner H3 is wrong
. On your experience, is interactive "right" for Allwinner?You can find some information about cpufreq governors here: https://linux-sunxi.org/Cpufreq
Basically, the "ondemand" governor is way too slow to increase CPU clock speed. If you want to run a graphics desktop, then it feels rather laggy and unresponsive. Obviously, it was not fit for Android, and that's why Android people have implemented the "interactive" governor, which is admittedly also far from perfect, but at least it is nowhere as bad as "ondemand". The shortcomings of the "ondemand" governor have been known since a long time ago, but only now the "schedutil" governor is trying to implement it in a proper way.
-
But yes, the DCDC3 voltage seems to be correctly set to 1.30V, so the high MBUS clock speed should be OK.
The culprit is probably the SK Hynix DRAM chips. I think that Cubieboard2 was initially developed and tested with the DRAM chips from GT. But the change to a different DRAM chips vendor now may require some different and more conservative settings. Please try to run lima-memtester with 432, 456 and 480 clock speeds for DRAM and find the last clock speed where the test passes and the first clock speed where it starts failing.
-
I used the mainline U-Boot to make my U-Boot. The only thing I changed was DRAM speed to 432 MHz.
I wonder why MBUS is working at 400 MHz.
Are you sure about this? Which U-Boot repository are you using?
If I build the mainline U-Boot for Cubieboard2 via
git clone git://git.denx.de/u-boot.git cd u-boot make CROSS_COMPILE=arm-linux-gnueabihf- Cubieboard2_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- -j8
Then the ".config" file contains CONFIG_DRAM_MBUS_CLK=300. And everyone else seems to have 300MHz MBUS clock speed, based on the logs posted here.
-
Is there something similar when using mainline kernel?
The mainline kernel with simplefb just uses the framebuffer passed over from the bootloader, but can't change its configuration. For the kernel is is just a memory buffer where one can write pixel data. The framebuffer setup is done in the U-boot bootloader. I believe that the framebuffer is initialized by U-Boot only when something is detected to be connected to HDMI and queried via EDID, but may be wrong.
-
It's a SK Hynix chip H5TQ4G63AFR-PBC
Above it is a i2c rtc module I use to sync the time.
And here is the output of a10-meminfo (improved version):
./a10-meminfo dram_clk = 432 mbus_clk = 400 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_delay = 0x05050505 active_windowing = 0
I see that the MBUS clock speed is set to 400MHz instead of 300MHz. This should work fine, as long as the DCDC3 voltage is set to 1.30V instead of 1.25V
You can check the DCDC3 voltage information in the dmesg log. And there was a patch for the 3.4 kernel to ensure that the kernel does not try to change the DCDC3 voltage, previously configured by the bootloader - https://github.com/linux-sunxi/linux-sunxi/commit/5052b83aa44dc16d6662d8d9d936166c139ad8c5
Please note that the mainline U-Boot currently uses 300MHz MBUS clock speed for Cubieboard2 / Cubietruck. There were so many broken 3.4 kernel forks that it was better be safe than sorry
Regarding the DRAM performance with different DRAM / MBUS clock speeds, some information can be found here: https://linux-sunxi.org/A10_DRAM_Controller_Performance
Cubietruck freeze after 1-3 days with 5.23 Xenial (uboot problem?)
in Allwinner sunxi
Posted
For the ZQ settings to have a meaningful effect, ODT needs to be enabled. This can be enabled by adding CONFIG_DRAM_ODT_EN=y to the U-Boot defconfig.
Also at least for the boards with GT DRAM chips, these settings can result in a much improved reliability and higher DRAM clock speed ceiling: https://linux-sunxi.org/User:Ssvb/Cubietruck_DRAM_Calibration
Basically, you could try the following:
I'm not sure if these settings are also good for SKHynix but somebody could give them a try too. CONFIG_DRAM_DQS_GATING_DELAY option may be also added if necessary.