[linux-sunxi] Strange behavior with missing H3 interrupts

[Martin Kelly]

Hi,

I've noticed strange behavior on my H3 (nanopi neo air) and am wondering 
if anyone has suggestions for further debugging it, as I'm getting stumped.


Specifically, I have configured a device (Invensense MPU9250) to deliver 
interrupts at 10Hz to PG_EINT11. For some reason, though, the interrupt 
handler is being called at only about 6 Hz.


Looking at a logic analyzer, I see the hardware is interrupting at 10 Hz 
as it should, but sometimes the interrupts are just missed from the 
kernel side. So you might see a 200 ms gap between calls to the IRQ 
handler, but 100 ms between hardware IRQ events.


Using ftrace, I see that sunxi_pinctrl_irq_handler is being called at 
about 6 Hz as well. The system load is very low (~0%) on all CPUs, and 
it doesn't appear that anyone is disabling this interrupt.


I have also verified that the IRQ handlers are exiting in less than 1 
ms, and the bottom half of the handler in less than 5 ms; they don't 
appear to be conflicting with the next IRQ coming in.


The interrupts are rising edges, and are consistently about 50 
microseconds in width.


This is the relevant device-tree fragment:

 {
mpu9250@68 {
model = "Invensense MPU9250";
compatible = "invensense,mpu9250";
reg = <0x68>;
interrupt-parent = <>;
interrupts = <6 11 IRQ_TYPE_EDGE_RISING>; /* PG11 / PG_EINT11 */
};
};

I'm quite stumped as to where to look next and would welcome any 
suggestions.


Thanks,
Martin

--
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] CHIP goes bankrupt?

[Luc Verhaegen]

On Wed, Apr 04, 2018 at 04:22:02PM +0200, Luc Verhaegen wrote:
> On Wed, Apr 04, 2018 at 01:55:36PM +, Benjamin Henrion wrote:
> > CHIP goes bankrupt?:
> > 
> > https://hackaday.com/2018/04/03/is-this-the-end-for-the-c-h-i-p/
> 
> Another $hitpi down the drain.
> 
> ($hitpi: a cheap board, often chinese, trying hard to compete with the 
> raspberry pi)
> 
> The only notable difference is that this was (at least superficially, 
> they did seem to have quite some chinese ties) a .us based kickstarter, 
> and their crowdfunding campaign got bitten hard by the GPL violations 
> drumbeating.
> 
> So much so that they made a u-turn halfway through their kickstarter 
> campaign and ended up paying free-electrons to have some of their 
> developers work on upstream code on paid time.
> 
> But mostly, NTC is/was a lot more noise compared to other $hitpis.
> 
> The only $hitpi i truly am not glad to have seen go was the cubieboard, 
> as Tom Cubies board(s) and attitude helped make linux-sunxi big. And 
> that was soon 6 years ago.

Also, we still do not have any real info about the c.h.i.p. in our wiki.

NTC of course wanted to build its own totally separate community, which 
is standard $hitpi practice tbh. So here it once again should be clear 
just how important a vendor neutral wiki is. But that's something sunxi 
and other projects' longtimers should've known already.

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] CHIP goes bankrupt?

[Luc Verhaegen]

On Wed, Apr 04, 2018 at 01:55:36PM +, Benjamin Henrion wrote:
> CHIP goes bankrupt?:
> 
> https://hackaday.com/2018/04/03/is-this-the-end-for-the-c-h-i-p/

Another $hitpi down the drain.

($hitpi: a cheap board, often chinese, trying hard to compete with the 
raspberry pi)

The only notable difference is that this was (at least superficially, 
they did seem to have quite some chinese ties) a .us based kickstarter, 
and their crowdfunding campaign got bitten hard by the GPL violations 
drumbeating.

So much so that they made a u-turn halfway through their kickstarter 
campaign and ended up paying free-electrons to have some of their 
developers work on upstream code on paid time.

But mostly, NTC is/was a lot more noise compared to other $hitpis.

The only $hitpi i truly am not glad to have seen go was the cubieboard, 
as Tom Cubies board(s) and attitude helped make linux-sunxi big. And 
that was soon 6 years ago.

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] CHIP goes bankrupt?

[Benjamin Henrion]

CHIP goes bankrupt?:

https://hackaday.com/2018/04/03/is-this-the-end-for-the-c-h-i-p/

-- 
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] "BUG: Bad page state in process ..." on Olimex A64-OLinuXino

[Andre Przywara]

Hi,

On 04/04/18 10:42, Martin Lucina wrote:
> Hi,
> 
> On Thursday, 22.03.2018 at 20:47, André Przywara wrote:
>>> Ok, I just measured both ports (via a cannibalised USB cable + OTG for the
>>> micro-USB) and there's no power on either of them. Cross-checked the
>>> measurement setup against an old Thinkpad to be sure.
> 
> One more data point which I did not notice before: After ATF runs but
> before the kernel boots I get 5V (well, 4.85V but close enough) on the
> USB-A port. Once the kernel has booted the voltage drops to zero.

Ah, interesting, but would make some sense: PG9 is pulled high on the
board, so you have to actively drive it *low* to *disable* the power.
Do you have some nodes for the WiFi/BT module in the DT? The UART1 CTS
is also on PG9, and we bundle it with the RTS pin in one group. RTS is
used by the BT module, but CTS is not.
So as soon as we initialise UART1, we might accidentally pull that line
low and disable USB power.

>> OK, remote debugging!
>>
>> Can you please try to play around with GPIO PG9 from Linux? Basically:
>> # cd /sys/class/gpio
>> # echo 201 > export
>> # cd gpio201
>> # echo out > direction
>> # echo 1 > value
>>
>> And then try to measure the USB voltage again? Try 0 for "value" as
>> well. If the export complains, try to remove the DT parts I gave you
>> (switch back to the normal mainline DT). 201 is ('G'-'A') * 32 + 9.
>> Something like that should enable the voltage on the USB-A socket
>> (regardless of the DT used).
> 
> I seem to be missing some driver for the GPIOs as I have no
> /sys/class/gpio and nothing that looks suitable in /lib/modules; what do I
> need to add to the arm64 defconfig to enable this?

Ah, yes, you need CONFIG_GPIO_SYSFS in your .config. You can use any
other userland tool to manipulate GPIOs, though.
You may also try to use U-Boot's "gpio" command, though I am not sure
that works on the A64 at the moment. Possibly today's sunxi/master
U-Boot branch would fix this.

>> For the micro-B port: Can you try to add the following line to the ATF
>> source, into plat/sun50iw1p1/sunxi_power.c, somewhere in the
>> pmic_setup() function:
>>  sunxi_pmic_write(0x30, sunxi_pmic_read(0x30) | BIT(2));
>>
>> That should power the DRIVEVBUS/N_VBUSEN pin, ideally turning on the
>> power of the OTG port.
>> If that works, I can make a Linux patch to do this there as well.
> 
> When I add that line to ATF I get 5V on the micro-B port after
> initialisation and it stays powered up even after the kernel has booted.

Good, so that's some confirmation. I recently found that the BananaPi
M64 uses the very same setup for the OTG port, and there are patches on
the way to support it properly. So we can piggy back on that.
We might need that ATF patch to enable it in U-Boot as well, if we care
(fastboot?). That would be shared with the BPi-M64, then.

Cheers,
Andre.

-- 
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] A64: mmc1: SDIO req failed for CMD5 Timeout(-110)

[Jagan Teki]

On 04/04/2018 05:24 PM, Chen-Yu Tsai wrote:

On Wed, Apr 4, 2018 at 7:09 PM, Jagan Teki  wrote:

On 04/04/2018 04:31 PM, Jagan Teki wrote:


On 04/03/2018 04:09 PM, Chen-Yu Tsai wrote:


On Tue, Apr 3, 2018 at 6:31 PM, Jagan Teki  wrote:


On 04/03/2018 03:16 PM, Chen-Yu Tsai wrote:



On Tue, Apr 3, 2018 at 5:43 PM, Jagan Teki  wrote:



On 04/03/2018 03:02 PM, Chen-Yu Tsai wrote:




On Tue, Apr 3, 2018 at 5:27 PM, Jagan Teki 
wrote:




On 04/03/2018 02:26 PM, Chen-Yu Tsai wrote:





On Tue, Apr 3, 2018 at 3:29 PM, Jagan Teki 
wrote:





On 04/03/2018 12:19 PM, Chen-Yu Tsai wrote:






On Tue, Apr 3, 2018 at 2:44 PM, Jagan Teki 
wrote:






Hi,

Anyone observed SDIO CMD5 timeout for A64 boards.?

I've custom board runs with linux-next and I'm unable to probe
SDIO
on
mmc1, observed CMD5 timeout.

Here is the log and dts node, request for any help?

Log:
[0.340446] sunxi-mmc 1c1.mmc: could not find pctldev for
node
/soc/pinctrl@1c20800/mmc1-pins, deferring p
robe
[1.927883] mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21
width
1 timing 0
[1.948765] mmc1: clock 40Hz busmode 2 powermode 2 cs 0
Vdd
21
width 1 timing 0
[2.008318] mmc1: mmc_rescan_try_freq: trying to init card at
40
Hz
[2.018121] mmc1: starting CMD52 arg 0c00 flags 0195
[2.055592] mmc1: req done (CMD52): -110:  


[2.064813] mmc1: starting CMD52 arg 8c08 flags 0195
[2.078524] mmc1: req done (CMD52): -110:  


[2.095536] mmc1: clock 40Hz busmode 2 powermode 2 cs 1
Vdd
21
width 1 timing 0
[2.108250] mmc1: starting CMD0 arg  flags 00c0
[2.115158] mmc1: req done (CMD0): 0:  


[2.132065] mmc1: clock 40Hz busmode 2 powermode 2 cs 0
Vdd
21
width 1 timing 0
[2.143698] mmc1: starting CMD8 arg 01aa flags 02f5
[2.155126] mmc1: req done (CMD8): -110:  


[2.164988] mmc1: starting CMD5 arg  flags 02e1
[2.175369] mmc1: req failed (CMD5): -110, retrying...
[2.185932] mmc1: req failed (CMD5): -110, retrying...
[2.196754] mmc1: req failed (CMD5): -110, retrying...

dt node:

wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>;
/*
WL-PMU-EN:
PL2 */
   };

 {
  pinctrl-names = "default";
  pinctrl-0 = <_pins>;
  vmmc-supply = <_aldo1>;
  vqmmc-supply = <_dldo4>;
  mmc-pwrseq = <_pwrseq>;
  bus-width = <4>;
  non-removable;
  status = "okay";

  brcmf: wifi@1 {
  reg = <1>;
  compatible = "brcm,bcm4329-fmac";
  interrupt-parent = <_pio>;
  interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>;  /*
WL-WAKE-AP:
PL3 */
  interrupt-names = "host-wake";
  };
};







Are you certain everything is powered up? On some boards they use
different
regulators for vqmmc on the WiFi chip and pin VCC on the SoC
side.
Also
try







Yes, I didn't find much different in regulator setup on vqmmc,
vmmc
it
is
similar to bananapi-m64 which is drive to dldo4 for vqmmc and
aldo1
for
vmmc
like this

vqmmc:

  DLDO4VCC-PG   VCC-IO-WIFI
|||
|||
 |
  ELDO1  |
||






Have you tried enabling both regulators?






At same time no? I've tried one after another.





Well, it's possible that one feeds VCC-PG and the other VCC-IO-WIFI.
So you need to enable both.





I never see how to enable both same for vqmmc, is it something like
this?

vqmmc-supply = <_dldo4 _eldo1>;




You can't. Not yet anyway. Just set one of them to "always on",
preferably
the one for the SoC side, as using any other pins in that pin group
would




look like VCC-PG is from processor side, set the same eldo1 to
regulator-always-on and vqmmc-supply = 


also require it to be powered.




What do you mean by pin group here? does that mean linking other
supplies
which are attached to same regulator like eldo1 here?



As the name VCC-PG implies, it provides power to the PG pingroup. So if
the board uses any of the other PG pins for things such as GPIOs or other
peripherals, you will need to power it regardless of whether WiFi is on
or not. I suggest you read up on the datasheets which explain what pin
does what.



Yes we have PG group GPIO's which is similar to bananapi-m64 like PG0-PG13
I have power it the all. Wouldn't find any change in behavior. I've XTAL-IN
and XTAL-OUT on pin10 and 11 with 26MHz like orangepi-win would that clock
effect? attached oragepi-win schematics please see on page 13.



What I mean to 

Re: [linux-sunxi] A64: mmc1: SDIO req failed for CMD5 Timeout(-110)

[Chen-Yu Tsai]

On Wed, Apr 4, 2018 at 7:09 PM, Jagan Teki  wrote:
> On 04/04/2018 04:31 PM, Jagan Teki wrote:
>>
>> On 04/03/2018 04:09 PM, Chen-Yu Tsai wrote:
>>>
>>> On Tue, Apr 3, 2018 at 6:31 PM, Jagan Teki  wrote:

 On 04/03/2018 03:16 PM, Chen-Yu Tsai wrote:
>
>
> On Tue, Apr 3, 2018 at 5:43 PM, Jagan Teki  wrote:
>>
>>
>> On 04/03/2018 03:02 PM, Chen-Yu Tsai wrote:
>>>
>>>
>>>
>>> On Tue, Apr 3, 2018 at 5:27 PM, Jagan Teki 
>>> wrote:



 On 04/03/2018 02:26 PM, Chen-Yu Tsai wrote:
>
>
>
>
> On Tue, Apr 3, 2018 at 3:29 PM, Jagan Teki 
> wrote:
>>
>>
>>
>>
>> On 04/03/2018 12:19 PM, Chen-Yu Tsai wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 3, 2018 at 2:44 PM, Jagan Teki 
>>> wrote:





 Hi,

 Anyone observed SDIO CMD5 timeout for A64 boards.?

 I've custom board runs with linux-next and I'm unable to probe
 SDIO
 on
 mmc1, observed CMD5 timeout.

 Here is the log and dts node, request for any help?

 Log:
 [0.340446] sunxi-mmc 1c1.mmc: could not find pctldev for
 node
 /soc/pinctrl@1c20800/mmc1-pins, deferring p
 robe
 [1.927883] mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21
 width
 1 timing 0
 [1.948765] mmc1: clock 40Hz busmode 2 powermode 2 cs 0
 Vdd
 21
 width 1 timing 0
 [2.008318] mmc1: mmc_rescan_try_freq: trying to init card at
 40
 Hz
 [2.018121] mmc1: starting CMD52 arg 0c00 flags 0195
 [2.055592] mmc1: req done (CMD52): -110:  
 
 
 [2.064813] mmc1: starting CMD52 arg 8c08 flags 0195
 [2.078524] mmc1: req done (CMD52): -110:  
 
 
 [2.095536] mmc1: clock 40Hz busmode 2 powermode 2 cs 1
 Vdd
 21
 width 1 timing 0
 [2.108250] mmc1: starting CMD0 arg  flags 00c0
 [2.115158] mmc1: req done (CMD0): 0:  
 
 
 [2.132065] mmc1: clock 40Hz busmode 2 powermode 2 cs 0
 Vdd
 21
 width 1 timing 0
 [2.143698] mmc1: starting CMD8 arg 01aa flags 02f5
 [2.155126] mmc1: req done (CMD8): -110:  
 
 
 [2.164988] mmc1: starting CMD5 arg  flags 02e1
 [2.175369] mmc1: req failed (CMD5): -110, retrying...
 [2.185932] mmc1: req failed (CMD5): -110, retrying...
 [2.196754] mmc1: req failed (CMD5): -110, retrying...

 dt node:

 wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>;
 /*
 WL-PMU-EN:
 PL2 */
   };

  {
  pinctrl-names = "default";
  pinctrl-0 = <_pins>;
  vmmc-supply = <_aldo1>;
  vqmmc-supply = <_dldo4>;
  mmc-pwrseq = <_pwrseq>;
  bus-width = <4>;
  non-removable;
  status = "okay";

  brcmf: wifi@1 {
  reg = <1>;
  compatible = "brcm,bcm4329-fmac";
  interrupt-parent = <_pio>;
  interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>;  /*
 WL-WAKE-AP:
 PL3 */
  interrupt-names = "host-wake";
  };
 };
>>>
>>>
>>>
>>>
>>>
>>>
>>> Are you certain everything is powered up? On some boards they use
>>> different
>>> regulators for vqmmc on the WiFi chip and pin VCC on the SoC
>>> side.
>>> Also
>>> try
>>
>>
>>
>>
>>
>>
>> Yes, I didn't find much different in regulator setup on vqmmc,
>> vmmc
>> it

Re: [linux-sunxi] A64: mmc1: SDIO req failed for CMD5 Timeout(-110)

[Jagan Teki]

On 04/04/2018 04:31 PM, Jagan Teki wrote:

On 04/03/2018 04:09 PM, Chen-Yu Tsai wrote:

On Tue, Apr 3, 2018 at 6:31 PM, Jagan Teki  wrote:

On 04/03/2018 03:16 PM, Chen-Yu Tsai wrote:


On Tue, Apr 3, 2018 at 5:43 PM, Jagan Teki  wrote:


On 04/03/2018 03:02 PM, Chen-Yu Tsai wrote:



On Tue, Apr 3, 2018 at 5:27 PM, Jagan Teki  
wrote:



On 04/03/2018 02:26 PM, Chen-Yu Tsai wrote:




On Tue, Apr 3, 2018 at 3:29 PM, Jagan Teki  
wrote:




On 04/03/2018 12:19 PM, Chen-Yu Tsai wrote:





On Tue, Apr 3, 2018 at 2:44 PM, Jagan Teki 
wrote:





Hi,

Anyone observed SDIO CMD5 timeout for A64 boards.?

I've custom board runs with linux-next and I'm unable to 
probe SDIO

on
mmc1, observed CMD5 timeout.

Here is the log and dts node, request for any help?

Log:
[    0.340446] sunxi-mmc 1c1.mmc: could not find pctldev for
node
/soc/pinctrl@1c20800/mmc1-pins, deferring p
robe
[    1.927883] mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21
width
1 timing 0
[    1.948765] mmc1: clock 40Hz busmode 2 powermode 2 cs 
0 Vdd

21
width 1 timing 0
[    2.008318] mmc1: mmc_rescan_try_freq: trying to init card at
40
Hz
[    2.018121] mmc1: starting CMD52 arg 0c00 flags 0195
[    2.055592] mmc1: req done (CMD52): -110:  


[    2.064813] mmc1: starting CMD52 arg 8c08 flags 0195
[    2.078524] mmc1: req done (CMD52): -110:  


[    2.095536] mmc1: clock 40Hz busmode 2 powermode 2 cs 
1 Vdd

21
width 1 timing 0
[    2.108250] mmc1: starting CMD0 arg  flags 00c0
[    2.115158] mmc1: req done (CMD0): 0:   



[    2.132065] mmc1: clock 40Hz busmode 2 powermode 2 cs 
0 Vdd

21
width 1 timing 0
[    2.143698] mmc1: starting CMD8 arg 01aa flags 02f5
[    2.155126] mmc1: req done (CMD8): -110:  


[    2.164988] mmc1: starting CMD5 arg  flags 02e1
[    2.175369] mmc1: req failed (CMD5): -110, retrying...
[    2.185932] mmc1: req failed (CMD5): -110, retrying...
[    2.196754] mmc1: req failed (CMD5): -110, retrying...

dt node:

wifi_pwrseq: wifi_pwrseq {
   compatible = "mmc-pwrseq-simple";
   reset-gpios = <_pio 0 2 
GPIO_ACTIVE_LOW>; /*

WL-PMU-EN:
PL2 */
  };

 {
 pinctrl-names = "default";
 pinctrl-0 = <_pins>;
 vmmc-supply = <_aldo1>;
 vqmmc-supply = <_dldo4>;
 mmc-pwrseq = <_pwrseq>;
 bus-width = <4>;
 non-removable;
 status = "okay";

 brcmf: wifi@1 {
 reg = <1>;
 compatible = "brcm,bcm4329-fmac";
 interrupt-parent = <_pio>;
 interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>;  /*
WL-WAKE-AP:
PL3 */
 interrupt-names = "host-wake";
 };
};






Are you certain everything is powered up? On some boards they use
different
regulators for vqmmc on the WiFi chip and pin VCC on the SoC 
side.

Also
try






Yes, I didn't find much different in regulator setup on vqmmc, 
vmmc

it
is
similar to bananapi-m64 which is drive to dldo4 for vqmmc and 
aldo1

for
vmmc
like this

vqmmc:

 DLDO4    VCC-PG   VCC-IO-WIFI
   |    |    |
   |||
    |
 ELDO1  |
   ||





Have you tried enabling both regulators?





At same time no? I've tried one after another.




Well, it's possible that one feeds VCC-PG and the other VCC-IO-WIFI.
So you need to enable both.




I never see how to enable both same for vqmmc, is it something like 
this?


vqmmc-supply = <_dldo4 _eldo1>;



You can't. Not yet anyway. Just set one of them to "always on", 
preferably
the one for the SoC side, as using any other pins in that pin group 
would



look like VCC-PG is from processor side, set the same eldo1 to
regulator-always-on and vqmmc-supply = 


also require it to be powered.



What do you mean by pin group here? does that mean linking other 
supplies

which are attached to same regulator like eldo1 here?


As the name VCC-PG implies, it provides power to the PG pingroup. So if
the board uses any of the other PG pins for things such as GPIOs or other
peripherals, you will need to power it regardless of whether WiFi is on
or not. I suggest you read up on the datasheets which explain what pin
does what.


Yes we have PG group GPIO's which is similar to bananapi-m64 like 
PG0-PG13 I have power it the all. Wouldn't find any change in behavior. 
I've XTAL-IN and XTAL-OUT on pin10 and 11 with 26MHz like orangepi-win 
would that clock effect? attached oragepi-win schematics please see on 
page 13.


What I mean to say here is, osc24M and osc32k added in sun50-a64.dtsi no 
clock for osc26M is it really need?


Jagan.

--
You received this message 

[linux-sunxi] Re: [U-Boot] [PATCH v5 00/11] sunxi: update H3/H5/A64 EMAC DT nodes

[Andre Przywara]

Hi,

On 04/04/18 09:55, Jagan Teki wrote:
> On Wed, Apr 4, 2018 at 12:14 PM, Jagan Teki  wrote:
>> On Wed, Apr 4, 2018 at 6:01 AM, Andre Przywara  
>> wrote:
>>> This is the first half of the DT update series, just updating the
>>> EMAC DT nodes, for which the bindings have diverged.
>>> Just fixed some checkpatch warnings and rebased (without conflicts)
>>> against v2018.05-rc1.
>>> As before, this includes the patches to drop the direct MMC environment
>>> for all Allwinner boards, to finally get rid of the image size limitation.
>>>
>>> Patch 01 leaves some hint in the README how to avoid the situation
>>> when overrunning U-Boot's image size on 64-bit boards.
>>> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
>>> EMAC driver for using the new DT binding used in Linux, also updates
>>> the DTs to the new EMAC DT node already.
>>>
>>> The final patches lift the space limit we currently have due to the raw
>>> MMC environment.
>>> Patch 09 disables that for all sunxi boards, to give us finally some
>>> space. Patches 10 and 11 consequently revert the disabling of features we
>>> saw a few weeks ago to migitate the size problem.
>>>
>>> Cheers,
>>> Andre.
>>>
>>> Changelog v4 .. v5:
>>> - drop Linux DT update patches for now
>>> - fix minor checkpatch complaints
>>>
>>> Changelog v3 .. v4:
>>> - remove MMC environment for all Allwinner boards (including 32 bit ones)
>>> - keep MMC environment offset to the old values
>>> - drop DT adjustments to use fixed MMC regulator
>>>
>>> Changelog v2 .. v3:
>>> 01: added, was on the list before
>>> 02: drop redundant H5 line
>>> 03-08: unchanged
>>> 09-20: added
>>>
>>> Changelog v1 .. v2:
>>> 01, 02, 03: unchanged
>>> 04, 05, 06, 07: added
>>>
>>> Andre Przywara (11):
>>>   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
>>> Firmware
>>>   sunxi: gpio: add missing compatible strings
>>>   net: sun8i-emac: support new pinctrl DT bindings
>>>   net: sun8i-emac: add support for new EMAC DT binding
>>>   arm: dts: sunxi: update A64 to new EMAC binding
>>>   arm: dts: sunxi: update H3 to new EMAC binding
>>>   arm: dts: sunxi: update H5 to new EMAC binding
>>>   net: sun8i-emac: remove support for old binding
>>>   sunxi: disable direct MMC environment
>>>   sunxi: revert disabling of features
>>>   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"
>>
>> Reviewed-by: Jagan Teki 
> 
> Applied to u-boot-sunxi/master

Thanks for that!

Looking at the repo, I wonder if we should clean up the branches?
I see:
  master-next
  master-pr
  next
  size-fixes
to be outdated, because the patches in there have been merged a long
time ago. This is especially confusing with the next and master-next
branch, because their name somewhat suggests bleeding edge code.

So can we either delete them or populate them with something more
appropriate?

Cheers,
Andre.

-- 
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] "BUG: Bad page state in process ..." on Olimex A64-OLinuXino

[Martin Lucina]

Hi,

On Thursday, 22.03.2018 at 20:47, André Przywara wrote:
> > Ok, I just measured both ports (via a cannibalised USB cable + OTG for the
> > micro-USB) and there's no power on either of them. Cross-checked the
> > measurement setup against an old Thinkpad to be sure.

One more data point which I did not notice before: After ATF runs but
before the kernel boots I get 5V (well, 4.85V but close enough) on the
USB-A port. Once the kernel has booted the voltage drops to zero.

> OK, remote debugging!
> 
> Can you please try to play around with GPIO PG9 from Linux? Basically:
> # cd /sys/class/gpio
> # echo 201 > export
> # cd gpio201
> # echo out > direction
> # echo 1 > value
> 
> And then try to measure the USB voltage again? Try 0 for "value" as
> well. If the export complains, try to remove the DT parts I gave you
> (switch back to the normal mainline DT). 201 is ('G'-'A') * 32 + 9.
> Something like that should enable the voltage on the USB-A socket
> (regardless of the DT used).

I seem to be missing some driver for the GPIOs as I have no
/sys/class/gpio and nothing that looks suitable in /lib/modules; what do I
need to add to the arm64 defconfig to enable this?

> For the micro-B port: Can you try to add the following line to the ATF
> source, into plat/sun50iw1p1/sunxi_power.c, somewhere in the
> pmic_setup() function:
>   sunxi_pmic_write(0x30, sunxi_pmic_read(0x30) | BIT(2));
> 
> That should power the DRIVEVBUS/N_VBUSEN pin, ideally turning on the
> power of the OTG port.
> If that works, I can make a Linux patch to do this there as well.

When I add that line to ATF I get 5V on the micro-B port after
initialisation and it stays powered up even after the kernel has booted.

Cheers,

-mato

-- 
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 v5 09/11] sunxi: disable direct MMC environment

[Andre Przywara]

Hi Maxime,

On 04/04/18 07:42, Maxime Ripard wrote:
> On Wed, Apr 04, 2018 at 01:31:21AM +0100, Andre Przywara wrote:
>> Since the dawn of time for the Allwinner support in mainline U-Boot
>> we store the environment to the SD card and write directly at
>> 544KB from the beginning of the device. This leads to problems when
>> the U-Boot proper image grows beyond 504KB and eventually overlaps.
>> With one release of having the environment preferably in a FAT
>> partition, let's now turn off the MMC variant fallback, so we get back
>> all the space we need to implement features.
>>
>> Signed-off-by: Andre Przywara 
> 
> Acked-by: Maxime Ripard 

Thanks a lot, also for the good collaboration during the "dark times" of
the U-Boot proper size limitation ;-)

Cheers,
Andre.

-- 
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] [PATCH v5 00/11] sunxi: update H3/H5/A64 EMAC DT nodes

[Jagan Teki]

On Wed, Apr 4, 2018 at 12:14 PM, Jagan Teki  wrote:
> On Wed, Apr 4, 2018 at 6:01 AM, Andre Przywara  wrote:
>> This is the first half of the DT update series, just updating the
>> EMAC DT nodes, for which the bindings have diverged.
>> Just fixed some checkpatch warnings and rebased (without conflicts)
>> against v2018.05-rc1.
>> As before, this includes the patches to drop the direct MMC environment
>> for all Allwinner boards, to finally get rid of the image size limitation.
>>
>> Patch 01 leaves some hint in the README how to avoid the situation
>> when overrunning U-Boot's image size on 64-bit boards.
>> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
>> EMAC driver for using the new DT binding used in Linux, also updates
>> the DTs to the new EMAC DT node already.
>>
>> The final patches lift the space limit we currently have due to the raw
>> MMC environment.
>> Patch 09 disables that for all sunxi boards, to give us finally some
>> space. Patches 10 and 11 consequently revert the disabling of features we
>> saw a few weeks ago to migitate the size problem.
>>
>> Cheers,
>> Andre.
>>
>> Changelog v4 .. v5:
>> - drop Linux DT update patches for now
>> - fix minor checkpatch complaints
>>
>> Changelog v3 .. v4:
>> - remove MMC environment for all Allwinner boards (including 32 bit ones)
>> - keep MMC environment offset to the old values
>> - drop DT adjustments to use fixed MMC regulator
>>
>> Changelog v2 .. v3:
>> 01: added, was on the list before
>> 02: drop redundant H5 line
>> 03-08: unchanged
>> 09-20: added
>>
>> Changelog v1 .. v2:
>> 01, 02, 03: unchanged
>> 04, 05, 06, 07: added
>>
>> Andre Przywara (11):
>>   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
>> Firmware
>>   sunxi: gpio: add missing compatible strings
>>   net: sun8i-emac: support new pinctrl DT bindings
>>   net: sun8i-emac: add support for new EMAC DT binding
>>   arm: dts: sunxi: update A64 to new EMAC binding
>>   arm: dts: sunxi: update H3 to new EMAC binding
>>   arm: dts: sunxi: update H5 to new EMAC binding
>>   net: sun8i-emac: remove support for old binding
>>   sunxi: disable direct MMC environment
>>   sunxi: revert disabling of features
>>   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"
>
> Reviewed-by: Jagan Teki 

Applied to u-boot-sunxi/master

-- 
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] [PATCH v5 00/11] sunxi: update H3/H5/A64 EMAC DT nodes

[Jagan Teki]

On Wed, Apr 4, 2018 at 6:01 AM, Andre Przywara  wrote:
> This is the first half of the DT update series, just updating the
> EMAC DT nodes, for which the bindings have diverged.
> Just fixed some checkpatch warnings and rebased (without conflicts)
> against v2018.05-rc1.
> As before, this includes the patches to drop the direct MMC environment
> for all Allwinner boards, to finally get rid of the image size limitation.
>
> Patch 01 leaves some hint in the README how to avoid the situation
> when overrunning U-Boot's image size on 64-bit boards.
> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
> EMAC driver for using the new DT binding used in Linux, also updates
> the DTs to the new EMAC DT node already.
>
> The final patches lift the space limit we currently have due to the raw
> MMC environment.
> Patch 09 disables that for all sunxi boards, to give us finally some
> space. Patches 10 and 11 consequently revert the disabling of features we
> saw a few weeks ago to migitate the size problem.
>
> Cheers,
> Andre.
>
> Changelog v4 .. v5:
> - drop Linux DT update patches for now
> - fix minor checkpatch complaints
>
> Changelog v3 .. v4:
> - remove MMC environment for all Allwinner boards (including 32 bit ones)
> - keep MMC environment offset to the old values
> - drop DT adjustments to use fixed MMC regulator
>
> Changelog v2 .. v3:
> 01: added, was on the list before
> 02: drop redundant H5 line
> 03-08: unchanged
> 09-20: added
>
> Changelog v1 .. v2:
> 01, 02, 03: unchanged
> 04, 05, 06, 07: added
>
> Andre Przywara (11):
>   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
> Firmware
>   sunxi: gpio: add missing compatible strings
>   net: sun8i-emac: support new pinctrl DT bindings
>   net: sun8i-emac: add support for new EMAC DT binding
>   arm: dts: sunxi: update A64 to new EMAC binding
>   arm: dts: sunxi: update H3 to new EMAC binding
>   arm: dts: sunxi: update H5 to new EMAC binding
>   net: sun8i-emac: remove support for old binding
>   sunxi: disable direct MMC environment
>   sunxi: revert disabling of features
>   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"

Reviewed-by: Jagan Teki 

-- 
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.