My T113-S4 board is finally ready for further testing

[pcprogrammer]

Edit: See this post https://www.eevblog.com/forum/projects/i-can-use-a-second-set-of-eyes-on-my-t113-s4-design/msg6253505/#msg6253505 for the follow up.

Edit: See this post https://www.eevblog.com/forum/projects/i-can-use-a-second-set-of-eyes-on-my-t113-s4-design/msg6248775/#msg6248775 for the latest problem.

---------------------------------------------------------------------------------------------------------------
Original post
---------------------------------------------------------------------------------------------------------------

I'm working on a design that uses an Allwinner T113-S4 MCU in combination with gigabit Ethernet, where the latter is completely new for me, so a review of what I have so far would be greatly appreciated.

There are four sheets of which the first one shows the power supply and connectors for a 7 inch display and accompanying touch panel. I have used this part in my F1C200s sound board project and is fully tested as such.

The second sheet shows the MCU with several expansion connectors and all the power decoupling. Most of this I believe to be correct based on other schematics and datasheets I found. Do have a concern about grounding the TV supply pins though. These parts of the chip are not used, and I think it is the same as in the F1C200s, where I left them floating. On the F1C200s I measure about 20mV on the TV-VCC pin and when shorted to ground nothing happens, so guess it to be fine.

The data sheets are very vague for sure. The T113-S4 is pin compatible to the T113-S3, but has more memory and an extra Risc-V core. No datasheet to be found for the S4. 
Datasheet of T113-S3: https://linux-sunxi.org/File:T113-s3_datasheet_v1.6.pdf
User manual of T113-S3: https://mangopi.org/_media/t113-s3_user_manual_v1.3_.pdf

The third sheet shows the Ethernet PHY with the RJ45 jack and here I'm not sure if things are properly designed. Based it on another schematic I found and the datasheets of the different parts. The schematic I copied parts from is for the coral dev board and is attached here. This section I'm least confident about.

The fourth sheet is for the power supply and the battery, USB OTG and the power on/off part have also been used in the F1C200s board, so tested and working as intended. The rest is fairly standard buck and boost converter stuff.

Attached are the PNG's of the four sheets and the two schematics I used as guide lines.

Edit: modified the title to address a new issue on this design.

[pcprogrammer]

Here is some additional stuff, like the PDF of the schematic I made and datasheets of some used parts.

[PGPG]

I have designed only one device with 10/100M Ethernet. For WIZNET IC I had to use external bus termination resistors.
Do your U4 (or RJ2) have them integrated?

[pcprogrammer]

I have designed only one device with 10/100M Ethernet. For WIZNET IC I had to use external bus termination resistors.
Do your U4 (or RJ2) have them integrated?

Yes the RTL8211FD has those resistors on board, at least that is what I found in the datasheet, and they are also not in the schematic I used as a reference.

[tdcp]

I have been working on my own Allwinner T113 design, this time the T113-i (BGA package, external DDR3 memory, and some other pins exposed but the die is identical as far as I can tell).

You mentioned it in your initial message as well, but it was interesting to see you have shorted to GND all of the unused pins MICIN, FMIN, LINEIN, TP-xx, and specifically VCC-TVIN and VCC-TVOUT. Having trawled through the datasheets and user manual for both the T113-i and T113-S3 myself I have found no indication of how to do this properly for the unused interfaces . Wondered if you had done any testing on this with your T113-S4 design in the end? I would be interested to know so I can "borrow" the knowledge for my own design!

[pcprogrammer]

Sorry for a bit late reply, but I have been fully consumed by this project. I could not find any information about what to do with those unused pins and decided to ground most of them based on some test I did with the F1C200s board I made. There it seem to do no harm, and my guess is that as long as the clocks for these parts are not enabled it should not make a difference.

Attached is the schematic I used for the board I just finished the design of. Also attached a pdf of the outer layers of the design.

For me a new experience to do things like differential pairs and length matching, so I hope the board will work. But I have to have it made first, and as I'm cheap it is going with the cheapest shipping option, giving it a couple of weeks of delay.

A pointer on a thing I found on the S3 and S4 which may also apply to the I version, it has several internal supply voltage regulators that can be used, and one is per default on. This is the one for the AVCC voltage, so definitely should not be grounded. Another one that can be enabled is for HPVCC.

I based my design mostly on other schematics I have found on the internet, but these all allowed for the use of the TV and audio parts, where as I'm only interested in the headphone output.

Hope this is of some help. 

[pcprogrammer]

The board arrived and has been soldered for most parts. Left the Ethernet PHY and the RJ45 connector of the board for now to be able to test the T113-S4 first.

I had hoped for it to run the Tina Linux sd card I made for the mango pi I have that uses the T113-S3, but for some reason it does not. Probing with a scope, I can see that the MCU accesses the sd card, but it still falls back to FEL mode indicating that there is no proper boot loader present.

Fortunately I can test the working of the MCU with FEL, but a simple GPIO toggle test I wrote does not work when loaded into sram with the use of FEL. So more research is needed to get this board fully up and running. Luckily there is plenty of source code around for this chip.

With the use of FEL I did manage to toggle GPIO pins by writing to the appropriate registers. Thus far it looks like the board is working.

The soldering of the T113-S4 at least was not as hard as the F1C200s on the board I designed for that one. Boy do I suck at that QFN88 soldering, but I finally managed to get the version two board working, after going through several F1C200s chips. 

[Zengfh]

Great job! Your T113-S4 is working normally!
 Your RTL8211 is not welded. I attach my schematic diagram!

[pcprogrammer]

Great job! Your T113-S4 is working normally!

Not so sure about that, but I'm making progress in discovering more about the chip. With the Cortex-A7 being new to me it takes a lot of searching to find out what is going on, even though the Allwinner boot stuff looks similar to what the F1C200s uses, it is a different architecture to some extend.

Your RTL8211 is not welded. I attach my schematic diagram!

I left it of to be able to first test the MCU and get a proper Linux setup working to make use of the RTL8211. It will take some time to get to that.

[pcprogrammer]

I'm starting to get somewhere. 

After successfully loading some simple code to a portion of the SRAM of the chip via the FEL system, I also managed to start a simple program from the SD card. A bit of a problem with the Allwinner chips is the sparse documentation. What I needed to find was the correct location of where to allocate the startup code. The FEL system is a bit weird, where it either uses the scratchpad location returned by the chip, which is 0x00045000 for the T113, or address 0x00028000, where as to start from SD card 0x00020000 has to be used, because that is where the BROM appears to load the data to. 

Finding this required trawling to the code of xfel and awboot. (https://github.com/xboot/xfel, https://github.com/szemzoa/awboot)

So now it is looking into the DDR3 memory of the chip, but probably requires working through the clock system first, to have it run at some higher speed. Without setting the clock, my simple code gives an asymmetric square wave on two GPIO pins with a frequency of 2.22MHz. See attached picture.

This is the simple code it is running.

Code: [Select]

  PORTG->CFG[0] = 0x11FFFFFF;
  PORTG->DATA   = 0x000000C0;
 
  while(1)
  {
    PORTG->DATA = 0x00000000;
    PORTG->DATA = 0x000000C0;
  }

Yes I used my FNIRSI 1013D with my own code for this since it boots quick and takes little desk space. 

[Zengfh]

I understand your work. You want to use the OS-free method like xboot on T113-S4, right? I have no experience in this field. T113-S3/S4 has only been debugged under Linux.
 FNIRSI 1013D is great. It is very small and suitable for the desktop.

[pcprogrammer]

I understand your work. You want to use the OS-free method like xboot on T113-S4, right? I have no experience in this field.

I like to do things completely bare metal, but that takes a lot of effort on something almost completely new for me. My experience with the Allwinner F1C100s (F1C200s) helps for sure, but getting to know all the ins and outs of the T113 clock system takes time.

Yesterday I got  a UART up and running via the FEL download, but it does not work when loaded from the SD card. Most likely due to the ABP1 clock, so I have to add setting up that one in my SD card startup code.

It is a journey slowed down due to procrastination caused by my chronic fatigue syndrome.

FNIRSI 1013D is great. It is very small and suitable for the desktop.

Great is not the right word for the FNIRSI 1013D. 

With the open source firmware it is somewhat ok, but the hardware design is rather crap. How do I know, well I reverse engineered the whole thing and wrote the first version of the open source firmware for it.

T113-S3/S4 has only been debugged under Linux.

Do you have a Linux SD card image for the T113-S4 with gigabit ethernet support that you are willing to share?

[pcprogrammer]

I'm having a serious problem with my board and the internal SDRAM of the T113-S4. After a lot of testing and trying to run the SDRAM without auto scanning for rank and DQ and getting nowhere, I decided to look at some external signals and compare them with the T113-S3 (mango pi) board I have.

What I found is that on the T113-S3 the DZQ resistor is only probed once on initialization of the memory. A pulse of 0.8V and 1.2us duration. On the T113-S4 the pulse is repetitive and only about 200ns wide. Same 0.8V. It repeats with a rate of about 126kHz.

I measured the resistor and it shows 240.4 Ohm on my old Agilent U1242A. The connections with the chip look good, because it shows just slightly higher resistance when probing the pin on the chip and the ground on some other part of the board.

What can cause this issue?

A bad ground connection on the chip? The rest of the T113-S4 is working without problems though. I can read registers, toggle IO pins, send data via a UART, etc.

I will have to solder up a second board to see if another chip shows the same problem, to rule out a bad chip. 

[pcprogrammer]

It took a lot of working with copilot and searching for code actually targeted at the T113M4020DC0 (Latest version of the T113-S4) to get the SDRAM up and running. I still have to further reverse engineer the startup code I found, to see where it differs from the source code I'm trying.

Working with copilot is a journey on its own, but I did find it useful. One still has to know about the subject on hand and verify what copilot spits out, because it does get things wrong from time to time. Without it, it would have taken me longer to get this far.

The code I found is targeted at this Ebyte ECB31-PB: T113-S3/S4 board https://www.cdebyte.com/products/ECB31-PB2E8-I also mentioned here: https://www.cnx-software.com/2025/08/19/ebyte-ecb31-pb-a-raspberry-pi-model-a-sized-industrial-sbc-with-allwinner-t113-s3-or-t113-s4-soc/

The available binary images have several boot loaders in them and are based on Allwinner TOC (table of contents) structure, on which copilot was a big help in extracting one of the actual eGON.BT0 boot loaders. Had to change it to work with UART4 instead of UART0 and was very pleased to see it run through the SDRAM setup without errors.

Now it is reverse engineering the code and the used data to get working source code and to fully verify my board, set up a Linux image that can test the gigabit Ethernet.

Edit: I forgot to mention that changing the board (second on I soldered) to have the TV power pins supplied with their respective voltages did not make a change, and that the found boot loader image works on the board without the bodges.

[pcprogrammer]

It took a lot of reverse engineering of the assembly of the SPL I found, but I finally got to the root of the problem.

Working backward from where the PHY is told to do the ZQ training did not lead to a solution, because there was only one other command being issued to the PHY, and even after fixing all the differences in the registers of both the PHY and the controller did not lead to working memory with the source code I'm trying with.

So I started from the beginning again to trace down the path taken through the code and correct every bit found mismatched between the binary SPL and the AWboot source code. It took me down to the function that does some remapping.

Code: [Select]

static const uint8_t ac_remapping_tables[][22] =
{
  [0] =  {0},
  /* FPGA Verify DDR REMAP */
  [1] = {0x1, 0x9, 0x3, 0x7, 0x8, 0x12, 0x4, 0xD, 0x5, 0x6, 0xA, 0x2, 0xE, 0xC, 0x0, 0x0, 0x15, 0x11, 0x14, 0x13, 0xB, 0x16}, // Generic DDR3 Type1
  [2] = {0x4, 0x9, 0x3, 0x7, 0x8, 0x12, 0x1, 0xD, 0x2, 0x6, 0xA, 0x5, 0xE, 0xC, 0x0, 0x0, 0x15, 0x11, 0x14, 0x13, 0xB, 0x16}, // Generic DDR3 Type C
  [3] = {0x1, 0x7, 0x8, 0xC, 0xA, 0x12, 0x4, 0xD, 0x5, 0x6, 0x3, 0x2, 0x9, 0x0, 0x0, 0x0, 0x15, 0x11, 0x14, 0x13, 0xB, 0x16}, // Generic DDR3 Type 8
  [4] = {0x4, 0xC, 0xA, 0x7, 0x8, 0x12, 0x1, 0xD, 0x2, 0x6, 0x3, 0x5, 0x9, 0x0, 0x0, 0x0, 0x15, 0x11, 0x14, 0x13, 0xB, 0x16}, // Generic DDR3 Type 9
  [5] = {0xD, 0x2, 0x7, 0x9, 0xC, 0x13, 0x5, 0x1, 0x6, 0x3, 0x4, 0x8, 0xA, 0x0, 0x0, 0x0, 0x15, 0x16, 0x12, 0x11, 0xB, 0x14}, // Generic DDR3 Type bf
  /* ASIC Chip */
  [6] = {0x3, 0xA, 0x7, 0xD, 0x9, 0xB, 0x1, 0x2, 0x4, 0x6, 0x8, 0x5, 0xC, 0x0, 0x0, 0x0, 0x14, 0x12, 0x0, 0x15, 0x16, 0x11}, // DDR2
  [7] = {0x3, 0x2, 0x4, 0x7, 0x9, 0x1, 0x11, 0xC, 0x12, 0xE, 0xD,0x8, 0xF, 0x6, 0xA, 0x5, 0x13, 0x16, 0x10, 0x15, 0x14, 0xB}, // DDR3 D1-H
  [8] = {0x2, 0x13, 0x8, 0x6, 0xE, 0x5, 0x14, 0xA, 0x3, 0x12, 0xD, 0xB, 0x7, 0xF, 0x9, 0x1, 0x16, 0x15, 0x11, 0xC, 0x4, 0x10}, // DDR3 H133
  [9] = {0x1, 0x2, 0xD, 0x8, 0xF, 0xC, 0x13, 0xA, 0x3, 0x15, 0x6, 0x11, 0x9, 0xE, 0x5, 0x10, 0x14, 0x16, 0xB, 0x7, 0x4, 0x12}, // DDR2 H133
};

/*
 * This routine chooses one of several remapping tables for 22 lines.
 * It is unclear which lines are being remapped. It seems to pick
 * table cfg7 for the Nezha board.
 */
static void mctl_phy_ac_remapping(dram_para_t *para)
{
  const uint8_t *cfg;
  uint32_t fuse, val, chipid;
 
  /*
   * It is unclear whether the LPDDRx types don't need any remapping,
   * or whether the original code just didn't provide tables.
   */
 
  if(para->dram_type != SUNXI_DRAM_TYPE_DDR2 && para->dram_type != SUNXI_DRAM_TYPE_DDR3)
    return;
 
  fuse = (readl(SUNXI_SID_BASE + 0x28) & 0xf00) >> 8;
  chipid = (readl(SUNXI_SID_BASE) & 0xffff);
 
  debug("DDR efuse: 0x%x\r\n", fuse);
  debug("chip id efuse: 0x%x\r\n", chipid);
 
  if(para->dram_type == SUNXI_DRAM_TYPE_DDR2)
  {
    if(fuse == 15)
      return;
   
    if(fuse == 10) // Support D1s
      cfg = ac_remapping_tables[0];
   
    cfg = ac_remapping_tables[6];
  }
  else
  {
    if(para->dram_tpr13 & 0xc0000)
    {
      cfg = ac_remapping_tables[7];
    }
    else
    {
      switch(fuse)
      {
        case 8:
          cfg = ac_remapping_tables[2];
          break;
         
        case 9:
          cfg = ac_remapping_tables[3];
          break;
         
        case 10:
          if(chipid == 0x6800)
          { // 0x6800 is T113-S4 no remap
            cfg = ac_remapping_tables[0];
          }
          else
          {
            cfg = ac_remapping_tables[5];
          }
          break;
         
        case 11:
          cfg = ac_remapping_tables[4];
          break;
         
        default:
        case 12:
          cfg = ac_remapping_tables[1];
          break;
         
        case 13:
        case 14:
          cfg = ac_remapping_tables[0];
          break;
      }
    }
  }
 
  val = (cfg[4] << 25) | (cfg[3] << 20) | (cfg[2] << 15) | (cfg[1] << 10) | (cfg[0] << 5);
  writel(val, (MCTL_COM_BASE + MCTL_COM_REMAP0));
 
  val = (cfg[10] << 25) | (cfg[9] << 20) | (cfg[8] << 15) | (cfg[7] << 10) | (cfg[6] << 5) | cfg[5];
  writel(val, (MCTL_COM_BASE + MCTL_COM_REMAP1));
 
  val = (cfg[15] << 20) | (cfg[14] << 15) | (cfg[13] << 10) | (cfg[12] << 5) | cfg[11];
  writel(val, (MCTL_COM_BASE + MCTL_COM_REMAP2));
 
  val = (cfg[21] << 25) | (cfg[20] << 20) | (cfg[19] << 15) | (cfg[18] << 10) | (cfg[17] << 5) | cfg[16];
  writel(val, (MCTL_COM_BASE + MCTL_COM_REMAP3));
 
  val = (cfg[4] << 25) | (cfg[3] << 20) | (cfg[2] << 15) | (cfg[1] << 10) | (cfg[0] << 5) | 1;
  writel(val, (MCTL_COM_BASE + MCTL_COM_REMAP0));
}

Could have caught  it earlier if I had included these MCTL_COM_REMAP registers in my debug output, but missed them in the process of looking for what to print. 

When I was in the process of comparing code, I noticed the comment "0x6800 is T113-S4 no remap" and realized that this might be the issue, because the ID of the chips I have is 0x7200. Checking the SPL code verified that no remapping is used, and when changed to check on that ID, the memory training runs smoothly and just the same as with the SPL or the S3 chip for that matter.

It took its time, but I have learned a lot.

Now it is time for the next step. Getting a Linux variant up and running for this board.

[pcprogrammer]

It is a slow process of looking for documentation or example code and trying to make parts of the system work. As I still have not been able to get a working Linux build for my board and hoping to get the proper SDK via the Allwinner bulletin board website, I have been working on easier  parts of the chip. The Linux is needed for testing the gigabit ethernet.

The bulletin board website is here: https://bbs.aw-ol.com/
I registered on that site and had to first become a level 2 user to be able to download, but when I reached it and tried downloading, the git process did not authenticate. According to Copilot, I need to be a level 3 user to upload my SSH key and use that for getting the SDK. I noticed just now that I'm leveled up to be a level 3 user, so have to see if Copilot was right. It took many days before the posts I made on that site to be approved, but that raised my point count by 125. 

In the mean time I concentrated on the display part of the system. Getting TCON_LCD up and running was not to hard, due to enough documentation and a lot of similarities with the F1C100s chip. But to get an image from memory onto the LCD requires setting up the display engine, which differs from the one used in the F1C100s chip. It took reverse engineering of uboot and finding some DE2.0 specifications to get things going, but it was not easy. Only when Copilot brought this repository (https://github.com/robots/allwinner_t113/tree/master) to my attention, that things started to come together. It has more or less bare metal coding for the T113-S2 (64MB version) and directly interfaces with the display engine. Not like uboot, where things are hidden behind function pointers and device tree configuration.

The next parts, like audio adc and dac or MIDI, should be easy enough. I already have UART up and running, so MIDI is just setting the correct baudrate and connecting the needed UART to the used pins. The audio part is probably also simple, because the I2S peripheral matches the F1C100s one, and I have already running code on that one.

Still plenty to do for sure.

[pcprogrammer]

I finally got Tina Linux running on my board, but it was a hell of a ride.

First of all this whole embedded Linux stuff is kinda virgin territory to me and getting the right SDK turned out to, in one way, be a nightmare, to only lead me back to the original archive I found when I received the S3 based board I bought. See this article https://ohmbedkernel.substack.com/p/embedded-linux-with-t113-s3-part. At first it looked like the SDK was not complete, so I tried to find other options, like the D1-H tree. Converting the latter to do t113 did not fly so well, but with the gain of knowledge and helped by Copilot I managed to do a build in this first archive.

Had to fix several build issues due to working on a newish Linux Mint build compared to the Ubuntu 16 version mentioned in that ohmbedkernel article. But then the configuration mud began. Boy what a mess that is. To get things changed, like for instance the UART the system outputs on, takes a mod in four different places, to only fail when moved to UART4. (Have not tested with other UART than 0 and 4) For some unknown reason the kernel will not boot when uboot is set to UART4, so I now have a version where SPL and the kernel are on UART4 and uboot is set up for UART0 but since the pins are not setup for this there is no output. The SPL sets up the pins for the UART uboot is using.

A very big hurdle was the fact that the SDK set for the S3 board uses optee and a secured kernel. This is why the image that works on the S3 board fails on my S4 board. There probably is some check value fused on the S3 board, that my S4 does not have.

After many failed attempts and misguidance from Copilot, yes AI ain't perfect, I was very close to throw in the towel.

I gave it one last try, by starting fresh on the S3 board and applying all the knowledge gained to create an image without optee and a non secure kernel. This succeeded and inserting the SD card in my board did start the kernel to only fail on missing root file system partition device. What the  was going through my mind. But then I realized that the S3 board has the card detect switch wired to an IO pin, where mine does not. So I tied down that pin, which I have on an IO connector, et voila the kernel booted into its prompt.

Now comes the joy of modifying the device tree settings to fully match my board and especially the ethernet RGMII pinout.

With all this fighting open source #@$%&!, the quest for writing my own bare metal code for this chip came to a halt.

On the subject of Copilot I can say that it has its use, but if one has no skills of ones own, it won't get you far. It required a lot of knowledge from my end to get this to where it is now. Most likely due to the fact that there are different versions of this Allwinner Tina Linux setups in use, you get mixed results. Copilot telling to check so and so directory, to only find it not being in the tree you are using.

But it is better than using google to search for solutions and having to wade through numerous hits of useless data.

[pcprogrammer]

The Linux story, although not completely done, comes to an end.

I'm very happy with the fact that the gigabit ethernet works, but what a ride it was to get this far. Getting DRAM initialization up and running, fixing the Tina Linux build issues, u-boot communication issues, optee and secure Linux issues and the last hurdle getting the ethernet interface up and running.

Since QFN soldering is not one of my strong points, the first try brought some shorts with it. Should have checked on those before running the board of course, but under the microscope it all looked ok. Nothing broke, luckily, but the process of getting things to work did not became easier. 

The DTS configuration was not to bad, with the support of Copilot, although at times it does not help either. When I first tried to bring up the phy it just failed and measurements showed that the reset signal was held low. This is where the DTS is counter intuitive. The reset needs to be low to reset the device, so Copilot showed this "phy-rst = <&pio PE 10 GPIO_ACTIVE_LOW>;", which looks reasonable, but it has to be "phy-rst = <&pio PE 10 GPIO_ACTIVE_HIGH>;". Without the reset line in the DTS the interface came up though, so I continued testing without it. Things looked good, the bring up showed 1Gbps/Full on a gigabit link and 100Mbps/Full on a fast ethernet link.

But there was no communication, so I started scoping the signals and at some point noticed that the RXCTL and the next to it RXD0 showed the same signal, which struck me as weird since the TXCTL signal showed a single pulse high for the full communication time. The dmm proved me right, a short between those lines. Resoldered the phy and checked for shorts to find none. Unfortunately still no communication, despite seeing both TXCTL and RXCTL pulses. The clocks all looked good too.

Then I learned that one can check the different stats on the RX side:

Code: [Select]

cat /sys/class/net/eth0/statistics/rx_packets
cat /sys/class/net/eth0/statistics/rx_crc_errors
cat /sys/class/net/eth0/statistics/rx_length_errors
cat /sys/class/net/eth0/statistics/rx_missed_errors

And those told me that packets were being received without any errors. At that point I grabbed an USB ethernet dongle and connected that. It only did 10Mbps/Half, but good enough to do some tests. This showed that there was data coming from the board, but it had weird errors, like some bits in the mac flipped and the wrong frame type. On 100Mbps this failed, and then, totally by accident, it started working. I had touched the board with my finger to see if the phy was warming up. I started to investigate this further and found it to be repeatable. Turned out that with a proper reset the link went down for a moment and then came up fully working.

So back to the DTS to try to fix this. Copilot came with a new set of DTS instructions and those had to be it for sure. Nah no dice. Did not even generate a pulse. So I reverted to some earlier suggestion and flipped the active state to high. Now I see a proper reset of 65ms low, but it still does not work directly. Only when I manually reset the  phy again, while it is up, does it work. 

But all this now shows that the board is good and after the manual reset it works without problems, even on a gigabit link. And that is what it was about, checking that the hardware is good.

The conclusion is that this first spin of the board is proper so far. The soc works, DRAM works, the LCD part works, the SD card works, ethernet works, UART4 works, USB device part (otg) works. What is left to test is the I2S peripherals and the USB host port.

[pcprogrammer]

Ooh what a mistaka to maka 

I did not check the USB host pinout. Just took a type A connector from the library and hooked it up based on the pin names, and they turn out to be reversed, so I have to desolder the connectors and solder them on the bottom side of the board. Luckily the insertion of an USB stick immediately killed the power and no damage done to the stick or the board.

Should have, could have, would have are all to late now. 

Something to fix in a respin that I already had in mind. This board is only suited for 50 pin parallel RGB LCD panels, and I also want it to support MIPI DSI and LVDS panels. Another change is a less quick power on switch, so a RC delay in that section.