(01-10-2016, 01:46 PM)devilsclaw Wrote: The reason why I was trying to looking at a schematic is because I got the dev board yesterday and I'm looking into starting to develop for it. Not having to pull the sdcard every time I make a simple change would be nice. I don't want to do development on the pine its self since the sdcard could get corrupt while doing kernel development or the system might become un-bootable. If the dev board is different then the other ones coming out in February then that schematic might be useless to me since I am working on the dev board. The dev people need the schematic that belongs with there boards. there should be no confusion if it is released under the wiki designated for the dev board. Also I don't see any TODO list or work that needs done in the wiki.

(01-10-2016, 12:45 PM)tllim Wrote:

(01-10-2016, 05:45 AM)Andrew2 Wrote:

(01-09-2016, 09:53 PM)devilsclaw Wrote: I tried looking for a schematic for the pine64 but there does not seem to be one.

Simple rule of thumb: don't trust a vendor that doesn't publish at least schematics. It's really that simple 

FEL mode should work on the A64 but if it really works on Pine64 still has to be confirmed (USB OTG is normally used together with Mini or Micro USB where an ID pin exists). The question has been asked already 4 weeks ago but the Pine guys did nothing to answer: http://forum.pine64.org/showthread.php?tid=44 

I would call this already lack of support.

As mentioned earlier, we will publish the Pine A64 schematic, but not Gerber file. The schematic will be publish when we start making the first batch delivery on February. We prefer to publish the schematic version that same as production board. Deliver several earlier versions try to satisfy some curiosity will end up more confusion.

---

(01-10-2016, 08:00 AM)ssvb Wrote:

Quote:Yes, micro USB is only used for DC-IN (weird decision in my humble opinion)

Since the A64 SoC only supports one USB host and one USB OTG, they had a choice between having two USB host connectors or having one regular USB host connector and one mini/micro connector for OTG.

Two USB host connectors are useful for plugging USB keyboard and USB mouse without any extra adapters and that's probably what the general public prefers.

Yes, DC-IN could alternatively use a barrel plug. But USB micro connector is the Raspberry Pi approach, which allows to use cellphone chargers instead of a dedicated power adapter. Admittedly this can lead to reliability issues if people start using shitty chargers or bad USB cables.

Whether using barrel plug or micro SD connector was my struggle when making the DC input plug. The same concern of people using shitty chargers is  and still my main concern of choosing microSD.  However, i finally gave in and decided on microSD based on following two reason.

1. There are different type of barrel plug dimension and the most common is 5x2.1mm type. However, this type of plug are use for +12V application such as network camera. We don't want to keep receiving "dead of arrival" "burned" boards due to some one just keep plug in 12V power supply into Pine A64. There is no such concern using microUSB socket.
2. If we select an unpopular one to avoid answer 1, this can become inconvenient due to cannot get them on the shelve and may keep blame us try to make money out of selling power supply.

Noted on microUSB cannot carry more current compare to barrel plug.

(01-10-2016, 01:46 PM)devilsclaw Wrote: The reason why I was trying to looking at a schematic is because I got the dev board yesterday and I'm looking into starting to develop for it. Not having to pull the sdcard every time I make a simple change would be nice. I don't want to do development on the pine its self since the sdcard could get corrupt while doing kernel development or the system might become un-bootable.

(01-10-2016, 01:57 PM)tllim Wrote: The developer board and production board are comes from same schematic. The only different is power LED light where developer board is green and production board is red color. We can release the schematic to developer in two to three weeks time.

(01-10-2016, 02:45 PM)ssvb Wrote:

(01-10-2016, 01:46 PM)devilsclaw Wrote: The reason why I was trying to looking at a schematic is because I got the dev board yesterday and I'm looking into starting to develop for it. Not having to pull the sdcard every time I make a simple change would be nice. I don't want to do development on the pine its self since the sdcard could get corrupt while doing kernel development or the system might become un-bootable.

USB boot is handled somewhat differently in Allwinner's SDK and in the mainline U-boot. For the mainline U-Boot, you can find  more details here. A bit tricky thing is that the SPL load address is not 0x0 but 0x10000 in A64 and A80. We now have all the necessary changes in sunxi-tools now, but there were no people willing to test FEL USB boot on A80 (apparently A80 is not very popular).

For getting the mainline U-Boot up and running, the most important part is the DRAM controller initialization. For some Allwinner SoC variants this code became open sourced at https://github.com/allwinner-zh/bootloader/tree/master/basic_loader/bsp under a proper GPL license. For the other SoC variants (Allwinner H3) it was more complicated and people had to disassemble the boot0 bootloader binary. If the Pine64 folks can ask Allwinner to open source the bootloader code for A64, then things are going to be a lot easier and more straightforward. Also thus speeding up the development significantly.

---

(01-10-2016, 01:57 PM)tllim Wrote: The developer board and production board are comes from same schematic. The only different is power LED light where developer board is green and production board is red color. We can release the schematic to developer in two to three weeks time.

Thanks for this information and for the schematic release promise. While it is not available yet, could you please tell us how is the power getting supplied to the lower USB connector (the USB OTG one)? Is the VBUS pin directly connected to +5V or is there some kind of switch available to turn it on and off?

(01-10-2016, 03:29 PM)tllim Wrote: The VBUS connect to a power switch LPW5210B5F with pine 4 en pin tie to high and Rset set as 10K. Here is the LPW5210 data sheet link: http://www.kcttek.com/uploads/soft/LPW5210.pdf. Please lets us know on your concern so that we can explore together.

(01-10-2016, 04:47 PM)ssvb Wrote:

(01-10-2016, 03:29 PM)tllim Wrote: The VBUS connect to a power switch LPW5210B5F with pine 4 en pin tie to high and Rset set as 10K. Here is the LPW5210 data sheet link: http://www.kcttek.com/uploads/soft/LPW5210.pdf. Please lets us know on your concern so that we can explore together.

Thanks! I was just curious about the use of USB OTG. If somebody plugs a USB A-A cable to the lower connector, then the PC is going to be providing +5V on VBUS, which is potentially undesirable. But the LPW5210B5F power switch has reverse current protection. Though I'm not quite sure if it is a good idea to have the EN pin pulled up by default (enabling the VBUS power on reset) for the lower USB connector. As for detecting the "device" vs. "host" mode, please have a look at USB0-VBUSDET on the A13 tablet reference schematic. This might be an alternative to the unavailable ID pin.

But admittedly this all is about a rather niche feature, because the majority of users will probably not care about booting over USB.

BTW, can anyone with a Pine64 board and USB A-A cable check if the FEL mode is actually available and paste the "sunxi-fel ver" output?

(01-10-2016, 06:04 PM)tllim Wrote:

(01-10-2016, 04:47 PM)ssvb Wrote:

(01-10-2016, 03:29 PM)tllim Wrote: The VBUS connect to a power switch LPW5210B5F with pine 4 en pin tie to high and Rset set as 10K. Here is the LPW5210 data sheet link: http://www.kcttek.com/uploads/soft/LPW5210.pdf. Please lets us know on your concern so that we can explore together.

Thanks! I was just curious about the use of USB OTG. If somebody plugs a USB A-A cable to the lower connector, then the PC is going to be providing +5V on VBUS, which is potentially undesirable. But the LPW5210B5F power switch has reverse current protection. Though I'm not quite sure if it is a good idea to have the EN pin pulled up by default (enabling the VBUS power on reset) for the lower USB connector. As for detecting the "device" vs. "host" mode, please have a look at USB0-VBUSDET on the A13 tablet reference schematic. This might be an alternative to the unavailable ID pin.

But admittedly this all is about a rather niche feature, because the majority of users will probably not care about booting over USB.

BTW, can anyone with a Pine64 board and USB A-A cable check if the FEL mode is actually available and paste the "sunxi-fel ver" output?

Please PM me with your shipping address, I just want make sure that you are in the developer distribution list. If we missed your name, I will include. Thanks.

Thanks on the tips and I will look into it.

(01-10-2016, 07:20 PM)devilsclaw Wrote: Just to let you know my Idea of how I would use the USB boot, if we can get it running.

this depends on how much SRAM is available on the CPU so it might need to be more complex.

if there is enough SRAM then use the first stage boot loader to get the DRAM and Ethernet initialized, second stage gets pulled through Ethernet, second stage init all hardware that is needed besides DRAM, third stage is the full u-boot,

Quote:and finally load everything from Ethernet into DRAM and boot. this being more of an embedded linux style just for kernel development. or instead of a ramfs image it could also be a NFS boot at that point.

Quote:This would allow a lot faster development of just about anything.