Re: [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)
Hi, On 22-01-15 08:30, Siarhei Siamashka wrote: On Tue, 20 Jan 2015 14:16:35 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 20-01-15 09:16, Siarhei Siamashka wrote: On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 04-01-15 20:19, Michal Suchanek wrote: Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for smooth HDMI scanout of large frambuffer (eg. 1080p). This fix comes at the cost of some overall memory bandwidth so it might be appropriate to detect a10s and only apply there (and not a13). Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what do you think of the proposed change ? I don't have A10s hardware, so have no idea and can't test anything myself. It would be great to have a better description of what exactly is happening before the patch. And precisely how the patch is helping. A description of the test setup and benchmark numbers would be appreciated. And it would be perfect if somebody else could reproduce the test and confirm the results. I may try to check A20 with the bus width artificially reduced to 16 bits (not a totally unrealistic configuration, since A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar enough, then the magic reserved bit may have some effect there too. But that's a different hardware either way. Done these tests with A20. Ironically, now the tables have turned and A10 seems to be doing a better job than A20 at low DRAM clock speeds (~408MHz) and 16-bit bus width when dealing with full-hd monitors. Just like Michal observed on A10s, setting 0x5031 as DEFE host port config makes things much worse on A20. Overall, the test results look in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes, none of the real boards uses such a slow DRAM setup) while running lima-memtester and driving 1920x1080-32@60Hz monitor: 0x1035 - The screen regularly blanks, but comes back again instantly. 0x1037 - The screen regularly blanks, but comes back again instantly. 0x5031 - Severe screen shaking. Unlike A10, there does not seem to be any difference between using DEBE or DEFE for framebuffer scanout on A20, so using DEBE has the same effect as listed above. Setting the magic 'reserved' hpcr bit 1 (0x1037 value) does not seem to have any effect on sun7i. It is great that it is apparently helping on sun5i/A10s though. Thanks for running these tests, this makes me more confident that I only need to enable DEFE in u-boot on A10, and can directly use DEBE on the others. But what about A10s? Do we want to do something about it? Once we have some feedback from hramrach from running tests with / without the frontend enabled, then yes, unless the fix is to simple disable the frontend, and then u-boot probably is fine as is. Regarding the 0x5031 settings. It just looks like sun7i (and sun5i?) might have an upper cap for the 'CmdNum' bits (bits 15-8) and bumping it to 0x50 or even 0xFF is not effective. If we instead reduce 'CmdNum' for the CPU and GPU host ports to 1, then the screen glitches disappear too. What glitches exactly, you mean the scanout fifo engine underruns we've been seeing on sun4i, or ? I thought that only hramrach was seeing glitches on his A10s, and that you could not reproduce them on A20 ? Also won't reducing the number of outstanding commands the CPU / GPU can have significantly impact overall performance ? Eventually I would like to also identify the source of occasional monitor blinks on sun7i with full-hd monitors and slow DRAM settings in order to apply some sort of a workaround. Yes fixing that would be great. Maybe it has something to do with DRAM refresh settings, maybe it is something else. But for now it can be left alone because the problem is not easily reproducible on 'normal' workloads (it needs a special setup in which CPU GPU are torturing slow DRAM simultaneously, trying to disrupt the 1920x1080-32@60Hz framebuffer scanout). I agree that fixing this does not have a high priority. Regards, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Announcing easy Linux installation on Allwinner devices for non-geek users
Hi, Nice work overall, it's good to see something like that happening. I'm a bit bothered by the use of the universal word, for something that is so restricted, but it's just words. On Thu, Jan 22, 2015 at 02:49:03PM +0200, Siarhei Siamashka wrote: = == 5. Support more devices! = The number of supported Allwinner devices in u-boot v2015.01 is really small. A few more devices are being added for v2015.04 While the progress is steady, I'm not convinced that the support for all the 100+ Allwinner devices can be added in a reasonable time frame. The owners of some these devices are non-geeks and will not be able to submit patches to u-boot and the linux kernel on their own, even if provided with detailed instructions. This process just does not scale. Moreover, it is not very nice to force the users to master a useless skill, such as FEX knowledge. So I see the automatic conversion as the only reasonable solution. Yes, something like this already supposedly exits: https://github.com/mripard/sunxi-babelfish The point of babelfish has never been to be able to add support to u-boot. The point was to be able to boot a mainline kernel on a legacy bootloader, without having to change anything at the bootloader level (be it the bootloader itself, or the environment), while not having to really care about the state of the support of the device itself in Linux. I don't know how much progress has the 'sunxi-babelfish' project made so far (and to be honest, even did not try it). Not very far I must admit. AFAIK, no one ever ran it beside me, and I'm not the target user. Patches are very welcome though. But in my opinion it has some fatal deficiencies in the design, based on just reading its README: 1. Implemented in the C language, while scripting languages are orders of magnitude more suitable for such task and allow much faster development. Let me know how you can fake a zImage and run bare metal code in ruby, I'm interested. 2. This approach does not look very testable/debuggable. It's true that some debug output might be needed. Patches welcome, again. 3. It apparently does not help mainlining. The output of the conversion does not look like it is intended to be used as a template for the DTS file submission to the mainline kernel. It really is. DTC can output a DTS from a running kernel, by looking at /proc/device-tree. That DTS can totaly be used as a base to submit it. So the right solution in my opinion is a set of scripts for the sunxi-boards repository. The scripts need to parse the FEX files, which are conveniently already collected in sunxi-boards. They need to support different FEX dialects as input (this is really important!) and 3 types of output: 1. The defconfigs for u-boot 2. The DTS files for the linux kernel 3. The FEX file in a dialect, which is compatible with the sunxi-3.4 kernel Just so you know, I will *not* merge any patch automatically generated that will not have been run on its real board. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Announcing easy Linux installation on Allwinner devices for non-geek users
Hello, This is a somewhat long e-mail. 1. The problem 2. A possible solution 3. Relocatable SD card 4. NAND 5. Support more devices! 6. Reliability tests 7. FEL mode installer application 8. A31+ support 9. Summary = == 1. The problem = First of all, let's see what is the difference between various Allwinner boards/devices and the Raspberry Pi (which is considered by many as a role model of being user friendly and easy to use). Raspberry Pi offers only a few hardware variants with minor differences. And Raspberry Pi users are familiar with the concept of downloading SD card images with Raspbian distro and writing them to the SD card (there are tools to easily do this even in Windows). This works as a way to quickly get the system up and running on their devices. And this is the skill that they already have and expect to be applicable to other devices. On the other hand, http://linux-sunxi.org/Category:Devices lists 124 pages dedicated to different Allwinner based devices at the moment. Most of the Allwinner based devices have a HDMI connector and are able to run a desktop GNU/Linux system with a big desktop monitor just like the Raspberry Pi. Many Allwinner devices have USB host ports. And the ones which don't, are at least equipped with USB OTG. While definitely not prefect, USB OTG is still suitable for a desktop system when used with something like http://linux-sunxi.org/USB_OTG_Charging_Hub And here we have a problem. The linux-sunxi wiki contains a lot of useful information about the hardware and reasonably detailed instructions about compiling the u-boot and the kernel for each of the devices. But that's not what the non-geek users want. The non-geek users expect to find SD card images for their devices, just like this is handled for the Raspberry Pi. What happens if non-geek users do not find the right SD card images for their devices? Do they follow the instructions to compile the u-boot and the kernel themselves? Of course not. The users just pick some random SD card image, which seems to be likely compatible. That's why they are trying Cubieboard SD card images on random tablets or other devboards. This rarely ends up well. Want an example? Here it is: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg08343.html Also have a look at http://olimex.wordpress.com/2014/10/27/a20-olinuxino-lime2-review-and-updates/ for a nice warning message EDIT: Something important! Debian and Android images for LIME and LIME2 are different because of the memory and Gigabit ethernet, so if you have LIME download the images for LIME if you have LIME2 download the images for LIME2!!!. And check the discussion in comments about Cubian, Bananian and other board specific distributions. Surprisingly, compiling u-boot just happens to be rather difficult for non-geeks. Geeks are of course perfectly fine with the nice and detailed instructions, which are readily available: http://lists.denx.de/pipermail/u-boot/2014-December/199351.html = == 2. A possible solution = While working on DRAM controller bugfixes for Allwinner A10/A13/A20, it was discovered that, among other things, DRAM bus width and density autodetection can be implemented: http://lists.denx.de/pipermail/u-boot/2014-July/183981.html This alone provides an obvious opportunity to use the same u-boot binary on multiple devices even if they use different DRAM size/configuration. And the natural evolution of this is the support of Allwinner A10/A13/A20 SoC in the same u-boot binary by just doing runtime SoC type detection: http://lists.denx.de/pipermail/u-boot/2014-August/185218.html This was a cool demo, but having only the u-boot prompt on the serial console and the ability to boot from the SD card is not something that can immediately help non-geek users. Now there is an important thing to consider. The same u-boot binary can boot on different Allwinner devices and initialize DRAM successfully. But what about the other peripherals? Some of the peripherals strictly need configuration parameters, which can't be automatically detected at runtime in any way (LCD displays for example). So what is the safe subset of hardware, which is universally usable in generic u-boot binaries? Basically, we can rely on the assumption that everything that is used by BROM, can be safely autodetected and used by the universal u-boot binaries too. For example, the UART serial console is not really used by BROM, and this was a kind of hack in the previous demo. At that time it looked like the serial console could be configured correctly according to some heuristic rules. However later it turned out that the heuristics does not really work on some A13 devices and they may
[linux-sunxi] Re: Announcing easy Linux installation on Allwinner devices for non-geek users
On Thu, Jan 22, 2015 at 02:49:03PM +0200, Siarhei Siamashka wrote: Hello, This is a somewhat long e-mail. 1. The problem 2. A possible solution 3. Relocatable SD card 4. NAND 5. Support more devices! 6. Reliability tests 7. FEL mode installer application 8. A31+ support 9. Summary = == 1. The problem = First of all, let's see what is the difference between various Allwinner boards/devices and the Raspberry Pi (which is considered by many as a role model of being user friendly and easy to use). Raspberry Pi offers only a few hardware variants with minor differences. And Raspberry Pi users are familiar with the concept of downloading SD card images with Raspbian distro and writing them to the SD card (there are tools to easily do this even in Windows). This works as a way to quickly get the system up and running on their devices. And this is the skill that they already have and expect to be applicable to other devices. On the other hand, http://linux-sunxi.org/Category:Devices lists 124 pages dedicated to different Allwinner based devices at the moment. Most of the Allwinner based devices have a HDMI connector and are able to run a desktop GNU/Linux system with a big desktop monitor just like the Raspberry Pi. Many Allwinner devices have USB host ports. And the ones which don't, are at least equipped with USB OTG. While definitely not prefect, USB OTG is still suitable for a desktop system when used with something like http://linux-sunxi.org/USB_OTG_Charging_Hub And here we have a problem. The linux-sunxi wiki contains a lot of useful information about the hardware and reasonably detailed instructions about compiling the u-boot and the kernel for each of the devices. But that's not what the non-geek users want. The non-geek users expect to find SD card images for their devices, just like this is handled for the Raspberry Pi. What happens if non-geek users do not find the right SD card images for their devices? Do they follow the instructions to compile the u-boot and the kernel themselves? Of course not. The users just pick some random SD card image, which seems to be likely compatible. That's why they are trying Cubieboard SD card images on random tablets or other devboards. This rarely ends up well. Want an example? Here it is: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg08343.html Also have a look at http://olimex.wordpress.com/2014/10/27/a20-olinuxino-lime2-review-and-updates/ for a nice warning message EDIT: Something important! Debian and Android images for LIME and LIME2 are different because of the memory and Gigabit ethernet, so if you have LIME download the images for LIME if you have LIME2 download the images for LIME2!!!. And check the discussion in comments about Cubian, Bananian and other board specific distributions. Surprisingly, compiling u-boot just happens to be rather difficult for non-geeks. Geeks are of course perfectly fine with the nice and detailed instructions, which are readily available: http://lists.denx.de/pipermail/u-boot/2014-December/199351.html = == 2. A possible solution = While working on DRAM controller bugfixes for Allwinner A10/A13/A20, it was discovered that, among other things, DRAM bus width and density autodetection can be implemented: http://lists.denx.de/pipermail/u-boot/2014-July/183981.html This alone provides an obvious opportunity to use the same u-boot binary on multiple devices even if they use different DRAM size/configuration. And the natural evolution of this is the support of Allwinner A10/A13/A20 SoC in the same u-boot binary by just doing runtime SoC type detection: http://lists.denx.de/pipermail/u-boot/2014-August/185218.html This was a cool demo, but having only the u-boot prompt on the serial console and the ability to boot from the SD card is not something that can immediately help non-geek users. Now there is an important thing to consider. The same u-boot binary can boot on different Allwinner devices and initialize DRAM successfully. But what about the other peripherals? Some of the peripherals strictly need configuration parameters, which can't be automatically detected at runtime in any way (LCD displays for example). So what is the safe subset of hardware, which is universally usable in generic u-boot binaries? Basically, we can rely on the assumption that everything that is used by BROM, can be safely autodetected and used by the universal u-boot binaries too. For example, the UART serial console is not really used by BROM, and this was a kind of hack in the previous demo. At that time it looked like the serial
Re: [linux-sunxi] LVDS LCD no clock
thank you George, After some testing, 2 channel LVDS panel worked well if i disable lvds output in uboot, hope this help others. On 01/21/2015 10:13 PM, George Ioakimedes wrote: I don't have that system on the workbench right now but it was off of the 3.4 branch and pulled within the last few months. For reference here is the display portion of my FEX: [disp_init] disp_init_enable = 1 disp_mode = 4 screen0_output_type = 1 screen0_output_mode = 4 screen1_output_type = 3 screen1_output_mode = 4 fb0_framebuffer_num = 4 fb0_format = 10 fb0_pixel_sequence = 0 fb0_scaler_mode_enable = 1 fb1_framebuffer_num = 2 fb1_format = 10 fb1_pixel_sequence = 0 fb1_scaler_mode_enable = 1 lcd0_bright = 197 lcd1_bright = 197 lcd0_screen_bright = 50 lcd0_screen_contrast = 50 lcd0_screen_saturation = 57 lcd0_screen_hue = 50 lcd1_screen_bright = 50 lcd1_screen_contrast = 50 lcd1_screen_saturation = 57 lcd1_screen_hue = 50 [lcd0_para] lcd_used = 1 lcd_x = 1920 lcd_y = 1080 lcd_dclk_freq = 69 lcd_pwm_not_used = 0 lcd_pwm_ch = 0 lcd_pwm_freq = 1 lcd_pwm_pol = 0 lcd_if = 3 lcd_hbp = 160 lcd_ht = 2084 lcd_vbp = 31 lcd_vt = 2226 lcd_hv_if = 0 lcd_hv_smode = 0 lcd_hv_s888_if = 0 lcd_hv_syuv_if = 0 lcd_hv_vspw = 0 lcd_hv_hspw = 0 lcd_lvds_ch = 1 lcd_lvds_mode = 0 lcd_lvds_bitwidth = 1 lcd_lvds_io_cross = 0 lcd_cpu_if = 0 lcd_frm = 1 lcd_io_cfg0 = 268435456 lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff lcd_bl_en_used = 1 lcd_bl_en = port:PH0710default1 lcd_power_used = 1 lcd_power = port:PH0810default1 lcd_pwm_used = 1 lcd_pwm = port:PB0220defaultdefault On Tue, Jan 20, 2015 at 9:57 PM, Kaspter Ju nigh0st3...@gmail.com mailto:nigh0st3...@gmail.com wrote: Hi George, thanks for your input, what kernel code did you use? https://github.com/linux-__sunxi/linux-sunxi.git https://github.com/linux-sunxi/linux-sunxi.git branch sunxi-3.4? thanks again, Best Regards. On 01/20/2015 10:32 PM, George Ioakimedes wrote: I recently connected a 2 channel LVDS panel to Cubieboard2 (A20) and it worked well with just the normal FEX file changes. On Mon, Jan 19, 2015 at 11:45 PM, Kaspter Ju nigh0st3...@gmail.com mailto:nigh0st3...@gmail.com mailto:nigh0st3...@gmail.com mailto:nigh0st3...@gmail.com__ wrote: Hi all LVDS two channels pannel can't works well, Can you explain how you write directly in PLL registers and which values ? many thanks. -Kaspter On 01/07/2014 02:38 PM, TsvetanUsunov wrote: LVDS works, but as I reported a month ago LVDS driver is buggy, if the LVDS is one channel clock is OK, if the LVDS is two channels (like for Full HD 1980x1080p LCDs) the clock gets divided by the number of the channels which is wrong and we fix this manually by writing directly in PLL registers Tsvetan 07 януари 2014, вторник, 08:33:08 UTC+2, Dmitriy B. написа: Interesting detail is, OLIMEX now sells LVDS panel https://www.olimex.com/Products/OLinuXino/A20/A20-LCD15.6/ https://www.olimex.com/__Products/OLinuXino/A20/A20-__LCD15.6/ https://www.olimex.com/__Products/OLinuXino/A20/A20-__LCD15.6/ https://www.olimex.com/Products/OLinuXino/A20/A20-LCD15.6/ https://www.olimex.com/Products/OLinuXino/A20/A20-LCD15.6/ https://www.olimex.com/__Products/OLinuXino/A20/A20-__LCD15.6/ https://www.olimex.com/__Products/OLinuXino/A20/A20-__LCD15.6/ https://www.olimex.com/Products/OLinuXino/A20/A20-LCD15.6/ http://olimex.wordpress.com/2013/12/09/new-product-in-stock-monster-lvds-15-6-lcd-for-a20-olinuxino/ http://olimex.wordpress.com/__2013/12/09/new-product-in-__stock-monster-lvds-15-6-lcd-__for-a20-olinuxino/ http://olimex.wordpress.com/__2013/12/09/new-product-in-__stock-monster-lvds-15-6-lcd-__for-a20-olinuxino/ http://olimex.wordpress.com/2013/12/09/new-product-in-stock-monster-lvds-15-6-lcd-for-a20-olinuxino/ http://olimex.wordpress.com/2013/12/09/new-product-in-stock-monster-lvds-15-6-lcd-for-a20-olinuxino/
Re: [linux-sunxi] Subj: A20 mainline, using allwinner,sunxi-nand
Hi, On Fri, Jan 16, 2015 at 01:33:40PM +0100, Lars Doelle wrote: Hi Maxime, working on the dts for an A20 device, I'm currently at the nand. I assume you are aware of the current state of the NAND, right? Not exactly, so I better be explicit. I assume, that the linux-sunxi /dev/nand driver does not do any wear-level mapping on the first blocks. Thus I'd be able to read the first MB out by both /dev/nand in linux-sunxi and by the mtd driver in mainline with identical results. Further, I have a yet unused NAND on a Lime2 board, so I could dare to test writing to some higher addresses. That's about the experiment I plan to do initially. I'm aware, that the first sectors are precious for the boot process and must be preserved, but they could be restored via FEX-boot in case I break them by wrong pin settings or whatever else. I've not researched whether ubi would touch the boot sector, and I will not try to install any fs before making sure, that it is preserved. I'm booting from a SD anyway, so it is only boot0 that I have to care for to keep the device operational. But that is all a different construction site. Now if you say the current state is too experimental for any such tries, I'd better keep hands off the mainline's NAND, and I'll appreciate all your warnings, Maxime. The code in the current kernel doesn't support anything but SLC NAND, which means that MLC NAND won't work unless you merge some additional patches on top of that. UBIFS doesn't deal well with MLC NAND, so you could also end up with corrupted pages in case of a power failure for example. This is also still a bit rough around the edges, so it won't work out of the box for your board, and you might encounter driver bugs. Nothing really bad if you know what you're doing, but still, you have to know what you are doing. Looking at Documentation/devicetree/bindings/mtd/sunxi-nand.txt, there are two parts in the example, that do not really make sense to me: 1) interrupts Does anyone know what interrupt is refered to in the example? The A20 handbook lists GIC 69 for NAND, while 37 in the example is IR 0. All the GIC interrupts above 32 are SPIs. 69 - 32 = 37 So I use 37, as this is a SPI interrupt. Yep, with the first argument of the cell being 0, which corresponds to the GIC SPI. 2) pinctrl-0 If I understand correctly, I'd setup two pinctrl groups, one for all pins with function nand0, i.e. PC00 to PC18. PC19-PC22 are not mentioned in my FEX, so I'd leave the later out. PC23 has function spi0 and goes to the second group. I don't really know what you want to achieve, but it sounds sensible, even though I don't really know why SPI0 is involved here. Maxime, honestly, I don't know. I simply translated the FEX config, which, like in the example of the [[Fex guide]], says: nand_spi = port:PC233defaultdefaultdefault Now MUX 3 translates to function spi0 for that pin, that's why SPI0 is involved. That seems useless to me, but why not. I'd leave out any allwinner,pull and allwinner,drive properties for these groups assuming pinctrl derives them from the functions. No. I cannot derive anything from any function. OK. My FEX spells default for all these values. I assume these are the default values as in the A20 Handbook, section 1.19.4.24. to 1.19.4.27. These spell all pins driven by 20 mA but vary in pull-ups, which does not really make much sense to me. It should all be NO_PULL, doesn't it, or should I preserve these defaults? The default are 10mA, without any pull resistor. If that worked for you, you can keep it that way. Now what puzzles me is, that in the example three groups are setup distinguishing nand_pins_a and nand_rb0_pins_a, though they have all the same function nand0. Do I misunderstand anything at that point, or is this grouping just a matter of personal style? R/B and CS pins are optional and this configuration change to one from another. If your board use both the nand controller pins to do that, you need to mux them, but your board might not use them, or use GPIOs instead for example. In order to support the most cases, we split it into three groups: the main pins (needed by anyone), the rb pins and the cs pins. I've no idea how the tablet's board is wired actually, my only information come from the FEX file, which is exactly like in the [[Fex guide]] example, only that values for CE4-CE7 are left empty. Well, the FEX file already gives you some information on how the board is wired. You should have everything you need there. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving
[linux-sunxi] Re: [PATCH v4 3/5] ARM: sunxi: dts: Add PS2 nodes to dtsi for A10 and A20
On Wed, Jan 21, 2015 at 04:40:28PM +0530, Vishnu Patekar wrote: On Wed, Jan 21, 2015 at 1:32 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Vishnu, On Fri, Jan 16, 2015 at 07:33:39PM +0530, Vishnu Patekar wrote: Signed-off-by: VishnuPatekar vishnupatekar0...@gmail.com Signed-off-by: Hans de Goede hdego...@redhat.com Why is there Hans Signed-off here? Hans has modified the A10 dtsi and also tested on A10 board. Shouldn't I add him as Signed-off? Yeah, you should :) Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)
Hi, On 22-01-15 15:43, Michal Suchanek wrote: Hello, On 22 January 2015 at 14:26, Hans de Goede hdego...@redhat.com wrote: Hi, On 22-01-15 08:30, Siarhei Siamashka wrote: On Tue, 20 Jan 2015 14:16:35 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 20-01-15 09:16, Siarhei Siamashka wrote: On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 04-01-15 20:19, Michal Suchanek wrote: Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for smooth HDMI scanout of large frambuffer (eg. 1080p). This fix comes at the cost of some overall memory bandwidth so it might be appropriate to detect a10s and only apply there (and not a13). Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what do you think of the proposed change ? I don't have A10s hardware, so have no idea and can't test anything myself. It would be great to have a better description of what exactly is happening before the patch. And precisely how the patch is helping. A description of the test setup and benchmark numbers would be appreciated. And it would be perfect if somebody else could reproduce the test and confirm the results. I may try to check A20 with the bus width artificially reduced to 16 bits (not a totally unrealistic configuration, since A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar enough, then the magic reserved bit may have some effect there too. But that's a different hardware either way. Done these tests with A20. Ironically, now the tables have turned and A10 seems to be doing a better job than A20 at low DRAM clock speeds (~408MHz) and 16-bit bus width when dealing with full-hd monitors. Just like Michal observed on A10s, setting 0x5031 as DEFE host port config makes things much worse on A20. Overall, the test results look in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes, none of the real boards uses such a slow DRAM setup) while running lima-memtester and driving 1920x1080-32@60Hz monitor: 0x1035 - The screen regularly blanks, but comes back again instantly. 0x1037 - The screen regularly blanks, but comes back again instantly. 0x5031 - Severe screen shaking. Unlike A10, there does not seem to be any difference between using DEBE or DEFE for framebuffer scanout on A20, so using DEBE has the same effect as listed above. Setting the magic 'reserved' hpcr bit 1 (0x1037 value) does not seem to have any effect on sun7i. It is great that it is apparently helping on sun5i/A10s though. Thanks for running these tests, this makes me more confident that I only need to enable DEFE in u-boot on A10, and can directly use DEBE on the others. But what about A10s? Do we want to do something about it? Once we have some feedback from hramrach from running tests with / without the frontend enabled, then yes, unless the fix is to simple disable the frontend, and then u-boot probably is fine as is. I need to re-test this but it seemed that on my a10s board enabling and disabling scaler had pretty much no impact on display performance. Increasing the priority of the display ports did not seem to increase display performance either. However, setting the 'magic' bit degraded memory throughput as reported by the lima-memspeed somewhat but enabled jump-free lima-memtester rotating cube. Since a13 has no hdmi this is moot for most sun5i hardware. Affected would be the obsolete olinuxinos and a few HDMI sticks that actually had a10s in them. There are actually a lot of a10s using HDMI sticks out there (all later mk802 models use the a10s + many others) as well as various a10s based top setboxes and an a10s variant of the mini-x. So I would really like to get this fixed, I'm ok with applying your fix, but before that I would like to see the following confirmed: 1) That currently you are using the scaler, since your patch modifies the scaler dram prio anything else would make no sense 2) Please retest without the scalar, and if you've the same problem try applying the same fix / DRAM settings to the DEBE dram prio bits. See http://ssvb.github.io/2014/11/11/revisiting-fullhd-x11-desktop-performance-of-the-allwinner-a10.html for a list of which dram prio config word is what. Thanks, Hans -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Announcing easy Linux installation on Allwinner devices for non-geek users
Hi, On 01/22/2015 01:49 PM, Siarhei Siamashka wrote: = == 4. NAND = NAND is the hardware, which is supported by BROM. Which means that it should be usable in a generic way by the universal device independent u-boot binary. Nice NAND is a perfect place to store the device specific information. So that the user can avoid the annoying device type selection choices. I expect that many non-technical users that bought a simple white label Android tablet at their local brick-and-mortar toy store, like to keep Android that was shipped with their devices in NAND. But do might want to play with Linux installed on SD card. If DRAM, SD-card and NAND can be detected properly, what about just: 1) boot from SD card 2) let u-boot load Android's script.bin from NAND 3) boot the Linux kernel from SD card. (via sunxi-babelfish to translate script.bin on-the-fly if using mainline Linux) -- Yours sincerely, Floris Bos -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] Announcing easy Linux installation on Allwinner devices for non-geek users
On 01/22/2015 08:20 AM, Hans de Goede wrote: Hi Siarhei, See the bottom for my reply to all this. On 22-01-15 13:49, Siarhei Siamashka wrote: Hello, This is a somewhat long e-mail. Thanks for reading and reaching the end of this e-mail. Special thanks to Luc Verhaegen, Roman Byshko and Hans de Goede for their work on u-boot. You're welcome, and thank you too for all your work on sunxi support, especially the sun4i/sun5i/sun7i dram work. So about the above mail, I've a number of things to say: 1) I think presenting the user with a list of devices to choose is a good idea, but I also think your solution is over complicated. The user will likely use a PC to download and write the image to the sdcard, why not simply provide a simple app on the PC side to select the board and write the correct u-boot binary ? I had a little bash script doing just that for the Fedora images, granted this requires the user to have Linux, so maybe we need someone to get to write a win32 util for this, so that we can offer both options ? To me this seems much more simple, and it will e.g. also work for a23 / a33 based tablets, which do not have hdmi and are really attractive for little hobby projects due to their low price (35-40 usd for a complete tablet). I should have waited for your reply, Hans. You see the issues much clearer than I. Yes, I *like* how I build an SD card for Fedora. I had sent in the little change to add the Cubieboard2 to the fedora-arm list some time ago. I might think this script could be dynamically created by set of files. But it does not help for new boards? What is currrently in Fedora assumes that everything for each board is worked out, and the uboot is provided. Siarhei is proposing a, perhaps complex, method of 1st boot building the right uboot for the board. So the SD card is built through the initial download and script (running xzcat plus whatever) with a general uboot, and then 1st boot customizes the uboot to that board? I would still want my serial console access to this process. At first I really complained about needing a serial console; it was taking me back to my UNIX days in the early '90s! Perhaps I would have to pull that Xyplex serial terminal server out of my junk bin to get multiple systems supported! but after I REALLY costed things out, I am a fan of the serial console for servers. A friend has a wandboard (Freescale SOC) and that has a real DB9 for the console, so he needs a DB9 serial/USB adapter. I would not be supprised of some Allwinner boards have gone to this expense. 3) As for the whole store info in nand based on sid idea, with the recent readonly nand patches posted to the list, which AFAIK do not need any nand parameters, we could do one better and read the dram timings from the nand for the SPL, and the in real u-boot read and parse script.bin from the nanda partition. This is a bit of a wild idea I admit, but it could work, I would want an installer to move as much as possible of the OS to the NAND and eliminate the need of the SD after 1st boot! Also make it easy to partition a HDD/SSD for swap and /home and whatever else (disk druid here we come?) Starting out on an SD card is good, but a serious desktop will have a serious drive. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] Announcing easy Linux installation on Allwinner devices for non-geek users
On 01/22/2015 07:49 AM, Siarhei Siamashka wrote: Hello, This is a somewhat long e-mail. Yes it is. Thank you for this detailed introduction to the problem and solutions. As a semi-skilled user and proponent of armv7, I really welcome all the work you and others have done. Just wish it was done 6 months ago! :) 2. A possible solution = == 2. A possible solution = For example, the UART serial console is not really used by BROM, and this was a kind of hack in the previous demo. At that time it looked like the serial console could be configured correctly according to some heuristic rules. However later it turned out that the heuristics does not really work on some A13 devices and they may have mutually incompatible UART configurations: ... Anyway, the really missing part was the user friendly output and user friendly input for generic u-boot binaries. HDMI is widely used in Allwinner hardware and it supports autoconfiguration. USB host ports use dedicated pins and only enabling/disabling power can be device specific. The missing USB power can be solved by using a powered USB hub, which is not very convenient, but still a workable solution. ... It is a demo of a universal SD card image, which should be bootable on any Allwinner A10/A10s/A20 device. With an installer of u-boot v2015.01-rc3 as the initial demo simple payload. By using a HDMI monitor for output and a USB keyboard or FEL button for input, it offers a menu based user interface. The menu allows to select the exact type of the user's Allwinner device and install the right bootloader for it. This is all great with one possible exception: server setups with no monitor/kybd. Take a look at: http://medon.htt-consult.com/~rgm/cubieboard/ You will see 5 cubieboard2 + drives in a nice tower arrangement. These are powered by one Anker 40W 5-port USB power supply. Note that every board has a 'dedicated' UART/USB serial console. These are $2 each compared to the cost of HDMI cables and an HDMI KVM switch (cheapest 4 porter I have found is $100; no cheap 8 porter). All I need to do is connect my USB extension cable to one, connect to a notebook and run 'screen /dev/ttyUSB0 115200' and I have the console for booting/configs. So I would want the option of a serial console menu. I suspect that screen supports VT-100 style menu controls, just have not had a situation to tried it. I am excited about the prospect that installing your Linux distro of choice on your Allwinner board of choice for a desktop system will soon be achievable. In May I will be visiting my parents for their 70th wedding anniversary, and would love to set them up with a system on their TV. But please consider the server use and the serial console. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)
Hello, On 22 January 2015 at 14:26, Hans de Goede hdego...@redhat.com wrote: Hi, On 22-01-15 08:30, Siarhei Siamashka wrote: On Tue, 20 Jan 2015 14:16:35 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 20-01-15 09:16, Siarhei Siamashka wrote: On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 04-01-15 20:19, Michal Suchanek wrote: Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for smooth HDMI scanout of large frambuffer (eg. 1080p). This fix comes at the cost of some overall memory bandwidth so it might be appropriate to detect a10s and only apply there (and not a13). Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what do you think of the proposed change ? I don't have A10s hardware, so have no idea and can't test anything myself. It would be great to have a better description of what exactly is happening before the patch. And precisely how the patch is helping. A description of the test setup and benchmark numbers would be appreciated. And it would be perfect if somebody else could reproduce the test and confirm the results. I may try to check A20 with the bus width artificially reduced to 16 bits (not a totally unrealistic configuration, since A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar enough, then the magic reserved bit may have some effect there too. But that's a different hardware either way. Done these tests with A20. Ironically, now the tables have turned and A10 seems to be doing a better job than A20 at low DRAM clock speeds (~408MHz) and 16-bit bus width when dealing with full-hd monitors. Just like Michal observed on A10s, setting 0x5031 as DEFE host port config makes things much worse on A20. Overall, the test results look in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes, none of the real boards uses such a slow DRAM setup) while running lima-memtester and driving 1920x1080-32@60Hz monitor: 0x1035 - The screen regularly blanks, but comes back again instantly. 0x1037 - The screen regularly blanks, but comes back again instantly. 0x5031 - Severe screen shaking. Unlike A10, there does not seem to be any difference between using DEBE or DEFE for framebuffer scanout on A20, so using DEBE has the same effect as listed above. Setting the magic 'reserved' hpcr bit 1 (0x1037 value) does not seem to have any effect on sun7i. It is great that it is apparently helping on sun5i/A10s though. Thanks for running these tests, this makes me more confident that I only need to enable DEFE in u-boot on A10, and can directly use DEBE on the others. But what about A10s? Do we want to do something about it? Once we have some feedback from hramrach from running tests with / without the frontend enabled, then yes, unless the fix is to simple disable the frontend, and then u-boot probably is fine as is. I need to re-test this but it seemed that on my a10s board enabling and disabling scaler had pretty much no impact on display performance. Increasing the priority of the display ports did not seem to increase display performance either. However, setting the 'magic' bit degraded memory throughput as reported by the lima-memspeed somewhat but enabled jump-free lima-memtester rotating cube. Since a13 has no hdmi this is moot for most sun5i hardware. Affected would be the obsolete olinuxinos and a few HDMI sticks that actually had a10s in them. Thanks Michal -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [U-Boot] Announcing easy Linux installation on Allwinner devices for non-geek users
On 22 January 2015 at 14:20, Hans de Goede hdego...@redhat.com wrote: Hi Siarhei, See the bottom for my reply to all this. On 22-01-15 13:49, Siarhei Siamashka wrote: This universal u-boot would be awesome and it looks like it's getting close enough. You're welcome, and thank you too for all your work on sunxi support, especially the sun4i/sun5i/sun7i dram work. So about the above mail, I've a number of things to say: 1) I think presenting the user with a list of devices to choose is a good idea, but I also think your solution is over complicated. The user will likely use a PC to download and write the image to the sdcard, why not simply provide a simple app on the PC side to select the board and write the correct u-boot binary ? I had a little bash script doing just that for the Fedora images, granted this requires the user to have Linux, so maybe we need someone to get to write a win32 util for this, so that we can offer both options ? A bash script should presumably work on any unix so long as the only operation needed is to copy/symlink a dtb or script.bin It requires separate FAT partition for kernel. I am not sure all distro tools handle installing kernel to FAT flawlessly but I think it's sometimes used on EFI as well. To me this seems much more simple, and it will e.g. also work for a23 / a33 based tablets, which do not have hdmi and are really attractive for little hobby projects due to their low price (35-40 usd for a complete tablet). ok, if you want me to write a windows app for this I can probably do that. I think there was severe limitation with VB dialog capabilities but you can always write a GTK app and then just compile it for Windows or something. You probably would not want something like copying whole pygtk runtime to the boot partition just to show a menu so either using windows-native scripting or C is probably preferred. 2) I would love to see a good fex file parser both the generate u-boot defconfig files and kernel dts files That would certainly help, especially with those tablets where the serial pins are dangling or connected to some random unpowered piece of hardware like the camera and u-boot gets stuck because there is noise on the console and it interprets it as the user interrupting the automatic boot sequence. 3) As for the whole store info in nand based on sid idea, with the recent readonly nand patches posted to the list, which AFAIK do not need any nand parameters, we could do one better and read the dram timings from the nand for the SPL, and the in real u-boot read and parse script.bin from the nanda partition. This is a bit of a wild idea I admit, but it could work, 2 problems with it are: a) It assume a standard Allwinner android nand contents, so not good for devices where people want to actually write a normal linux distro to the nand / bricked devices It does not have to. The memory parameters are in the boot area AFAIK which should be same on AW formatted flash and mainline formatted flash because the BROM reads the bootloader from there. It will have to distinguish AW boot0 and u-boot SPL, though. b) Does not work on devices without nand (e.g. some olinuxino-lime models) You always can (and should) write the parameters on the card. Reading nand is just one way of detecting them. c) Does not really help for the kernel, we could generate a dtb on the fly on u-boot based on the fex file contents, but that is going to be very tricky, esp with the dtb files evolving as we start supporting more and more hw features in the upstream kernel. The problem with generating the dtb or even just using existing fex with linux-sunxi is that some default values which can be omitted in manufacturer fex have to be specified in linux-sunxi fex or dtb. For one, tablet keys default to on when there is no section for them and I had to explicitly enable them on my tablets. Thanks Michal -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v4 2/5] ARM:sunxi:drivers:input Add support for A10/A20 PS2
On Wed, Jan 21, 2015 at 04:52:04PM +0530, Vishnu Patekar wrote: Hello Dmitry, On Tue, Jan 20, 2015 at 6:05 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Mon, Jan 19, 2015 at 11:37:38AM +0530, Vishnu Patekar wrote: Hello Dmitry, Thank you for review comments. Please see in-lined. On Sun, Jan 18, 2015 at 3:55 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Hi Vishnu, On Fri, Jan 16, 2015 at 07:33:38PM +0530, Vishnu Patekar wrote: Signed-off-by: VishnuPatekar vishnupatekar0...@gmail.com --- drivers/input/serio/Kconfig | 11 ++ drivers/input/serio/Makefile|1 + drivers/input/serio/sun4i-ps2.c | 330 +++ 3 files changed, 342 insertions(+) create mode 100644 drivers/input/serio/sun4i-ps2.c diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index bc2d474..964afc5 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -281,4 +281,15 @@ config HYPERV_KEYBOARD To compile this driver as a module, choose M here: the module will be called hyperv_keyboard. +config SERIO_SUN4I_PS2 + tristate Allwinner A10 PS/2 controller support + default n + depends on ARCH_SUNXI || COMPILE_TEST + help + This selects support for the PS/2 Host Controller on + Allwinner A10. + + To compile this driver as a module, choose M here: the + module will be called sun4i-ps2. + endif diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile index 815d874..c600089 100644 --- a/drivers/input/serio/Makefile +++ b/drivers/input/serio/Makefile @@ -29,3 +29,4 @@ obj-$(CONFIG_SERIO_ARC_PS2) += arc_ps2.o obj-$(CONFIG_SERIO_APBPS2) += apbps2.o obj-$(CONFIG_SERIO_OLPC_APSP)+= olpc_apsp.o obj-$(CONFIG_HYPERV_KEYBOARD)+= hyperv-keyboard.o +obj-$(CONFIG_SERIO_SUN4I_PS2)+= sun4i-ps2.o diff --git a/drivers/input/serio/sun4i-ps2.c b/drivers/input/serio/sun4i-ps2.c new file mode 100644 index 000..06b3fef --- /dev/null +++ b/drivers/input/serio/sun4i-ps2.c @@ -0,0 +1,330 @@ +/* + * Driver for Allwinner A10 PS2 host controller + * + * Author: Vishnu Patekar vishnupatekar0...@gmail.com + * Aaron.maoye leafy.m...@newbietech.com + * + * + */ + +#include linux/module.h +#include linux/serio.h +#include linux/interrupt.h +#include linux/errno.h +#include linux/slab.h +#include linux/list.h +#include linux/io.h +#include linux/of_address.h +#include linux/of_device.h +#include linux/of_irq.h +#include linux/of_platform.h +#include linux/clk.h +#include linux/delay.h + +#define DRIVER_NAME sun4i-ps2 + +/* register offset definitions */ +#define PS2_REG_GCTL 0x00/* PS2 Module Global Control Reg */ +#define PS2_REG_DATA 0x04/* PS2 Module Data Reg */ +#define PS2_REG_LCTL 0x08/* PS2 Module Line Control Reg */ +#define PS2_REG_LSTS 0x0C/* PS2 Module Line Status Reg */ +#define PS2_REG_FCTL 0x10/* PS2 Module FIFO Control Reg */ +#define PS2_REG_FSTS 0x14/* PS2 Module FIFO Status Reg */ +#define PS2_REG_CLKDR0x18/* PS2 Module Clock Divider Reg*/ + +/* PS2 GLOBAL CONTROL REGISTER PS2_GCTL */ +#define PS2_GCTL_INTFLAG BIT(4) +#define PS2_GCTL_INTEN BIT(3) +#define PS2_GCTL_RESET BIT(2) +#define PS2_GCTL_MASTER BIT(1) +#define PS2_GCTL_BUSEN BIT(0) + +/* PS2 LINE CONTROL REGISTER */ +#define PS2_LCTL_NOACK BIT(18) +#define PS2_LCTL_TXDTOEN BIT(8) +#define PS2_LCTL_STOPERREN BIT(3) +#define PS2_LCTL_ACKERRENBIT(2) +#define PS2_LCTL_PARERRENBIT(1) +#define PS2_LCTL_RXDTOEN BIT(0) + +/* PS2 LINE STATUS REGISTER */ +#define PS2_LSTS_TXTDO BIT(8) +#define PS2_LSTS_STOPERR BIT(3) +#define PS2_LSTS_ACKERR BIT(2) +#define PS2_LSTS_PARERR BIT(1) +#define PS2_LSTS_RXTDO BIT(0) + +#define PS2_LINE_ERROR_BIT \ + (PS2_LSTS_TXTDO | PS2_LSTS_STOPERR | PS2_LSTS_ACKERR | \ + PS2_LSTS_PARERR | PS2_LSTS_RXTDO) + +/* PS2 FIFO CONTROL REGISTER */ +#define PS2_FCTL_TXRST BIT(17) +#define PS2_FCTL_RXRST BIT(16) +#define PS2_FCTL_TXUFIEN BIT(10) +#define PS2_FCTL_TXOFIEN BIT(9) +#define PS2_FCTL_TXRDYIENBIT(8) +#define PS2_FCTL_RXUFIEN BIT(2) +#define PS2_FCTL_RXOFIEN BIT(1) +#define PS2_FCTL_RXRDYIENBIT(0) + +/* PS2 FIFO STATUS REGISTER */ +#define PS2_FSTS_TXUFBIT(10) +#define PS2_FSTS_TXOFBIT(9) +#define PS2_FSTS_TXRDY
Re: [linux-sunxi] Re: [PATCH] sunxi: Add Gemei G9 (Allwinner A10/sun4i) tablet
On Thu, 2015-01-22 at 09:47 +0200, Siarhei Siamashka wrote: On Tue, 20 Jan 2015 15:43:31 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, [...] We have already talked with plaes on IRC yesterday, just now bringing it here. I have finally updated the http://linux-sunxi.org/LCD page to add LVDS panels data and now for Gemei_G9 we have the following settings there: CONFIG_VIDEO_LCD_MODE=x:1024,y:768,depth:24,pclk_khz:10,le:799,ri:260,up:15,lo:16,hs:1,vs:1,sync:3,vmode:0 CONFIG_VIDEO_LCD_PANEL_LVDS=y # warning: unsupported 'lcd_lvds_mode' : 1 CONFIG_VIDEO_LCD_POWER=PH8 CONFIG_VIDEO_LCD_BL_EN=PH7 CONFIG_VIDEO_LCD_BL_PWM=PB2 It's good that lcd_lvds_mode=1 apparently works without problems, while this was not fully expected according to http://lists.denx.de/pipermail/u-boot/2015-January/200168.html Also confirming whether 18-bit or 24-bit is the correct color depth would be a good idea. This tablet has 'lcd_frm = 1' and 'lcd_lvds_bitwidth = 0' in fex. So I tried the 24bit depth setting and it messed up some of the colors (though black remained black and white remained white) in the penguin image in top left corner. Therefore this tablet seems to have 18bit LCD. Päikest, Priit :) -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
