Allwinner H3

Forgot to say, pressing esc on a USB keyboard either directly connected or through a hub does nothing.

That suggests that the USB might not be working at all. Do the capslock/numlock/etc. LEDs toggle when you press the relevant key?

Remember my earlier comments about how boot straight to a command prompt

Remember my earlier comments about how boot straight to a command prompt

I did remember, and went through that before posting. I didn’t think of keyboard LEDs though. I think I have a working corded keyboard to test that with.

In terms of debugging this I think the first thing to do will be a build with SCSIFS exported only. That should avoid that hangup and allow me access to the prompt.

Second thing will be to re enable all the cache and MMU disabling code I disabled, remove the uImage build type, then pound away at trying to boot it as a standalone. This seems less useful.

While USB storage was working, it’s not really needed to solve this issue, so the first option seems the best.

Changed SCSIFS to an export and rebuilt. USB is definitely broken. The modules load, even multiple instances of EHCIDriver, but there don’t appear to be any detected devices on the bus.
The proplem may stem from some alterations I made about the time I was getting sick. IIRC I tried to add support for the OTG port and did some reshuffling of s.USB. Although the added port didn’t work because of the necessity to enable power to the port via an IO pin, I’m pretty sure the rest still worked. I might try a reversion.

I followed up on a suspicion that booting a uImage through bootm in U-Boot somehow had an effect on USB.

What I’ve done is modify my USB.s somewhat to only enumerate the 3 normal USB buses via EHCI and then boot the image via “bootm” and “go”. Because of the layout of the uImage I can just “go 0×42000040” to plop down past the header. If course it took me quite a few attempts to get a complete boot, however my perseverence was rewarded.
The flash disk ony appears in *usbdevices when booted via “go”.

*usbdevinfo yields the same information via both boot methods on the root hubs. Of course the flash drive does not appear.

So not terrible but not great. I’m going to rearrange the devices so they enumerate the same as U-Boot to make things a little easier for me. Beyond that I was expecting issues once I got the boot sorted out. Really it’s a minor inconvenience compared to the massive improvement by being able to boot consistently.

I just want to clarify here that there are 3 normal USB connectors on the Orange Pi PC. Each one is the only device on it’s bus. There is no internal hub.

e: I’m working on adding EHCI port resets to the USB init. If that doesn’t work I’ll set up the ROM to dump the USB registers pre-mmu, so I can run it with “go”, grab the values and work through them.

I haven’t had much time recently but I think I’ve found most of the differences between bootm and go regarding USB. I am however troubled by E_PERIODICLISTBASE and E_ASYNCLISTADDR.
In the case of Pre-MMU “go” they were still pointing to addresses in U-Boot. with “bootm” they were reset with everything else.
I’ve seen the regitsers defined in the header for OMAP4 at least. Not the contents. I don’t know where that gets the contents.

The problem I’m looking at here is how much of the USB hardware do I have to prepare before the USB modules take over and do the rest?
For example if the modules do fill the addresses in those registers, how much do I set up beforehand? What does it enable itself?

If it doesn’t populate them, what on earth do I tell it?

I need to separate out the register printing code so I can run it pre and post MMU. It’s only coincidence that the addresses don’t clobber anything. They are right up near the top of the physical RAM.

All the registers are set up in EHCIdriver.c.ehci. The hal just needs to tell EHCIDriver.c.ehcimodule where to find the registers.

Does your register dump show that the USB controller is still running? If so, halting or resetting the controller early on during your initialisation would be wise. Otherwise as soon as the HAL/OS starts touching memory which the USB controller is programmed to use, bad things are likely to happen (i.e. memory corruption followed by a crash).

If you get to the desktop is this (ehciinfo) any use to you?

It just prints out registers of ehci devices it finds.

Edit: Of course it’s no use you don’t have a keyboard or mouse – silly me.

Before the post yesterday I had finished going through and checking what the register contents meant.

U-Boot when booting via “bootm”, ie the normal mode for booting an OS shuts off absolutely everything USB. I didn’t bother checking OHCI, but EHCI is all zeroed. As are registers, or bits therein of registers in the CCU related to USB clocking and the USB PHY.

It was why I was left looking at them, wondering how much I should enable, and how much the EHCI driver deals with.
I’m guessing that I’d leave the EHCI host stopped because the list pointers mentioned before haven’t been set.
I’m also just guessing that maybe I should set the relevent CCU registers. I’m not fond of guessing with this though.

No desktop yet. Not even attempting that until I have way more core functionality up and running.

Edit:
I tried configuring the CCU registers. It’s not enough. The flash drive still doesn’t appear in *usbdevices. There are actually some control packets in *usbbuses now, however the frequency seems pretty low.

EHCI is all zeroed

Do you mean that both USBSTS and USBCMD are zero?

Haven’t had a free moment to respond.
Here’s a copypaste from part of a text file I’ve been using to work this out. The rest probably wouldn’t mean much to anyone else.

The results I mentioned in the previous post were after setting the bits of the relevent CCU registers.

It’s interesting they didn’t set up the USB OTG port to be enabled in the CCU regs.

e: Remember these are Pre-MMU, so pre RO USB module. The “go” settings lead to working USB (if it completes boot).
Mimicing the CCU regs, but NOT the EHCI regs leads to the results in the previous post. Ie non-functional but still a heartbeat.

via "go"

CCU registers:
USBPHY_CFG_REG 000e0e0e
AHB2_CLK_CFG 00000000
BUS_CLK_GATING_REG0 ee024140
BUS_SOFT_RST_REG0 ee024140
EHCI Operational Register
E_USBCMD 00080b01
E_USBSTS 00000008
E_USBINTR 00000000
E_FRINDEX 000037f3
E_CTRLDSSEGMENT 00000000
E_PERIODICLISTBASE 79f82000
E_ASYNCLISTADDR 79f81d80
E_CONFIGFLAG 00000001
E_PORTSC 00001000

via "bootm"

CCU registers:
USBPHY_CFG_REG 00000000
AHB2_CLK_CFG 00000000
BUS_CLK_GATING_REG0 00024140
BUS_SOFT_RST_REG0 00024140
EHCI Operational Register
E_USBCMD 00000000
E_USBSTS 00000000
E_USBINTR 00000000
E_FRINDEX 00000000
E_CTRLDSSEGMENT 00000000
E_PERIODICLISTBASE 00000000
E_ASYNCLISTADDR 00000000
E_CONFIGFLAG 00000000
E_PORTSC 00000000

edit again: See that result for E_PORTSC in “go”? That unsettles me. The datasheet says that bit is reserved and SBZ.

Bit 12 of E_PORTSC is port power setting. It looks normal for a socket which has nothing plugged into it. For example on my armx6 the empty socket shows

PORTSC 1:            1C001000
     30 Parallel Transceiver select:        0 (ARMX6 only) UTMI/UTMI+
     29 Serial Transceiver Select:          0 (ARMX6 only) 
     28 Parallel Transceiver Width:         1 (ARMX6 only) 
     26 Port Speed:                         3 (ARMX6 only) Undefined
     24 Port Force Full Speed Connect:      0 (ARMX6 only)
     23 PHY Low Power Suspend:              0 (ARMX6 only)
     22 Wake on overcurrent enable:         0
     21 Wake on disconnect enable:          0
     20 Wake on connect enable:             0
     16 Port test control:                  0
     14 Port indicator control:             0
     13 Port owner:                         0
     12 Port power:                         1
     10 Line status:                        0
      8 Port reset:                         0
      7 Suspend:                            0
      6 Force port resume:                  0
      5 Over current change:                0
      4 Over current active:                0
      3 Port enable/disable change:         0
      2 Port enabled/disabled:              0
      1 Connect status change:              0
      0 Current connect status:             0

It looks like the ‘go’ version needs to be stopped before passing it on to RISC OS and the ‘bootm’ version needs USBPHY_CFG_REG initialising before passing it on to RISC OS.

What documentation are you reading? The EHCI specification pdf tells you everything you need to know about EHCI. Is there a technical manual for the computer?

The H3 datasheet is where I got my info. Hm. I misremembered a little. For bit 12 it says “Reserved. These bits are reserved for future use and should return a value of zero when read”. That’s just boilerplate they copypaste into any “reserved” bits.

The “go” version is my reference because USB works fine. I need to work out where to put some code post-init to tell me the USB values then. I’m really interested if the pointers get re-init’d on the “go” one.

Thankfully I got uImage working after however many months, and the only breakage was USB. Using “go” was horrible and incredibly unreliable.

I just grabbed the EHCI specs from Intel. That’s the one I should be looking at, right?

Agin though, how much of it should I be doing before the EHCI module takes over?

Yes the EHCI spec will tell you about EHCI but generally you don’t have to do anything with EHCI.

All the registers in the EHCI spec are set by the EHCI driver so you don’t need to set any of those. If USB has already been configured as it appears to be in the ‘go’ version then you just need just stop (halt) it before changing the MMU in the off chance that E_ASYNCLISTADDR or E_PERIODICLISTBASE are referenced.

The ‘bootm’ version needs the USB host enabled by configuring non ehci registers.

Have you tried the bootm version setting these registers as follows

USBPHY_CFG_REG 000e0e0e
AHB2_CLK_CFG 00000000
BUS_CLK_GATING_REG0 ee024140
BUS_SOFT_RST_REG0 ee024140

ie to the same as the ‘go’ version. That looks as though it enables HCI1 HCI2 and HCI3 – both EHCI and OHCI. After setting the values I would expect E_USBSTS for HCI1,2 & 3 to have bit 12 set to indicate that the controller is halted in which case no other configuration is needed by the HAL.

Thanks for all the input, Colin. This is extremely useful.

I feel I may be explaining myself badly. To say I’ve been busy and distracted is an understatement.

When I got the “bootm” boot far enough to be reporting some control packets, but nothing else of use, it was after setting those registers to those values to mimic what I’m seeing in the “go” boot. Without them, there’s just nothing happening at all.

I’ll have to have another dig through the H3 datasheet to make absolutely sure I didn’t miss any other registers in the CCU or elsewhere.

I’ll have another go at it when I have a few minutes.

When you say stop(halt) I’m guessing you mean stopped using b0 of USBCMD (start/stop), and b12 of USBSTS is 1.
Would you believe last week I wrote code to ensure that was the case for the USB hosts, then deleted it without backing it up because I decided that the USB module would probably already do that. Also no it’s not the code on GitHub. That was the code equivalent of thinking out loud. It isn’t called in that version of the source anyway which is a good thing because it’s wrong haha.

e: I also want to make clear that the “bootm” and “go” versions are the same binary. It’s just I load via “go” from 0×42000040 to skip the uImage header. I can load it a little lower and then execute from 0×42000000 but it doesn’t make a difference. It makes comparisons easy. That’s for sure!

I had a quick shot at it today. The code is really hacky for USB_Init but I just wanted to give the registers a kick. it didn’t make a difference.

No idea if the link below will work. I think all the actual changes were made to s.USB

https://raw.githubusercontent.com/experimentech/RISC_OS_AWH3/master/AWH3Dev/Castle/RiscOS/Sources/HAL/AWH3/s/USB%2Cfff

To state the obvious usb isn’t working at all when running the riscos image with bootm. The output you are getting from usbbuses is just from the registering of the host controllers when the ehci driver reads the HAL controller info. The odd control transfers you see will be fake ones as the ‘root’ hubs emulate attached hubs so any control transfers sent by the usbdriver to the root hubs are not ‘real’ control transfers ie nothing is sent via the controller.

When run with bootm if writing to the ECHI registers doesn’t actually change them and they stay as 0 then as the EHCI driver doesn’t check USBSTS to see if it is actually halted and then doesn’t check USBCMD to see if the host controller is actually started then it is possible for the EHCIDriver to register a host controller which isn’t working.

When you use go to run the image USB does work – you’ve had a drive connect.

You could try a ‘usb stop’ before using ‘go’ from uboot.

Using “usb stop” before executing the ROM with “go” appears to yield the same result as executing “bootm”. Ie no functional USB.

Connector still has a “go” test in the buffer.

*usbbuses                                        
Transfers (3 buses):                                                            
Bus    Control Isochronous       Bulk  Interrupt                                
  1         21           0          0          0 
  2         21           0          0          0 
  3         44           0          0          0 
*usbdevices                                      
No. Bus Dev Class Description                                                   
  1   1   1  9/ 0 Built-in EHCI root hub                                        
  2   2   1  9/ 0 Built-in EHCI root hub
  3   3   1  9/ 0 Built-in EHCI root hub
  4   3   2  0/ 0 General USB Flash Disk

When I did have SCSIFS built into the ROM I can confirm it could access the USB drive when running in “go” as it created directories without issue, and saved and loaded a BASIC file with some asm content just fine too.

When I have some time I’ll add in some code so it’ll spit out the registers under some other circumstances so I can see what’s working a little better.

I also checked the H3 manual again. As far as I can tell, I’ve got all USB related registers accounted for.

I also checked the H3 manual again. As far as I can tell, I’ve got all USB related registers accounted for.

In that case, it’s probably worth looking at the u-boot sources to work out what “usb stop” is doing for the H3 / Orange Pi.

cough Nobody saw that. I totally didn’t have a pre-MMU address in there.

This result for “bootm” makes more sense. Doesn’t work though. But at least it’s displaying the right addresses.

About to init USB clocks etc
CCU registers:
USBPHY_CFG_REG      00000000
AHB2_CLK_CFG        00000000
BUS_CLK_GATING_REG0 00024140
BUS_SOFT_RST_REG0   00024140
EHCI Operational Register   
E_USBCMD            00000000
E_USBSTS            00000000
E_USBINTR           00000000
E_FRINDEX           00000000
E_CTRLDSSEGMENT     00000000
E_PERIODICLISTBASE  00000000
E_ASYNCLISTADDR     00000000
E_CONFIGFLAG        00000000
E_PORTSC            00000000
BUS_CLK_GATING_REG0 set
BUS_CLK_GATING_REG0  value: ee024140
BUS_SOFT_RST_REG0 set
BUS_SOFT_RST_REG0 value: ee024140
USBPHY_CFG_REG set
USBPHY_CFG_REG value: 000e0e0e
USB PreInit finished.

The rough notes I was taking while looking at the registers.

https://pastebin.com/raw/zZ98yDgD

These are all from before the module starts. I haven’t worked out a neat way to call something from the HAL after modules have been initialised.

These bootm values from the file look correct.

"bootm"

About to init USB clocks etc
CCU registers:
USBPHY_CFG_REG      00000000
AHB2_CLK_CFG        00000000
BUS_CLK_GATING_REG0 00024140
BUS_SOFT_RST_REG0   00024140
EHCI Operational Register      
EHCI_USBCMD            00000000
EHCI_USBSTS            00000000
EHCI_USBINTR           00000000
EHCI_FRINDEX           00000000
EHCI_CTRLDSSEGMENT     00000000
EHCI_PERIODICLISTBASE  00000000
EHCI_ASYNCLISTADDR     00000000
EHCI_CONFIGFLAG        00000000
EHCI_PORTSC            00000000
BUS_CLK_GATING_REG0 set         
BUS_CLK_GATING_REG0  value: ee024140
BUS_SOFT_RST_REG0 set           
BUS_SOFT_RST_REG0 value:    ee024140
USBPHY_CFG_REG set               
USBPHY_CFG_REG value:       000e0e0e
USB PreInit finished.
CCU registers:
USBPHY_CFG_REG      000e0e0e
AHB2_CLK_CFG        00000000
BUS_CLK_GATING_REG0 ee024140
BUS_SOFT_RST_REG0   ee024140
EHCI Operational Register      
EHCI_USBCMD            00080b00
EHCI_USBSTS            00001000
EHCI_USBINTR           00000000
EHCI_FRINDEX           00000000
EHCI_CTRLDSSEGMENT     00000000
EHCI_PERIODICLISTBASE  00000000
EHCI_ASYNCLISTADDR     00000000
EHCI_CONFIGFLAG        00000001
EHCI_PORTSC            00001000

Are they the values immediately after setting the CCU registers? The registers are in the ideal state for passing to the EHCI driver.

You should not alter any EHCI registers.

PORTSC is correct – the documentation you are reading is wrong.

FRINDEX is a counter so is always changing when EHCI is started.

I had to check, because there has been so much tinkering.

There are a couple of things I am doing to the EHCI registers, which can probably be removed. Setting the start / stop bit of EHCI_USBCMD to 0, and setting the EHCI_CONFIGFLAG.
The reason I set them up was I was bothered by both start / stop and halt being 0. As for the config flag, I’m sure I had some idea at the time.

Just disabled that EHCI register tweaking code, built and ran it. No functional difference. It still doesn’t see the USB drive.

Here’s the “bootm” output post CCU fiddling, and without the pointless EHCI fiddling.

If it still looks good, maybe I had a minor slip-up in HAL_USBControllerInfo. Enough to allow it to work if some kind of init has already taken place.

EHCI1 Operational Register      
EHCI_USBCMD            00080b00
EHCI_USBSTS            00001000
EHCI_USBINTR           00000000
EHCI_FRINDEX           00000000
EHCI_CTRLDSSEGMENT     00000000
EHCI_PERIODICLISTBASE  00000000
EHCI_ASYNCLISTADDR     00000000
EHCI_CONFIGFLAG        00000000
EHCI_PORTSC            00003000
EHCI2 Operational Register      
EHCI_USBCMD            00080b00
EHCI_USBSTS            00001000
EHCI_USBINTR           00000000
EHCI_FRINDEX           00000000
EHCI_CTRLDSSEGMENT     00000000
EHCI_PERIODICLISTBASE  00000000
EHCI_ASYNCLISTADDR     00000000
EHCI_CONFIGFLAG        00000000
EHCI_PORTSC            00003000
EHCI3 Operational Register      
EHCI_USBCMD            00080b00
EHCI_USBSTS            00001000
EHCI_USBINTR           00000000
EHCI_FRINDEX           00000000
EHCI_CTRLDSSEGMENT     00000000
EHCI_PERIODICLISTBASE  00000000
EHCI_ASYNCLISTADDR     00000000
EHCI_CONFIGFLAG        00000000
EHCI_PORTSC            00003000

edit: I just spotted a mistake in HAL_USBControllerInfo. I’ll report findings when I fix it (or probably multiples). Looks like when I changed how my code worked I failed to load something to a register which is then compared, which would lead to some kind of result, possibly just dropping through.

e again: No. It’s just a passed value. But something doesn’t look right in there.

I’m putting it away for the day. It’s been a ride. I broke it and now I’ve made it back to the controllers appearing in *usbbuses and *usbdevices, but no USB drive. Progress was made though. I found some glaring errors in HAL_USBControllerInfo and essentially rewrote it.

https://raw.githubusercontent.com/experimentech/RISC_OS_AWH3/master/AWH3Dev/Castle/RiscOS/Sources/HAL/AWH3/s/USB%2Cfff

Ignore the USB OTG code. It’s broken and doesn’t get executed. That’s a job for later. Surely there’s still some major omission here?

e: My source tree doesn’t have the USB OHCI module in it. That wouldn’t be helping.

e again:
Well…

Okay maybe I’ll just try temporarily removing the OHCI controllers again or something. No idea.

init mod USBDriver                                                              
init mod EHCIDriver                                                             
init mod OHCIDriver => error: PCI device doesn't exist