you can downlod our new image ,will have fixed this issue.
Sorry, I didn’t explained the issue correctly.
With connected USB peripherals, board shuts down immediately after I press ‘power on’ button. Power led just blinks for ~0.3 seconds.
It didn’t getting to kernel loading stage, and I guess, at u-boot loading stage also.
I do have latest kernel with ‘always load above 1.00 fix’ patch and some minor tweaks for my use case.
As I explained earlier, I have no problems connecting USB devices after kernel is loaded. So latest kernel patch, that letting PMU handle high current, is working.
May be, by default (immediately after power on), PMU is unable to handle current, drawn by USB peripherals?
This is why I asked about board version difference. I was thinking, that in v1.2, PMU have some sort of bootstrap to handle high current at startup.
I did some investigation with schematics provided for v1.2 board, and found difference in the way, USB peripheral ports powered.
There is two ferrite beads, FB7 and FB4. FB7 powers USB ports directly from microUSB port, and FB4 powers them from PMU. But on my board, FB7 solder pads are not populated, there is no FB7 on my board.
That actually makes sense, USB peripheral ports should be powered only by PMU, It will allow controling and monitoring current drawn by USB devices, and keep them powered off while board is powered off.
So I’m asking people who own v1.2 board, could someone check, if FB7 is present?
Did you measure with an oscilloscope ? I am asking, because a Multimeter is to slow to show you short drops in voltage or ampere. Beside you will also have to measure on different sections of the board in parallel.
Remove everything beside Ethernet. You can try with a powered USB-Hub.
Out of curiousity: Did you apply the latest fix mentioned above or not? Since this should also fix PMU handling in u-boot (and requires to overwrite a few sectors on the image/card).
Can’t help with the hardware issue since I also have v1.1
Yes, voltage drops may be very short, but I don’t have an oscilliscope, to measure them. But I soldered thick wires to pads for barrel plug connector and powered board from laboratory PSU. So, I guess, problems with voltage drops on microUSB connector can be excluded. When connecting everything to powered USB hub, I have no problems.
Yes, I do have latest fixes from github repo compiled and written to appropriate sectors of my eMMC.
Then according even to SinoVoip’s CEO everything is fine: CPU Performance Review of SBCs
So what are you complaining about?! 
I just learned that voltage drops happening between PSU and the Micro USB jack can be avoided by software fixes. So much magic involved when dealing with the M3 
And in the meantime someone at SinoVoip could have looked many times on the PCB and confirm/deny existence of FB7. But it’s just as usual…
In this respect, your line 3 is a little bit wrong.
I don’t know which PMU sits on the M3, do you know how many watts it can /could deliver?
Judging by last commit at github repo, PMU can deliver up to 4000mA. There is no way I could get such a current from my USB devices.
Hmm, I guess I found it on a picture on ‘sunxi’ it is an: axp813 I cannot look up all pages from the PC I am right now. I wouldn’t judge on a GitHub from SinoVoip.
Better search the datasheet
Think about the context! I was referring to Lion’s and sinovoip’s endlessly repeated claims that with their latest commits to Github all Micro USB related problems would be solved. The link from before: CPU Performance Review of SBCs
And this is obviously wrong. While they might have solved issues related to powering USB devices they have not resolved the problems related with Micro USB as DC-IN source. But since it’s useless talking to them since they don’t listen…
And since they remain silent now instead of telling @mihaly4 whether FB7 is present on PCB revision 1.2 or not we can almost be certain that this is a hardware fix, customers of PCB revision 1.1 would need a solder iron for.
One would assume the manufacturer would be of any help here since it’s their ‘official support forum’, they read this thread, they have the boards lying around, their engineers should know what’s going on and even someone without any technical clues could have a look at PCB rev. 1.2 and answer your question within seconds.
But… they don’t help. Why? Why would you buy products from a vendor that simply doesn’t care about customers?
at first , please check our newest image , we have optimize AXP PMU setting ,we test add 2.5 hardisk ,USB HUB, HDMI to VGA line,all can power it , and work fine.
now deisgn , all power is spport from AXP PMU
we also support get power direct from DC power .
FB7 add 0 ohm resistor.
FB4 magnetic bead remove. so power is direct from DC power
Note : if you have do this change , if you use 3.7 battery to power , USB port will not work.
It’s so sad. The whole thread is about that he already uses the last version and that it’s NOT ‘work fine’.
Power hardware design is same. not any change.
voltage is dropping to ~3V at boot time. If I connect USB peripherals after system booted : please try our newest image ,and told us result.
So why don’t you carefully read @mihaly4’s question and then answer accordingly? It was only about the above. You could simply answered this simple question. But instead the usual bullsh*t: “Start from scratch, use our newest image”. He DID so already! When do you start to respect your customers?!
Obviously never. So sad.
OK, I got all the answers about board versions I needed. I do not use images provided by SinoVoip, I’m using custom made image, containing ArchLinux root, latest kernel and u-boot from github. I guess it doesn’t matter which distro I’m using as root. Since I’m not planning to use battery, I removed FB4 and soldered in on FB7 place. As I expected, board starts fine now, but this is not a real solution. Other vendor boards with A83T SoC are using AXP818 instead of AXP813. I wonder, if it is PMU problem or board design flaw. I don’t believe that this can be fixed by code, because board shuts down immediately after power on. I can hardly believe that U-boot can be loaded immediately after power button is pressed, it needs at least a half of second i guess. Or may be I’m wrong.
for allwinner chip
H8 use AXP818, and A83T is AXP813. R58 use also AXP813
we have test all , same issue. it is about allwinner AXP issue. we have optimize all AXP parameter,it can work fine ,but also have some limited to need more power.
allwinner answer is : they design this chip , just for box and PAD , so we need add more external accessories, need more power , it is limited . so we design the two way to support power .
please not always to say us "so bad“, i am so crazy with you.
Of course. U-boot with/without latest patches might have made a difference. You could give mainline u-boot a try and look into board_init. Maybe behaviour changes.
I remember a discussion on either linux-sunxi IRC or the mailing list about a similar problem (default voltages after board reset which defaulted to 3V instead of 3.3V). But 5V vs. 3V is something different (I also think it was about A64’s PMU) and unfortunately I didn’t found the discussion 
Anyway: I would try to join linux-sunxi IRC and ask vishnup or wens whether they have an idea whether it’s related to PMU or not.
1 Like