Re: [linux-sunxi] [PATCH] Mainline U-boot -- Tristan Auron Planet 1 tablet
On Sat, Jan 10, 2015 at 12:15:42AM +0100, Luc Verhaegen wrote: On Fri, Jan 09, 2015 at 05:33:17PM +0100, Lars Doelle wrote: This patch adds settings for yet another A20 tablet. To reduce the various dram settings, dram_sun7i_384_1024_iow16 has been used. This changes the .trp4 register from 3 to 0 and lets the device run somewhat underclocked. No device tree settings have been created for the device, yet. This is an Inet K970??, and like all inet devices this is very often rebadged. As described in the wiki page, please fire up android, and find out the last 1-2 letters, which usually are tied to a given display size and wifi module, and use this name everywhere instead. Luc Verhaegen. cfr http://linux-sunxi.org/Inet_K970 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] [PATCH] Mainline U-boot -- Tristan Auron Planet 1 tablet
On Fri, Jan 09, 2015 at 05:33:17PM +0100, Lars Doelle wrote: This patch adds settings for yet another A20 tablet. To reduce the various dram settings, dram_sun7i_384_1024_iow16 has been used. This changes the .trp4 register from 3 to 0 and lets the device run somewhat underclocked. No device tree settings have been created for the device, yet. This is an Inet K970??, and like all inet devices this is very often rebadged. As described in the wiki page, please fire up android, and find out the last 1-2 letters, which usually are tied to a given display size and wifi module, and use this name everywhere instead. 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: Infrared Remote Control (sunxi-ir)
I think the current sunxi-ir driver only decodes the NEC protocol. In my case I have one of the dual core android tv player device similar to: http://linux-sunxi.org/YBKJ_A20 I have made a debian linux sd card using the 3.4 sunxi kernel and I had success reading the original remote that came with the box and also various cheap remotes usually found in car players. See for instance the remote from here: http://docs.cubieboard.org/tutorials/cb1/customization/wireless_music_box If the driver is loaded properly you should be able to find an eventX link for it in /dev/input/eventX where X varies but it should be similar to what you had in the dmesg log. A simple test to see if you have any keys recognized you could run: cat /dev/input/eventX | hexdump and start pressing keys from your remote. If you do not get any output then either your remote is not using the NEC protocol or the decoder might be listening on the wrong pins. I saw you have ir0_rx = port:PB042defaultdefaultdefault in your script.fex file but have you actually converted that file to a binary one and made it available so that the U-boot loader can load it? Again, in my case, I needed the script.bin file generated for my debian build as mentioned in here: http://linux-sunxi.org/Manual_build_howto All the best, tkg -- 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: Mainline work status
On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: Hi, On Tue, Jan 6, 2015 at 12:15 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Chen-Yu, On Wed, Dec 24, 2014 at 11:29:26PM +0800, wens Tsai wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. Thanks for your amazing work. The following is a list of things I'm working on or waiting to submit: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 - AXP20x regulator driver cleanup, finished and tested What is left to be posted, besides the DT bits? This is actually getting rid of the DT parsing code in the regulator driver, and using common code in the regulator core added in 3.19-rc1. So this is new. Oh, cool. - AXP221 support, originally by Boris, finished and tested * Also enables WiFi on the Hummingbird A31 There was some discussion since for some board (maybe the APP4) we had some circular dependency between the regulators exposed by the PMIC. Has that been taken care of? The work Boris has done on that doesn't mesh well with the previous item. What previous items? The DT parsing code removal? For now I've dropped that bit. The dependency is ELDOs are powered from DCDC1, which is a fairly simple dependency. I think we can get around it by registering the DCDC ones first. The thing is that this dependency is pretty much dependant on the board. We could really well have other combinations on different boards, that we wouldn't be able to solve. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Did you test individual OPPs or global ones (ie per-board or per-SoC)? Eventually, I'd like to have per-SoC OPPs. It doesn't seem that undoable from the spreadsheet I shared with you. I've tested per-SoC OPPs with the boards I have using the hardware reliability test on the wiki [1]. Doing per-board OPPs should be as simple as overriding the OPP table in the board dts. As I will state in the series cover letter, for sun[457]i the OPPs are the same or very similar. Nice. For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. 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] Re: Mainline work status
Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? 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.
[linux-sunxi] Re: Mainline work status
On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. 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] Re: Mainline work status
Hi, On 09-01-15 10:37, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. True (wrt side-effects), but having the OPPs defined in code, rather then in the dts seems wrong to me. Maybe for sun6i we need to define the OPPs in a separate dt-node (one per revision) and have mach-sunxi populate the cpu node with the OPPs for the right revision ? 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.
[linux-sunxi] Re: Mainline work status
On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. 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] Re: Sunxi FOSDEM2015 Dinner!
On Fri, Jan 9, 2015 at 10:28 AM, TsvetanUsunov tsvetanusu...@gmail.com wrote: +2 for Olimex I will be there as well. @Oliver congratulations for the Cubieboard book at Packt! Same place as last year or you want to go somewhere else? -- Benjamin Henrion bhenrion at ffii.org FFII Brussels - +32-484-566109 - +32-2-4148403 In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators. -- 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: Mainline work status
On Fri, Jan 9, 2015 at 4:30 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: Hi, On Tue, Jan 6, 2015 at 12:15 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Chen-Yu, On Wed, Dec 24, 2014 at 11:29:26PM +0800, wens Tsai wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. Thanks for your amazing work. The following is a list of things I'm working on or waiting to submit: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 - AXP20x regulator driver cleanup, finished and tested What is left to be posted, besides the DT bits? This is actually getting rid of the DT parsing code in the regulator driver, and using common code in the regulator core added in 3.19-rc1. So this is new. Oh, cool. - AXP221 support, originally by Boris, finished and tested * Also enables WiFi on the Hummingbird A31 There was some discussion since for some board (maybe the APP4) we had some circular dependency between the regulators exposed by the PMIC. Has that been taken care of? The work Boris has done on that doesn't mesh well with the previous item. What previous items? The DT parsing code removal? Yes. For now I've dropped that bit. The dependency is ELDOs are powered from DCDC1, which is a fairly simple dependency. I think we can get around it by registering the DCDC ones first. The thing is that this dependency is pretty much dependant on the board. We could really well have other combinations on different boards, that we wouldn't be able to solve. I doubt anyone sane would chain DCDC regulators or LDO regulators, like DCDC1 - DCDC2-in, or ALDO1 - ELDO-in. It doesn't make sense from an efficiency standpoint. And you'll likely be further limited by how much current the parent regulator can drive. A more likely scenario would be DCDC - some external regulator - xLDO. I don't think the regulator_set stuff solves this either. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Did you test individual OPPs or global ones (ie per-board or per-SoC)? Eventually, I'd like to have per-SoC OPPs. It doesn't seem that undoable from the spreadsheet I shared with you. I've tested per-SoC OPPs with the boards I have using the hardware reliability test on the wiki [1]. Doing per-board OPPs should be as simple as overriding the OPP table in the board dts. As I will state in the series cover letter, for sun[457]i the OPPs are the same or very similar. Nice. For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Sounds good. This becomes rather simple then. Just need to get the AXP221 patches merged first. I hope that the voltage tolerance levels on the hypothetical version D is high enough so that we don't ruin anyone's board though. ChenYu -- 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: Mainline work status
Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? 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.
[linux-sunxi] Re: Sunxi FOSDEM2015 Dinner!
+2 for Olimex сряда, 7 януари 2015 г., 17:30:50 UTC+2, Olliver Schinagl написа: Hey guys, with FOSDEM 2015 approaching rapidly again, I was wondering if there is anything organized again this year? If not, Who's up for it? :) I will be attending FOSDEM and will have a stand for saturday/sunday for my work (Ultimaker). So Saturday evening sounds perfect for such an event! So who's up for it? (And if something is already taking shape, count me in!) Olliver -- 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] AllWinner processor with integrated LTE?
On Tue, Jan 6, 2015 at 11:25 AM, bruce bushby bruce.bus...@gmail.com wrote: I wanted to ask whether anyone knows if AllWinner will release a processor with integrated LTE? Preferably integrated LTE, WiFi BT 4.0 As far as I know, there have not been any Allwinner SoCs with GSM/3G/LTE support (integrated in the SoC). For GSM/3G/LTE integrated in the SoC, you would probably go for MediaTek SoCs. Simos -- 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: Mainline work status
On Fri, Jan 9, 2015 at 5:47 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 09-01-15 10:37, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. True (wrt side-effects), but having the OPPs defined in code, rather then in the dts seems wrong to me. Maybe for sun6i we need to define the OPPs in a separate dt-node (one per revision) and have mach-sunxi populate the cpu node with the OPPs for the right revision ? That was kind of what I had in mind when I started. May need some changes to cpufreq-dt driver. It currently loads OPPs from the default bindings unconditionally. Not sure if changing this would break anyone else. ChenYu -- 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: Mainline work status
Hi, On 09-01-15 10:53, wens Tsai wrote: On Fri, Jan 9, 2015 at 5:47 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 09-01-15 10:37, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. True (wrt side-effects), but having the OPPs defined in code, rather then in the dts seems wrong to me. Maybe for sun6i we need to define the OPPs in a separate dt-node (one per revision) and have mach-sunxi populate the cpu node with the OPPs for the right revision ? That was kind of what I had in mind when I started. May need some changes to cpufreq-dt driver. It currently loads OPPs from the default bindings unconditionally. Not sure if changing this would break anyone else. If we move/copy the right OPPs over to the cpu dt node (so we do runtime devicetree mangling) before the cpufreq driver loads there should be no need for changes to the cpufreq-dt driver. 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.
[linux-sunxi] mainline NAND+MMC device tree kernel panic
Can you help me understand this strange bug on a10s-olinuxino-m? I guess my
DT record for NAND MTD partitions is somehow incorrect because I happen to
get a kernel panic in the mainline 3.19 kernel that looks like this:
[0.599782] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde
[0.606203] nand: Hynix H27UCG8T2ETR-BC 8GiB 3.3V 8-bit
[0.611433] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size: 16384,
OOB size: 1664
[0.628428] Bad block table found at page 524032, version 0x01
[0.650299] Bad block table found at page 523776, version 0x01
[0.664100] nand_bbt: ECC error in BBT at 0xffc5
[0.677393] nand_bbt: ECC error in BBT at 0xff85
[0.682711] Scanning device for bad blocks
[1.086137] random: nonblocking pool is initialized
[1.769233] Bad eraseblock 1992 at 0x0001f23fc000
[1.814688] Bad block table written to 0x0001ffc0, version 0x01
[1.832192] Bad block table written to 0x0001ff80, version 0x01
[1.839592] 4 ofpart partitions found on MTD device H27UCG8T2ETR-BC 8GiB
3.3V 8-bit
[1.847297] Creating 4 MTD partitions on H27UCG8T2ETR-BC 8GiB 3.3V
8-bit:
[1.854275] 0x-0x0040 : boot0
[1.859622] 0x0040-0x0080 : boot1
[1.864877] 0x0080-0x0180 : kernel
[1.870197] 0x0180-0x0002 : rootfs
...snip...
[2.124638] Registering SWP/SWPB emulation handler
[2.129842] Unable to handle kernel NULL pointer dereference at virtual
address 0713
SWP/SWPB instruction emulation has nothing to do with the NFC. The kernel
boots OK as soon as I disable the NFC in the device tree. In a successful
boot attempt, this is followed by mmc0 initialisation. So, it looks like
the culprit is mmc0. However, disabling the leaf mmc nodes in the device
tree does not change the outcome.
Here is my nfc configuration added to the mainline
sunxi-a10s-olinuxino-micro.dts. The pinctrl-0 definitions are standard,
same as in Boris' repo for Cubietruck.
nfc: nand@01c03000 { compatible = allwinner,sun4i-a10-nand; reg =
0x01c03000 0x1000; interrupts = 37; clocks = ahb_gates 13,
nand_clk; clock-names = ahb, mod; #address-cells = 1; #size-cells
= 0; pinctrl-names = default; pinctrl-0 = nand_pins_a
nand_cs0_pins_a nand_rb0_pins_a; status = okay; nand@0 { reg = 0;
allwinner,rb = 0; #address-cells = 1; #size-cells = 2;
nand-on-flash-bbt; nand-ecc-mode = hw; boot0@0 { label = boot0; reg =
0x0 0x0 0x40; }; boot1@40 { label = boot1; reg = 0x40 0x0
0x40; }; kernel@80 { label = kernel; reg = 0x80 0x0
0x100; }; rootfs@180 { label = rootfs; reg = 0x180 0x1
0xfe80; }; }; };
--Vladimir
--
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] [PATCH] Mainline U-boot -- Tristan Auron Planet 1 tablet
This patch adds settings for yet another A20 tablet. To reduce the various dram settings, dram_sun7i_384_1024_iow16 has been used. This changes the .trp4 register from 3 to 0 and lets the device run somewhat underclocked. No device tree settings have been created for the device, yet. --- board/sunxi/Kconfig | 8 board/sunxi/MAINTAINERS | 5 + board/sunxi/Makefile | 1 + configs/Tristan_Auron_Planet_1_defconfig | 10 ++ 4 files changed, 24 insertions(+) create mode 100644 configs/Tristan_Auron_Planet_1_defconfig diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 1d47cb7..d21bec2 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -195,6 +195,14 @@ config TARGET_QT840A bool QT840A depends on MACH_SUN7I +config TARGET_TRISTAN_AURON_PLANET_1 +bool Tristan Auron Planet 1 (9.7\ tablet) +depends on MACH_SUN7I +---help--- +The Tristan Auron Planet 1 is an A20 based tablet. +For a detailed description of the device see +http://linux-sunxi.org/Tristan_Auron_Planet_1 + config TARGET_R7DONGLE bool R7DONGLE depends on MACH_SUN5I diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index d880b63..f02f323 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -54,6 +54,11 @@ S: Maintained F: board/sunxi/dram_a20_olinuxino_l2.c F: configs/A20-OLinuXino-Lime2_defconfig +TRISTAN_AURON_PLANET_1 BOARD +M: Lars Dölle lars-doe...@on-line.de +S: Maintained +F: configs/Tristan_Auron_Planet_1_defconfig + COLOMBUS BOARD M: Maxime Ripard maxime.rip...@free-electrons.com S: Maintained diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile index 805d8c9..eb37a9f 100644 --- a/board/sunxi/Makefile +++ b/board/sunxi/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o obj-$(CONFIG_TARGET_MINI_X)+= dram_sun4i_360_512.o obj-$(CONFIG_TARGET_MINI_X_1GB)+= dram_sun4i_360_1024_iow16.o obj-$(CONFIG_TARGET_MSI_PRIMO73) += dram_sun7i_384_1024_iow16.o +obj-$(CONFIG_TARGET_TRISTAN_AURON_PLANET_1)+= dram_sun7i_384_1024_iow16.o obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o obj-$(CONFIG_TARGET_QT840A)+= dram_sun7i_384_512_busw16_iow16.o obj-$(CONFIG_TARGET_R7DONGLE) += dram_r7dongle.o diff --git a/configs/Tristan_Auron_Planet_1_defconfig b/configs/Tristan_Auron_Planet_1_defconfig new file mode 100644 index 000..138be6c --- /dev/null +++ b/configs/Tristan_Auron_Planet_1_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,USB_EHCI +CONFIG_VIDEO_LCD_MODE=x:1024,y:768,depth:18,pclk_khz:65000,le:120,ri:180,up:22,lo:13,hs:20,vs:3,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_TARGET_TRISTAN_AURON_PLANET_1=y -- 2.1.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.
Re: [linux-sunxi] Sunxi FOSDEM2015 Dinner!
On Wed, 2015-01-07 at 16:30 +0100, Olliver Schinagl wrote: Hey guys, with FOSDEM 2015 approaching rapidly again, I was wondering if there is anything organized again this year? If not, Who's up for it? :) I will be attending FOSDEM and will have a stand for saturday/sunday for my work (Ultimaker). So Saturday evening sounds perfect for such an event! So who's up for it? (And if something is already taking shape, count me in!) I'd like to come but I don't know yet if I'll have work commitments on the Saturday evening, how near the time would be too late to let you know? Ian. -- 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/1] sunxi: add Linksprite pcDuino v1/v2 support
Hi,
On 06-01-15 01:09, Zoltan HERPAI wrote:
Add support for a sun4i board built by Linksprite. This addition covers
both v1 and v2 versions. As the board has been working with 408MHz memory
setting in the u-boot-sunxi branch, and has been proven to be running stable
during my tests as well, a respective new DRAM config file is added as well.
Signed-off-by: Zoltan HERPAI wigy...@uid0.hu
Thanks, I've queued this up in u-boot-sunxi for when the merge window opens.
Regards,
Hans
---
board/sunxi/Kconfig|4
board/sunxi/Makefile |1 +
board/sunxi/dram_sun4i_408_1024_iow8.c | 31 +++
configs/Linksprite_pcDuino_defconfig |7 +++
4 files changed, 43 insertions(+)
create mode 100644 board/sunxi/dram_sun4i_408_1024_iow8.c
create mode 100644 configs/Linksprite_pcDuino_defconfig
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 246cd9a..ccf583f 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -99,6 +99,10 @@ config TARGET_IPPO_Q8H_V5
bool IPPO_Q8H_V5
depends on MACH_SUN8I
+config TARGET_PCDUINO
+ bool PCDUINO
+ depends on MACH_SUN4I
+
config TARGET_PCDUINO3
bool PCDUINO3
depends on MACH_SUN7I
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index b84ff9b..c947b09 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_TARGET_MELE_A1000G) +=
dram_sun4i_360_1024_iow8.o
obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
obj-$(CONFIG_TARGET_MINI_X) += dram_sun4i_360_512.o
obj-$(CONFIG_TARGET_MINI_X_1GB) += dram_sun4i_360_1024_iow16.o
+obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_408_1024_iow8.o
obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o
obj-$(CONFIG_TARGET_QT840A) += dram_sun7i_384_512_busw16_iow16.o
obj-$(CONFIG_TARGET_R7DONGLE) += dram_r7dongle.o
diff --git a/board/sunxi/dram_sun4i_408_1024_iow8.c
b/board/sunxi/dram_sun4i_408_1024_iow8.c
new file mode 100644
index 000..c6d87d2
--- /dev/null
+++ b/board/sunxi/dram_sun4i_408_1024_iow8.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+ .clock = 408,
+ .type = 3,
+ .rank_num = 1,
+ .density = 2048,
+ .io_width = 8,
+ .bus_width = 32,
+ .cas = 6,
+ .zq = 123,
+ .odt_en = 0,
+ .size = 1024,
+ .tpr0 = 0x30926692,
+ .tpr1 = 0x1090,
+ .tpr2 = 0x1a0c8,
+ .tpr3 = 0,
+ .tpr4 = 0,
+ .tpr5 = 0,
+ .emr1 = 0,
+ .emr2 = 0,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(dram_para);
+}
diff --git a/configs/Linksprite_pcDuino_defconfig
b/configs/Linksprite_pcDuino_defconfig
new file mode 100644
index 000..f5b0ca9
--- /dev/null
+++ b/configs/Linksprite_pcDuino_defconfig
@@ -0,0 +1,7 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_EMAC,USB_EHCI
+CONFIG_FDTFILE=sun4i-a10-pcduino.dtb
++S:CONFIG_ARM=y
++S:CONFIG_ARCH_SUNXI=y
++S:CONFIG_MACH_SUN4I=y
++S:CONFIG_TARGET_PCDUINO=y
--
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] mainline NAND+MMC device tree kernel panic
On 9 January 2015 at 18:16, Vladimir Komendantskiy
komendant...@gmail.com wrote:
Can you help me understand this strange bug on a10s-olinuxino-m? I guess my
DT record for NAND MTD partitions is somehow incorrect because I happen to
get a kernel panic in the mainline 3.19 kernel that looks like this:
[0.599782] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde
[0.606203] nand: Hynix H27UCG8T2ETR-BC 8GiB 3.3V 8-bit
[0.611433] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size: 16384,
OOB size: 1664
[0.628428] Bad block table found at page 524032, version 0x01
[0.650299] Bad block table found at page 523776, version 0x01
[0.664100] nand_bbt: ECC error in BBT at 0xffc5
[0.677393] nand_bbt: ECC error in BBT at 0xff85
[0.682711] Scanning device for bad blocks
[1.086137] random: nonblocking pool is initialized
[1.769233] Bad eraseblock 1992 at 0x0001f23fc000
[1.814688] Bad block table written to 0x0001ffc0, version 0x01
[1.832192] Bad block table written to 0x0001ff80, version 0x01
[1.839592] 4 ofpart partitions found on MTD device H27UCG8T2ETR-BC 8GiB
3.3V 8-bit
[1.847297] Creating 4 MTD partitions on H27UCG8T2ETR-BC 8GiB 3.3V
8-bit:
[1.854275] 0x-0x0040 : boot0
[1.859622] 0x0040-0x0080 : boot1
[1.864877] 0x0080-0x0180 : kernel
[1.870197] 0x0180-0x0002 : rootfs
...snip...
[2.124638] Registering SWP/SWPB emulation handler
[2.129842] Unable to handle kernel NULL pointer dereference at virtual
address 0713
SWP/SWPB instruction emulation has nothing to do with the NFC. The kernel
boots OK as soon as I disable the NFC in the device tree. In a successful
boot attempt, this is followed by mmc0 initialisation. So, it looks like the
culprit is mmc0. However, disabling the leaf mmc nodes in the device tree
does not change the outcome.
Here is my nfc configuration added to the mainline
sunxi-a10s-olinuxino-micro.dts. The pinctrl-0 definitions are standard, same
as in Boris' repo for Cubietruck.
nfc: nand@01c03000 { compatible = allwinner,sun4i-a10-nand; reg =
0x01c03000 0x1000; interrupts = 37; clocks = ahb_gates 13,
nand_clk; clock-names = ahb, mod; #address-cells = 1; #size-cells =
0; pinctrl-names = default; pinctrl-0 = nand_pins_a nand_cs0_pins_a
nand_rb0_pins_a; status = okay; nand@0 { reg = 0; allwinner,rb = 0;
#address-cells = 1; #size-cells = 2; nand-on-flash-bbt; nand-ecc-mode =
hw; boot0@0 { label = boot0; reg = 0x0 0x0 0x40; }; boot1@40 {
label = boot1; reg = 0x40 0x0 0x40; }; kernel@80 { label =
kernel; reg = 0x80 0x0 0x100; }; rootfs@180 { label =
rootfs; reg = 0x180 0x1 0xfe80; }; }; };
Hello,
I use this tree with the nand patches and cubieboard DT patches
https://github.com/hramrach/linux-sunxi/tree/sunxi-nand-next
I can boot this on cubieboard12 so you should be able to adapt the
cubieboard1 patch to sun5i
HTH
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: Sunxi FOSDEM2015 Dinner!
Hey guys, On 09-01-15 11:03, Benjamin Henrion wrote: On Fri, Jan 9, 2015 at 10:28 AM, TsvetanUsunov tsvetanusu...@gmail.com wrote: +2 for Olimex I will be there as well. @Oliver congratulations for the Cubieboard book at Packt! Thank you! I'm still upset it is focused around CB title-wise, the book is 'all round' however and can be used with all our boards! Same place as last year or you want to go somewhere else? I wasn't there last year, but if there is no objections, I see why not. For the record; I will be +2 = 3 tot ;) olliver -- Benjamin Henrion bhenrion at ffii.org FFII Brussels - +32-484-566109 - +32-2-4148403 In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators. -- 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] Use H264 to Encode VideoOutput
Hello I'd like to know if it's possible to use the video encoder to save to file the video output ? So the device would output to hdmi , and in the same time, save to file what is displayed. I'm waiting on my A20 dev board -- 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.
