Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33
On Mon, Sep 08, 2014 at 06:01:25PM +0200, Luc Verhaegen wrote: On Mon, Sep 08, 2014 at 04:33:48PM +0200, Maxime Ripard wrote: On Mon, Sep 08, 2014 at 03:55:19PM +0200, Luc Verhaegen wrote: For those who do not know what Maxime is on about, here is the short explanation: http://linux-sunxi.org/Allwinner_SoC_Family#Naming_confusion I do not buy the modern allwinner sunXi naming. Retro-actively renaming half their line-up sun4i and the other half sun8i, I have seen that before (cfr unichrome.sf.net). A few months in, and that Vendor did another little pirouette. And again, and again. Where Allwinner drew the naming line now is quite arbitrary: the type of the ARM core in there. The one component which is mostly generic and reasonably universal. Sun4i suddenly became all ARM Cortex A8, sun8i became all ARM Cortex A7. Now that they stuck a few A15 in A80, they named that sun9i. Actually, I do find it consistent. For now. Forgive me, I don't have the chance to own a crystal ball. If the sunXiwYpZ scheme actually had something to do with the majority of SoC specific component lineage, i would've totally bought into it: that would put A20 close to A10, and would put A31 somewhere else altogether, with A23 and A33 close together... Yeah, right, as if the sun4i/sun5i was in any way better It was a consistent scheme, which allwinner followed for many many years. No, it was not. If it was to be a purely time-driven naming scheme, A10s should have been sun6i. So no, this is purely a marketing driven decision, which will have changed again in 6 months time. Where will Allwinners freshly announced A83 land? Will they stick to their own naming scheme? What will happen when Allwinner produces an ARMv8 chip, will they count beyond 9, or will they rename everything sun7i/sun8i? Sun[4567]i was chronological, and initially sun[89]i were too. So I say we just keep on counting for ourselves. A10s was released after A13, A31 and A20 at the same time. Not very chronological if you ask me... A10s is A13. [citation needed] The A20 design was a stopgap, and the design started after A31 was started. So it was chronological, just not chronological with the release dates. Yeah, right. So it's chronological, but we have no way to tell, except by fully trusting you. The argument of (which?) authority is not really something that usually convince me. But I guess what it all boils down is this: do we want to keep allwinner's naming and be consistent with it or not. We've been so far, it's something I'd like to be kept. Especially since it's *very* easy to support (basically, keep the sun6i and sun7i, introduce sun8i for A23, A33, and whatever comes next, which should be the best if following your connection argument), and have sun9i for the A80. But this is not consistent with Allwinner naming. Being consistent with allwinner naming would mean renaming most of the upstream code. And then doing it again a few months from now. It is. You can find some reference to A31 being sun6i, and A20 being sun7i. Can you find any reference to A33 being sun10i? Sun8i for A23 and A33 will only work until we see allwinner give out the codename for A83, and whether the early marketing noise for it matches reality and it really is a octal A7 with powervr. Something tells me that this is going to be an A80, with less dram channels, less rogue shaders, and with A7s instead of A15. I guess it could fit into both sun8i and sun9i. But A83 isn't really the topic here, is it? And even if Allwinner introduces a sun10i for A83, it will only proves that we were wrong by trying to stick it to A33. Introducing this sun10i out of nowhere, without any other code/documentation referring to it, and with the only argument that some guy thought it was a better idea is not that great. Especially when the time where they will have a new design and come up with sun10i chips. It will be a very short pain. Look closer into your crystal ball. Another option is to completely switch to AWchip id, which would mimic what i did for unichrome. A10= AW1623 (sun4i) A13/A10s = AW1625 (sun5i) A31= AW1633 (sun6i) A20= AW1651 (sun7i) A23= AW1650 (sun8i) A80= AW1635 (sun9i) A33= AW1667 (...) Now that's going to be real confusing. That could be an option, but like you said, it's pretty confusing to existing user of our code base. This is going to be a big pain. But ok, so what do you want to call A33, and do we rename A23 away from sun8i, by adding suffixes there as well? The sun8isuffix solution is only a band-aid though. Perhaps A83 will fit in this scheme, perhaps not. Something tells me that armv8 is going to seriously kill this, and will require a more permanent solution to this
Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33
On 9 September 2014 11:53, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, Sep 08, 2014 at 09:53:21PM +0200, Michal Suchanek wrote: A10= AW1623 (sun4i) A13/A10s = AW1625 (sun5i) A31= AW1633 (sun6i) A20= AW1651 (sun7i) A23= AW1650 (sun8i) A80= AW1635 (sun9i) A33= AW1667 (...) Now that's going to be real confusing. That could be an option, but like you said, it's pretty confusing to existing user of our code base. Ok, so how about printing all of the above? It's not just about printing. If we want to be consistent, we would have to stick with a single naming scheme. So that would mean also fixing up the source code of linux/uboot, the configuration files, the wiki, etc. If you want to spend time doing so, great. But I have no intention to follow you down this road. The chip id is something burnt into the SoC and cannot be disputed. From the chip id it can be guessed what is probably printed on the package unless AW marketing got *really* creative. As far as I know, it's indeed on the package. But the package might not be visible, due to an heatsink for example. But it's what it sells as and what is in the marketing material of the product that includes the SoC in cases when it is correct. 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] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33
On Tue, Sep 09, 2014 at 12:41:41PM +0200, Michal Suchanek wrote: On 9 September 2014 11:53, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, Sep 08, 2014 at 09:53:21PM +0200, Michal Suchanek wrote: A10= AW1623 (sun4i) A13/A10s = AW1625 (sun5i) A31= AW1633 (sun6i) A20= AW1651 (sun7i) A23= AW1650 (sun8i) A80= AW1635 (sun9i) A33= AW1667 (...) Now that's going to be real confusing. That could be an option, but like you said, it's pretty confusing to existing user of our code base. Ok, so how about printing all of the above? It's not just about printing. If we want to be consistent, we would have to stick with a single naming scheme. So that would mean also fixing up the source code of linux/uboot, the configuration files, the wiki, etc. If you want to spend time doing so, great. But I have no intention to follow you down this road. The chip id is something burnt into the SoC and cannot be disputed. From the chip id it can be guessed what is probably printed on the package unless AW marketing got *really* creative. As far as I know, it's indeed on the package. But the package might not be visible, due to an heatsink for example. But it's what it sells as and what is in the marketing material of the product that includes the SoC in cases when it is correct. Not really, you'll never find any board/device sold as embedding an AW1635. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33
On Tue, Sep 09, 2014 at 12:05:54PM +0200, Maxime Ripard wrote: On Mon, Sep 08, 2014 at 06:01:25PM +0200, Luc Verhaegen wrote: For now. Forgive me, I don't have the chance to own a crystal ball. And logically extrapolating is not one of your strengths either apparently. It was a consistent scheme, which allwinner followed for many many years. No, it was not. If it was to be a purely time-driven naming scheme, A10s should have been sun6i. See below. It was consistent. A10s is A13. [citation needed] Why else does allwinner call them both sun5i? Why else does A13 have a fully working hdmi block sitting there? Citation: my uboot cfbconsole code where i successfully use HPD detection on A13. This fails nicely, as no hpd pin is exported outside of the chip, and it is never raised to 5V. But please go ask our Allwinner contacts or Tom Cubie or something. The A20 design was a stopgap, and the design started after A31 was started. So it was chronological, just not chronological with the release dates. Yeah, right. So it's chronological, but we have no way to tell, except by fully trusting you. The argument of (which?) authority is not really something that usually convince me. It is pretty logical. A31 was named sun6i, A20 was named sun7i. A31 was a major redesign. A20 was throwing 2 A7s and a second fragment shader, and some minor fixes onto A10. The latter was either a stopgap, or a deliberate market decision, it at least took a lot less time to complete. Hence them both arriving at the same time. Again, the above is the best logical explanation for events. But this is not consistent with Allwinner naming. Being consistent with allwinner naming would mean renaming most of the upstream code. And then doing it again a few months from now. It is. You can find some reference to A31 being sun6i, and A20 being sun7i. Can you find any reference to A33 being sun10i? You did find A31 and A20 as sun6i and sun7i when Allwinner was still on a relatively sane naming scheme. You cannot find these references anymore on anything allwinner produces today. So either you go allwinner, or you don't. Sun8i for A23 and A33 will only work until we see allwinner give out the codename for A83, and whether the early marketing noise for it matches reality and it really is a octal A7 with powervr. Something tells me that this is going to be an A80, with less dram channels, less rogue shaders, and with A7s instead of A15. I guess it could fit into both sun8i and sun9i. But A83 isn't really the topic here, is it? But it is. Or it very much will be, in about 6 months time. And even if Allwinner introduces a sun10i for A83, it will only proves that we were wrong by trying to stick it to A33. Or it could end up proving that we were right to not use Allwinners current scheme, and instead diverged and stuck to Allwinners older, saner scheme. It will be a very short pain. Look closer into your crystal ball. We'd just keep on counting up. Since we wouldn't be calling this chip sun10iw1p1 but instead sun12i or so, there will be no real discrepancy. We'd be talking about sun10i without a suffix. And there would be only minimal room for confusion. But ok, so what do you want to call A33, and do we rename A23 away from sun8i, by adding suffixes there as well? The sun8isuffix solution is only a band-aid though. Perhaps A83 will fit in this scheme, perhaps not. Something tells me that armv8 is going to seriously kill this, and will require a more permanent solution to this problem. A more permanent solution to a problem that isn't even a problem. Yeah, definitely looks way more important than a proper display driver. Why not? So you do not want to support any users beyond a20 and a31? And we've already established that you are against collecting device information and helping users get a proper linux up on their random android devices. You do find it necessary to complain about a naming scheme, and then you go and state that it is not important. Which is it? Is it not important (especially since it is on software you do not want to care about, as it is there to help bring up new devices), then why did you care to complain? If it is important, then why are you not contributing more to things surrounding and supporting mainline kernel code? Luc Verhaegen. -- 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: [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33
For now. Forgive me, I don't have the chance to own a crystal ball. And logically extrapolating is not one of your strengths either apparently. Could we try to stay friendly? Pretty please? Stefan -- 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] New device support strategy.
Hi, A31 was always a pretty marginal affair for Allwinner. I doubt that they made much money off of it. A23 should've been a wake-up call for us, but we seemed unable to get much going with it. With A33 and A80 happening now, and with Olimex doing an A31 device, and with development boards becoming available for A80 we realy do need to change our act. We just aren't going to be able to support these devices with our sunxi-3.4 kernel. Period. But... It is also mighty important that we provide straightforward device support for devices based upon the newer chipsets. For one, the fact that we can quickly grab a fex and easily support previously unknown devices is what put us apart from other ARM projects, it is why we are thriving today. By having lowered the threshold to support any random android device, we have kept a steady flow of new users up, and we have seen many people contribute who would've otherwise just moved on to play with something else. With our sunxi-3.4 we have also significantly lowered the threshold for mainline u-boot/kernel usage, and thus mainline u-boot/kernel development. We have no other option but to realize that we need to do more than sunxi-3.4 does today. We need to start using the SDKs more. Not that i am stating that sunxi-3.4 should be deprecated, it should still be the default kernel for A10,A13,A10s and A20. But we have to start using the SDKs more for A31(s), A23, A33 and A80 and all chips going forwards. I have already been working sunxi-tools/meminfo to help us collect dram controller information off of the newer platforms. This will allows us to create device specific dram controller parameters in future, when Allwinner finally provides us with the information needed there. This information should be gathered, for now, in sunxi-boards, probably under a to be created meminfo directory. The next step is create SoC specific Manual Build howtos, following the original on our wiki. This should point to specific branches in our sunxi u-boot and kernel trees, branches which contain SDK kernels with minimal diffs to the kernel release they are based on. We can pack fixes on top of that, and if someone is really bored, they could go port those changes to other kernels/u-boot versions. We will need to figure out how to hack the dram timing into the provided boot0 binaries, so that useful SD cards can be created (amongst others). But this should be a stop gap, as Allwinner should provide us the necessary information to add proper u-boot support. With this, we diverge from our old mode of working, but we have very little option at this point. We need go get general device support going again for newer SoCs, we need to get proper linuxes replacing androids on newer devices. Chen-yu has already been writing an SDK build howto (http://linux-sunxi.org/SDK_build_howto). I should soon start working on A23_Manual_build_howto. It's been 9 months since i got A23 that tablet, and it is high time that things start rolling properly on these devices. The NDH and existing device pages will be adjusted to point to the respective build howtos. And i hope that soon we will get some enterprising individuals writing up the missing howtos. Thanks, Luc Verhaegen. -- 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 3/3] Remove CONS_INDEX from generic A13_MID entry.
On Fri, Aug 29, 2014 at 10:42:15PM +0200, Michal Suchanek wrote: As this entry is promoted as generic tablet bootloader and uart turned on prevents booting at least on some tablets it should be removed. Separate A13_MID_UART entry is provided as sample for people who are willing to take apart their tablet and happen to find uart wired as was on the original A13_MID board. Signed-off-by: Michal Suchanek hramr...@gmail.com --- boards.cfg |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/boards.cfg b/boards.cfg index 525d8a2..2775116 100644 --- a/boards.cfg +++ b/boards.cfg @@ -380,7 +380,8 @@ Active arm armv7 sunxi - sunxi Active arm armv7 sunxi - sunxi A13-OLinuXino_FEL_sdcon sun5i:A13_OLINUXINO,SPL_FEL,STATUSLED=201,UART0_PORT_F - Active arm armv7 sunxi - sunxi A13-OLinuXinoM sun5i:A13_OLINUXINOM,SPL,NO_AXP,STATUSLED=201,CONS_INDEX=2 - Active arm armv7 sunxi - sunxi A13-OLinuXinoM_FEL sun5i:A13_OLINUXINOM,SPL_FEL,NO_AXP,STATUSLED=201,CONS_INDEX=2 - -Active arm armv7 sunxi - sunxi A13_MID sun5i:A13_MID,SPL,CONS_INDEX=2 - +Active arm armv7 sunxi - sunxi A13_MID sun5i:A13_MID,SPL - +Active arm armv7 sunxi - sunxi A13_MID_UART sun5i:A13_MID,SPL,CONS_INDEX=2 - Active arm armv7 sunxi - sunxi A86V4sun5i:A86V4,SPL - Active arm armv7 sunxi - sunxi INET86VS sun5i:INET86VS,SPL - Active arm armv7 sunxi - sunxi INET86VS_FEL_sdcon sun5i:INET86VS,SPL_FEL,UART0_PORT_F - This seems wholly incorrect. Whatever the A13-MID was, no device page was created, and no knowledge exists anymore on what it really was. At best, it has to be assumed that the console index was correct. As soon as Chen-yu pushes HSG H702 uboot support, and he stops using A13_MID, i will remove this entry. Luc Verhaegen. -- 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] [sunxi-boards 0/5] A13 tablet fex files
Fex files for two A13 tablets. With these basic functionality should be obtained on iNet 86VS and A86 V4. Dodgy devices like Mali or touchscreen are not tested and may need additional options. Thanks Michal Michal Suchanek (5): Original fex file from iNet technology 86VS (Manta MID705). Update iNet 86VS fex with a10-meminfo output. Add a86v4 original fex from Prestigio PMP370B (black). Update a86v4 fex with paramaters read from meminfo. Fix broken keys and uarts on A86 V4 and iNet 86VS sys_config/a13/a86v4.fex | 637 sys_config/a13/inet_86vs.fex | 745 ++ 2 files changed, 1382 insertions(+) create mode 100644 sys_config/a13/a86v4.fex create mode 100644 sys_config/a13/inet_86vs.fex -- 1.7.10.4 -- 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] [sunxi-boards 2/5] Update iNet 86VS fex with a10-meminfo output.
Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/inet_86vs.fex |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/sys_config/a13/inet_86vs.fex b/sys_config/a13/inet_86vs.fex index f1c224f..b2a04c2 100644 --- a/sys_config/a13/inet_86vs.fex +++ b/sys_config/a13/inet_86vs.fex @@ -54,19 +54,17 @@ dram_baseaddr = 0x4000 dram_clk = 408 dram_type = 3 dram_rank_num = 1 -dram_chip_density = 2048 -dram_io_width = 8 +dram_chip_density = 4096 +dram_io_width = 16 dram_bus_width = 16 dram_cas = 9 -dram_zq = 0x7b +dram_zq = 0x56b9697b dram_odt_en = 0 dram_size = 512 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 -dram_tpr4 = 0x0 -dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 -- 1.7.10.4 -- 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] [sunxi-boards 1/5] Original fex file from iNet technology 86VS (Manta MID705).
Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/inet_86vs.fex | 735 ++ 1 file changed, 735 insertions(+) create mode 100644 sys_config/a13/inet_86vs.fex diff --git a/sys_config/a13/inet_86vs.fex b/sys_config/a13/inet_86vs.fex new file mode 100644 index 000..f1c224f --- /dev/null +++ b/sys_config/a13/inet_86vs.fex @@ -0,0 +1,735 @@ +[product] +version = 1.0 +machine = A13-EVB-V1.0 + +[target] +boot_clock = 1008 +dcdc2_vol = 1400 +dcdc3_vol = 1200 +ldo2_vol = 3000 +ldo3_vol = 3300 +ldo4_vol = 3300 +pll4_freq = 960 +pll6_freq = 720 +power_start = 0 +storage_type = 0 + +[pm_para] +standby_mode = 0 + +[card_boot] +logical_start = 40960 +sprite_gpio0 = + +[card_boot0_para] +card_ctrl = 0 +card_high_speed = 1 +card_line = 4 +sdc_d1 = port:PF0021defaultdefault +sdc_d0 = port:PF0121defaultdefault +sdc_clk = port:PF0221defaultdefault +sdc_cmd = port:PF0321defaultdefault +sdc_d3 = port:PF0421defaultdefault +sdc_d2 = port:PF0521defaultdefault + +[twi_para] +twi_port = 0 +twi_scl = port:PB0021defaultdefault +twi_sda = port:PB0121defaultdefault + +[uart_para] +uart_debug_port = 0 +uart_debug_tx = port:PG0341defaultdefault +uart_debug_rx = port:PG0441defaultdefault + +[jtag_para] +jtag_enable = 0 +jtag_ms = port:PF0041defaultdefault +jtag_ck = port:PF0541defaultdefault +jtag_do = port:PF0341defaultdefault +jtag_di = port:PF0141defaultdefault + +[dram_para] +dram_baseaddr = 0x4000 +dram_clk = 408 +dram_type = 3 +dram_rank_num = 1 +dram_chip_density = 2048 +dram_io_width = 8 +dram_bus_width = 16 +dram_cas = 9 +dram_zq = 0x7b +dram_odt_en = 0 +dram_size = 512 +dram_tpr0 = 0x42d899b7 +dram_tpr1 = 0xa090 +dram_tpr2 = 0x22a00 +dram_tpr3 = 0x0 +dram_tpr4 = 0x0 +dram_tpr5 = 0x0 +dram_emr1 = 0x4 +dram_emr2 = 0x10 +dram_emr3 = 0x0 + +[nand_para] +nand_used = 1 +nand_we = port:PC002defaultdefaultdefault +nand_ale = port:PC012defaultdefaultdefault +nand_cle = port:PC022defaultdefaultdefault +nand_ce1 = port:PC032defaultdefaultdefault +nand_ce0 = port:PC042defaultdefaultdefault +nand_nre = port:PC052defaultdefaultdefault +nand_rb0 = port:PC062defaultdefaultdefault +nand_rb1 = port:PC072defaultdefaultdefault +nand_d0 = port:PC082defaultdefaultdefault +nand_d1 = port:PC092defaultdefaultdefault +nand_d2 = port:PC102defaultdefaultdefault +nand_d3 = port:PC112defaultdefaultdefault +nand_d4 = port:PC122defaultdefaultdefault +nand_d5 = port:PC132defaultdefaultdefault +nand_d6 = port:PC142defaultdefaultdefault +nand_d7 = port:PC152defaultdefaultdefault +nand_wp = +nand_ce2 = +nand_ce3 = +nand_ce4 = +nand_ce5 = +nand_ce6 = +nand_ce7 = +nand_spi = +nand_ndqs = port:PC192defaultdefaultdefault +good_block_ratio = 0 + +[mali_para] +mali_used = 1 +mali_clkdiv = 2 + +[twi0_para] +twi0_used = 1 +twi0_scl = port:PB002defaultdefaultdefault +twi0_sda = port:PB012defaultdefaultdefault + +[twi1_para] +twi1_used = 1 +twi1_scl = port:PB152defaultdefaultdefault +twi1_sda = port:PB162defaultdefaultdefault + +[twi2_para] +twi2_used = 1 +twi2_scl = port:PB172defaultdefaultdefault +twi2_sda = port:PB182defaultdefaultdefault + +[uart_para0] +uart_used = 0 +uart_port = 0 +uart_type = 2 +uart_tx = port:PB1921defaultdefault +uart_rx = port:PB2021defaultdefault + +[uart_para1] +uart_used = 0 +uart_port = 1 +uart_type = 2 +uart_tx = port:PG0341defaultdefault +uart_rx = port:PG0441defaultdefault + +[spi1_para] +spi_used = 0 +spi_cs0 = port:PG092defaultdefaultdefault +spi_cs1 = port:PG132defaultdefaultdefault +spi_sclk = port:PG102defaultdefaultdefault +spi_mosi = port:PG112defaultdefaultdefault +spi_miso = port:PG122defaultdefaultdefault + +[spi2_para] +spi_used = 0 +spi_cs0 = port:PE004defaultdefaultdefault +spi_sclk = port:PE014defaultdefaultdefault +spi_mosi = port:PB024defaultdefaultdefault +spi_miso = port:PB034defaultdefaultdefault + +[rtp_para] +rtp_used = 0 +rtp_screen_size = 5 +rtp_regidity_level = 5 +rtp_press_threshold_enable = 0 +rtp_press_threshold = 0x1f40 +rtp_sensitive_level = 0xf +rtp_exchange_x_y_flag = 0 + +[ctp_para] +ctp_boxchip_type = 2579 +ctp_cob = 1 +ctp_twi_id = 1 +ctp0_used = 1 +ctp0_name = ft5x02 +ctp0_twi_addr = 56 +ctp1_used = 0 +ctp1_name = Goodix-TS +ctp1_twi_addr = 85 +ctp2_used = 1 +ctp2_name = ssd253x-ts +ctp2_twi_addr = 72 +ctp2_ssd_type = 75801 +ctp4_used = 1 +ctp4_name = zet622x-ts +ctp4_twi_addr = 118 +ctp5_used = 1 +ctp5_name = byd693x-ts +ctp5_twi_addr = 82 +ctp8_used = 0 +ctp8_name = gt82x +ctp8_twi_addr = 93 +ctp9_used = 1 +ctp9_name = gt811 +ctp9_twi_addr = 93 +ctp10_used = 1 +ctp10_name = pixcir_cxx +ctp10_twi_addr = 92 +ctp12_used = 1 +ctp12_name = gslx680 +ctp12_twi_addr = 64 +ctp12_gsl_type = 8602 +ctp13_used = 1 +ctp13_name = sitronix_ts +ctp13_twi_addr = 96 +ctp19_used = 1 +ctp19_name = elan_ts +ctp19_twi_addr = 20 +ctp_screen_max_x = 800 +ctp_screen_max_y = 480 +ctp_revert_x_flag = 0 +ctp_revert_y_flag = 0 +ctp_exchange_x_y_flag = 0 +ctp_int_port = port:PG116defaultdefaultdefault +ctp_wakeup = port:PB031defaultdefault1 +ctp_io_port =
[linux-sunxi] [sunxi-boards 4/5] Update a86v4 fex with paramaters read from meminfo.
Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/a86v4.fex |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/sys_config/a13/a86v4.fex b/sys_config/a13/a86v4.fex index 618e5d9..43fade3 100644 --- a/sys_config/a13/a86v4.fex +++ b/sys_config/a13/a86v4.fex @@ -59,19 +59,16 @@ dram_baseaddr = 0x4000 dram_clk = 408 dram_type = 3 dram_rank_num = 1 -dram_chip_density = 2048 -dram_io_width = 8 +dram_chip_density = 4096 +dram_io_width = 16 dram_bus_width = 16 dram_cas = 9 dram_zq = 0x7b dram_odt_en = 0 -dram_size = 512 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 -dram_tpr4 = 0x0 -dram_tpr5 = 0x0 dram_emr1 = 0x0 dram_emr2 = 0x10 dram_emr3 = 0x0 -- 1.7.10.4 -- 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] [sunxi-boards 3/5] Add a86v4 original fex from Prestigio PMP370B (black).
Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/a86v4.fex | 626 ++ 1 file changed, 626 insertions(+) create mode 100644 sys_config/a13/a86v4.fex diff --git a/sys_config/a13/a86v4.fex b/sys_config/a13/a86v4.fex new file mode 100644 index 000..618e5d9 --- /dev/null +++ b/sys_config/a13/a86v4.fex @@ -0,0 +1,626 @@ +[product] +version = 1.0 +machine = A13-EVB-V1.0 + +[target] +boot_clock = 1008 +dcdc2_vol = 1400 +dcdc3_vol = 1200 +ldo2_vol = 3000 +ldo3_vol = 3300 +ldo4_vol = 3300 +pll4_freq = 960 +pll6_freq = 720 +power_start = 0 +storage_type = 0 + +[card_boot] +logical_start = 40960 +sprite_gpio0 = + +[pm_para] +standby_mode = 0 + +[card_boot0_para] +card_ctrl = 0 +card_high_speed = 1 +card_line = 4 +sdc_d1 = port:PF0021defaultdefault +sdc_d0 = port:PF0121defaultdefault +sdc_clk = port:PF0221defaultdefault +sdc_cmd = port:PF0321defaultdefault +sdc_d3 = port:PF0421defaultdefault +sdc_d2 = port:PF0521defaultdefault + +[twi_para] +twi_port = 0 +twi_scl = port:PB0021defaultdefault +twi_sda = port:PB0121defaultdefault + +[uart_para] +uart_debug_port = 0 +uart_debug_tx = +uart_debug_rx = + +[uart_force_debug] +uart_debug_port = 0 +uart_debug_tx = port:PF024defaultdefaultdefault +uart_debug_rx = port:PF044defaultdefaultdefault + +[jtag_para] +jtag_enable = 0 +jtag_ms = port:PF0041defaultdefault +jtag_ck = port:PF0541defaultdefault +jtag_do = port:PF0341defaultdefault +jtag_di = port:PF0141defaultdefault + +[dram_para] +dram_baseaddr = 0x4000 +dram_clk = 408 +dram_type = 3 +dram_rank_num = 1 +dram_chip_density = 2048 +dram_io_width = 8 +dram_bus_width = 16 +dram_cas = 9 +dram_zq = 0x7b +dram_odt_en = 0 +dram_size = 512 +dram_tpr0 = 0x42d899b7 +dram_tpr1 = 0xa090 +dram_tpr2 = 0x22a00 +dram_tpr3 = 0x0 +dram_tpr4 = 0x0 +dram_tpr5 = 0x0 +dram_emr1 = 0x0 +dram_emr2 = 0x10 +dram_emr3 = 0x0 + +[nand_para] +nand_used = 1 +nand_we = port:PC002defaultdefaultdefault +nand_ale = port:PC012defaultdefaultdefault +nand_cle = port:PC022defaultdefaultdefault +nand_ce1 = port:PC032defaultdefaultdefault +nand_ce0 = port:PC042defaultdefaultdefault +nand_nre = port:PC052defaultdefaultdefault +nand_rb0 = port:PC062defaultdefaultdefault +nand_rb1 = port:PC072defaultdefaultdefault +nand_d0 = port:PC082defaultdefaultdefault +nand_d1 = port:PC092defaultdefaultdefault +nand_d2 = port:PC102defaultdefaultdefault +nand_d3 = port:PC112defaultdefaultdefault +nand_d4 = port:PC122defaultdefaultdefault +nand_d5 = port:PC132defaultdefaultdefault +nand_d6 = port:PC142defaultdefaultdefault +nand_d7 = port:PC152defaultdefaultdefault +nand_wp = +nand_ce2 = +nand_ce3 = +nand_ce4 = +nand_ce5 = +nand_ce6 = +nand_ce7 = +nand_spi = +nand_ndqs = port:PC192defaultdefaultdefault +good_block_ratio = 0 + +[mali_para] +mali_used = 1 +mali_clkdiv = 2 + +[twi0_para] +twi0_used = 1 +twi0_scl = port:PB002defaultdefaultdefault +twi0_sda = port:PB012defaultdefaultdefault + +[twi1_para] +twi1_used = 1 +twi1_scl = port:PB152defaultdefaultdefault +twi1_sda = port:PB162defaultdefaultdefault + +[twi2_para] +twi2_used = 1 +twi2_scl = port:PB172defaultdefaultdefault +twi2_sda = port:PB182defaultdefaultdefault + +[uart_para0] +uart_used = 0 +uart_port = 0 +uart_type = 2 +uart_tx = port:PB1921defaultdefault +uart_rx = port:PB2021defaultdefault + +[uart_para1] +uart_used = 0 +uart_port = 1 +uart_type = 2 +uart_tx = +uart_rx = + +[spi1_para] +spi_used = 0 +spi_cs0 = port:PG092defaultdefaultdefault +spi_cs1 = port:PG132defaultdefaultdefault +spi_sclk = port:PG102defaultdefaultdefault +spi_mosi = port:PG112defaultdefaultdefault +spi_miso = port:PG122defaultdefaultdefault + +[spi2_para] +spi_used = 0 +spi_cs0 = port:PE004defaultdefaultdefault +spi_sclk = port:PE014defaultdefaultdefault +spi_mosi = port:PB024defaultdefaultdefault +spi_miso = port:PB034defaultdefaultdefault + +[rtp_para] +rtp_used = 0 +rtp_screen_size = 5 +rtp_regidity_level = 5 +rtp_press_threshold_enable = 0 +rtp_press_threshold = 0x1f40 +rtp_sensitive_level = 0xf +rtp_exchange_x_y_flag = 0 + +[ctp_para] +ctp_used = 1 +ctp_twi_id = 1 +ctp_screen_max_x = 800 +ctp_screen_max_y = 480 +ctp_revert_x_flag = 0 +ctp_revert_y_flag = 0 +ctp_exchange_x_y_flag = 0 +ctp_int_port = port:PG116defaultdefaultdefault +ctp_wakeup = port:PB031defaultdefault1 +ctp_io_port = port:PG110defaultdefaultdefault + +[tkey_para] +tkey_used = 0 +tkey_name = hv_keypad +tkey_twi_id = 2 +tkey_twi_addr = 0x62 +tkey_int = + +[motor_para] +motor_used = 0 +motor_shake = + +[disp_init] +disp_init_enable = 1 +disp_mode = 0 +screen0_output_type = 1 +screen0_output_mode = 5 +screen1_output_type = 1 +screen1_output_mode = 5 +fb0_framebuffer_num = 2 +fb0_format = 10 +fb0_pixel_sequence = 0 +fb0_scaler_mode_enable = 0 +fb1_framebuffer_num = 2 +fb1_format = 10 +fb1_pixel_sequence = 0 +fb1_scaler_mode_enable = 0 + +[lcd0_para] +lcd_used = 1 +lcd_x = 800 +lcd_y = 480 +lcd_dclk_freq = 30 +lcd_pwm_not_used = 0 +lcd_pwm_ch = 0 +lcd_pwm_freq = 5000 +lcd_pwm_pol = 1 +lcd_if = 0 +lcd_hbp = 46
[linux-sunxi] Differences between Allwinner's u-boot and kernel and uboot-sunxi/linux-sunxi on sun7i
I tried to use kexec to boot kernel. Kexec from sdk/stock kernel works only with sdk kernels, kexec from linux-sunxi kernel works only with sunxi. sdk' kernel is unuseful because g2d API is broken, usb sometimes crashes (NPD somewhere in usb code). -- 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] Differences between Allwinner's u-boot and kernel and uboot-sunxi/linux-sunxi on sun7i
tis 2014-09-09 klockan 11:01 -0700 skrev Toroshin Dmitry: I tried to use kexec to boot kernel. Kexec from sdk/stock kernel works only with sdk kernels, kexec from linux-sunxi kernel works only with sunxi. sdk' kernel is unuseful because g2d API is broken, usb sometimes crashes (NPD somewhere in usb code). This is likely because the two uses different machid values, where the SDK kernels are using an unofficial randomly picked value, where linux-sunxi uses the officially registered machid values. Regards Henrik -- 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] [sunxi-boards v2 2/4] Update iNet 86VS fex with a10-meminfo output.
Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/inet_86vs.fex |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/sys_config/a13/inet_86vs.fex b/sys_config/a13/inet_86vs.fex index f1c224f..b2a04c2 100644 --- a/sys_config/a13/inet_86vs.fex +++ b/sys_config/a13/inet_86vs.fex @@ -54,19 +54,17 @@ dram_baseaddr = 0x4000 dram_clk = 408 dram_type = 3 dram_rank_num = 1 -dram_chip_density = 2048 -dram_io_width = 8 +dram_chip_density = 4096 +dram_io_width = 16 dram_bus_width = 16 dram_cas = 9 -dram_zq = 0x7b +dram_zq = 0x56b9697b dram_odt_en = 0 dram_size = 512 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 -dram_tpr4 = 0x0 -dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 -- 1.7.10.4 -- 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] [sunxi-boards v2 3/4] Update A86 V4.0 Prestigio PMP370B fex with paramaters read from meminfo.
Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/prestigio_pmp3670b.fex |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/sys_config/a13/prestigio_pmp3670b.fex b/sys_config/a13/prestigio_pmp3670b.fex index 59e8ec2..e024d2d 100644 --- a/sys_config/a13/prestigio_pmp3670b.fex +++ b/sys_config/a13/prestigio_pmp3670b.fex @@ -59,19 +59,16 @@ dram_baseaddr = 0x4000 dram_clk = 408 dram_type = 3 dram_rank_num = 1 -dram_chip_density = 2048 -dram_io_width = 8 +dram_chip_density = 4096 +dram_io_width = 16 dram_bus_width = 16 dram_cas = 9 dram_zq = 0x7b dram_odt_en = 0 -dram_size = 512 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 -dram_tpr4 = 0x0 -dram_tpr5 = 0x0 dram_emr1 = 0x0 dram_emr2 = 0x10 dram_emr3 = 0x0 -- 1.7.10.4 -- 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] [sunxi-boards v2 0/4] A13 tablet fex files
Fex files which should provide basic functionalit on Prestigio PMP370B and iNet 86VS. V2 Rebased on top of the existing PMP370B fex file. Thanks Michal Michal Suchanek (4): Original fex file from iNet technology 86VS (Manta MID705). Update iNet 86VS fex with a10-meminfo output. Update A86 V4.0 Prestigio PMP370B fex with paramaters read from meminfo. Fix broken keys and uarts on PMP370B and iNet 86VS sys_config/a13/inet_86vs.fex | 745 + sys_config/a13/prestigio_pmp3670b.fex | 21 +- 2 files changed, 761 insertions(+), 5 deletions(-) create mode 100644 sys_config/a13/inet_86vs.fex -- 1.7.10.4 -- 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] [sunxi-boards v2 4/4] Fix broken keys and uarts on PMP370B and iNet 86VS
Kernel wants an uart3 serction otherwise whines. Keys should be explicitly enabled and mapped as appropriate. USB should be enabled by default because it is not detected otherwise. Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/inet_86vs.fex | 14 +- sys_config/a13/prestigio_pmp3670b.fex | 14 ++ 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/sys_config/a13/inet_86vs.fex b/sys_config/a13/inet_86vs.fex index b2a04c2..6cdfaff 100644 --- a/sys_config/a13/inet_86vs.fex +++ b/sys_config/a13/inet_86vs.fex @@ -131,6 +131,13 @@ uart_type = 2 uart_tx = port:PG0341defaultdefault uart_rx = port:PG0441defaultdefault +[uart_para3] +uart_used = 0 +uart_port = 3 +uart_type = 2 +uart_tx = port:PG0341defaultdefault +uart_rx = port:PG0441defaultdefault + [spi1_para] spi_used = 0 spi_cs0 = port:PG092defaultdefaultdefault @@ -203,6 +210,9 @@ ctp_int_port = port:PG116defaultdefaultdefault ctp_wakeup = port:PB031defaultdefault1 ctp_io_port = port:PG116defaultdefaultdefault +[tabletkeys_para] +tabletkeys_used=1 + [tkey_para] tkey_used = 0 tkey_name = hv_keypad @@ -512,7 +522,9 @@ usb_controller_type = 1 usb_id_gpio = usb_det_vbus_gpio = usb_drv_vbus_gpio = port:PG1110default0 -usb_host_init_state = 0 +; set usb_host_init_state to 0 to not enable USB controller until a sunxi-specific USB WiFi driver is loaded +; saves power if you do not use WiFi +usb_host_init_state = 1 [port_pm] restrict_1a = 0 diff --git a/sys_config/a13/prestigio_pmp3670b.fex b/sys_config/a13/prestigio_pmp3670b.fex index e024d2d..8ffa9e0 100644 --- a/sys_config/a13/prestigio_pmp3670b.fex +++ b/sys_config/a13/prestigio_pmp3670b.fex @@ -135,6 +135,13 @@ uart_type = 2 uart_tx = uart_rx = +[uart_para3] +uart_used = 0 +uart_port = 1 +uart_type = 4 +uart_tx = +uart_rx = + [spi1_para] spi_used = 0 spi_cs0 = port:PG092defaultdefaultdefault @@ -178,6 +185,11 @@ tkey_twi_id = 2 tkey_twi_addr = 0x62 tkey_int = +[tabletkeys_para] +tabletkeys_used = 1 +key0_code = 114 +key1_code = 115 + [motor_para] motor_used = 0 motor_shake = @@ -413,6 +425,8 @@ usb_controller_type = 0 usb_id_gpio = usb_det_vbus_gpio = usb_drv_vbus_gpio = port:power2031defaultdefault0 +; set usb_host_init_state to 0 to not enable USB controller until a sunxi-specific USB WiFi driver is loaded +; saves power if you do not use WiFi usb_host_init_state = 1 [port_pm] -- 1.7.10.4 -- 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.
