USB OTG Boot

[tllim]

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.

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.

---

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.

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.

[Andrew2]

Sorry, I don't get it: You say the boards sent out to devs are based on the same schematics as the mass production batch scheduled for February? And fear also people might get confused if you publish different revisions of the schematics (which is exactly no problem if you use version numbers). And you speak about 'satisfying curiousity' when it's about helping devs getting Linux support done for your boards in reality?

That's all just weird and not the best sign regarding your 'open source' claims (towards Allwinner), isn't it?

[ssvb]

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

---

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?

[tllim]

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

---

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?

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.

[ssvb]

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?

[tllim]

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.

[devilsclaw]

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.

Thanks for the update on the info for the schematic. I don't know why people are trying to inflame this at ever corner. also thamls ssvb for the info

---

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

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

[ssvb]

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,

The whole U-Boot can boot over USB just fine and that's how it is currently implemented. The only real reason to switch from the USB FEL protocol (implemented in the boot ROM) to some other communication method is the transfer speed. The FEL transfer speed is around ~900 KB/s for the other Allwinner SoC variants, you can find this information in the SoC support status table. And because the U-Boot size is only around 300 KB, we don't gain much from switching to Ethernet too early.

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.

That's how it works now on the older Allwinner chips (A10/A13/A20/A31/...). After U-Boot is loaded, you are free to use any method to load the Linux kernel and rootfs. Ethernet is just one of these methods. NFS boot works and many people are using it. However the beauty of USB OTG is that Ethernet is not strictly required. You can boot everything over the same USB cable and use cdc_ether for NFS. This is particularly useful for tablets.

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

That's a chicken/egg problem :-) We can do this if we have full U-Boot support with all the bells and whistles, including the Ethernet driver. Then for mounting NFS root you need the Ethernet driver in the Linux kernel too. But when we already have everything, there is no development to speed up anymore.

[janjwerner]

OTG is available on the upper USB port. I used cheap USB-A to USB-A cable
(http://www.amazon.com/gp/product/B000R4L4CM) and it works just fine.

Code:

jjwerner@SantokuVM:~/sunxi-tools$ sudo ./sunxi-fel version
AWUSBFEX soc=00001689(unknown) 00000001 ver=0001 44 08 scratchpad=00017e00 00000000 00000000

[ssvb]

Thanks janjwerner! In fact I have already received my Pine64 board yesterday and have tested everything myself, sorry for not dropping a notice here sooner. It was me who added the initial FEL mode information to the Pine64 page at the linux-sunxi wiki. Now I'm working on getting full A64 support in sunxi-tools.

Hopefully we will get something usable for Pine64 in the U-Boot bootloader too. Or at least get a better understanding about what is missing and what needs to be asked from Allwinner.