Hi, As a conclusion.
All sunxi-3.4 branches contains r3p0 mali drivers. On boards with A20 chip your memtester crashes the system. This issue related to access to Pixel cores. Driver on your 20140116-mali-r3p2-01rel2 branh also crashes the system. When I build mali driver from malidevelopers site your memtester worked properly but the mali driver without changes rest kernel code doesn't work. It say that the issue not related to ddram settings. So. The issue related to HW version of mali core (r1p1) and mali driver implementation into sunxi-3.4.kernel. At this moment there are no correct drivers which can organise whole graphical stack on A20 chips (with 2GB memory). Unfortunately I cannot find information about preferred driver versions for Mali 400 MP2 hw version r1p1. It is not my business. Best Regards and Nice Hacking. Andrey K. четверг, 26 марта 2015 г., 23:21:55 UTC+3 пользователь Siarhei Siamashka написал: > > On Thu, 26 Mar 2015 07:26:11 -0700 (PDT) > Andrew Kosteltsev <[email protected] <javascript:>> wrote: > > > четверг, 26 марта 2015 г., 11:01:55 UTC+3 пользователь Siarhei Siamashka > > написал: > > > > > > > > > This repository is now obsolete. It is better to use the mainline > > > U-Boot. Some instructions are available here: > > > > > > http://linux-sunxi.org/Mainline_U-boot > > > > > > > > Denx's u-boot doesn't have apx209 driver and the dcdc3 set to 1200 mV > > instead of 1300 mV > > Except that the mainline u-boot does support axp209. > > How did you verify the 1200 mV dcdc3 voltage? Was it reported in > the dmesg log after booting the system? > > > ( or Denx's u-boot doesn't read dcdc3_vol value from script.bin) > > None of the u-boot variants can read values from the script.bin > > > But I think the best way to use Denx's u-boot with patches > > Which patches? > > > because on > > github we have a very bad configuration management. Using the fixed > > releases from Denx with set of patches allow us to find problems very > > quick. (bay the way we have to remember machine ID 'setenv machid > > 0x000010bb' ) > > Who has advised you to use "setenv machid 0x000010bb"? Please don't do > this. Just try to literally follow the instructions without any > improvisations: > > http://linux-sunxi.org/Mainline_U-boot > > > > > https://raw.githubusercontent.com/linux-sunxi/sunxi-boards/master/sys_config/a20/cubietruck.fex > > > > > > > > > > > This script is wrong. We have to add into this script at least following > > lines for wifi ap6xxx_wl_host_wake pin: > > > > [gpio_para] > > gpio_used = 1 > > gpio_num = 2 > > gpio_pin_1 = port:PH20<1><default><default><1> > > gpio_pin_2 = port:PH10<0><default><default><0> > > Nevertheless, the sunxi-boards repository contains the most up to date > fex files. If you think that something needs to be fixed there, please > submit a patch. > > Nobody has reported this problem yet, but this is probably because > nobody is really using wifi on this board. Now this is a good chance > for you to contribute something to the linux-sunxi community :-) > > > And the main issue is a sdram density. The Cubietruck has 4 chips > > H5TQ4G83AMR (512Mx8) and we have to set > > > > dram_chip_density = 4096 > > dram_io_width = 8 > > dram_bus_width = 32 > > > > instead of: > > > > dram_chip_density = 8192 > > dram_io_width = 16 > > dram_bus_width = 32 > > First of all, the DRAM settings in the fex file are not used for > u-boot. > > Second, these two configurations are pretty much equivalent and > can't be a problem. The point is that two x8 chips are seen by > the DRAM controller exactly the same as a single x16 chip with > twice higher density (except for the refresh timings). Think of > two x8 chips sandwiched together and put into a single case. > > > > When troubleshooting, please try the default 'sun7i_defconfig' first. > > > And if you want to store your own config somewhere, please run > > > > > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- savedefconfig > > > > > > > > I tried sun7i_defconfig without results. > > > > Mali clock is set to 312 MHz (but 288 doesn't fix this problem) > > > > > > > > > * Maybe try a different power supply or power cable just in case, > > > these might be sometimes responsible for reliability problems too > > > > > > > > > > > I have the 5V 2000mA Adaptor created for P-SP > > Maybe try to power the board with something else if you can? Are you > sharing the same power adapter for both your Cubietruck and another > Allwinner A10 board? If these are two different adapters, then try > to swap them. > > > What do you think about __phys_to_bus() macros in the > > > > > https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/arch/arm/plat-sunxi/include/plat/memory.h > > > file? > > Nothing. As I already mentioned before, this was a problem a long time > ago, but it has been already fixed by now. > > > May be I have to rebuild kernel without cedarX support? > > You can try, but I don't expect it to help. In fact, deviating from the > sun7i_defconfig is an unnecessary risk factor. > > > Do you have an image with lima-memtester which works on Cubietruck with > 2GB > > sdram? > > You can probably try to search for various cubian, cubiuntu and > other SD card images for the Cubietruck. Preferably the ones, which > advertise having working mali drivers :-) > > Just to have the device reliability problem solved once and for all for > all the users, I'm slowly making progress with the following thing: > > http://lists.denx.de/pipermail/u-boot/2015-January/202306.html > > The reception was not exactly great though. But you are welcome to > participate in testing and providing feedback. > > I can also try to quickly hack some downloadable SD card image > specifically for running lima-memtester on the Cubietruck. > > -- > Best regards, > Siarhei Siamashka > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
