Allwinner H3

I’ve been looking at the HAL USB sources. I’m a little confused by something in HAL_USBControllerInfo. It is there in both iMx6 and OMAP4. MOVHI pc, lr and MOVLO pc, lr. I honestly can’t work out what’s going on there. While I feel ignoring it is the best thing to do, I don’t like using copypasted code that I don’t understand. Especially because it has to be set up with 3 USB BUSses, +1 for USB OTG if I could be bothered.

Sounds like you need to brush up on your condition codes.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Chdhcfbc.html

Taking OMAP4 as an example, the CMP on line 142 splits the input into controller number into three categories: HI = out of range (so return via MOVHI pc,lr), EQ = controller 1, LO = controller 0. Then after a branch on EQ to separate out the #0 and #1 cases, we have the MOVLO pc, lr instructions to exit if the supplied buffer size is smaller than required.

Jeffrey. I don’t know where my head was at. I kept thinking High and low 16 bit words. You’re absolutely right. Serves me right for trying to do it when i wasn’t in the right mindset.

Just for the sake of it I tried adding USB today, because I realised the implementation was really simple. Just tried the first build. Almost, I guess?

=> go 0x42000000

init mod USBDriver => error: File ‘Resources:$.Resources.USBDriver.USBDevs’ not found

After adding a new module to the ROM (or changing one from ‘-type EXP’ to normal), make sure you do a ‘Export resources’ build phase.

I did. I actually did a build through from clean because there was some problem with it not seeing contents of oslib headers that were definitely there. Until I did that the EHCI module wouldn’t build. Oddly enough the USB module built fine the whole time.

Ohh. Wow. Here’s an example of the infuriating rubbish that I just can’t work out.

Bytes transferred = 5242880 (500000 hex) => go 0x42000000

This one’s a real beauty! It would have happened almost instantly after starting to run the image. There’s some good hints to that. First being the stack dump exists. U-boot gets overwritten shortly.
There’s no UART messages. They get set up pretty early.
There’s some fun stuff going on here!
As you can see, the image is loaded to 0×42000000. The physical RAM base is at 0×40000000 and goes to 0×80000000. AFAIK the vectors are at 0×0 in SRAM at this stage.
The reloc lr is a bit of a surprise. I’m going to assume this is before I turn off the MMU.
sp is where it should be. That’s where the U-Boot stack is roughly.

pc should be at 0×420xxxxx. 0×10 is the data abort vector. lr is 0×3. What?

The weirdness of the errors is completely different every time. It’s not as if this is a machine freshly powered up. It’s passed through the BROM, FEL and U boot to get this far. It’s all these weird random errors during boot that have been causing me headaches. Strange thing is if it does manage to boot completely, there are no issues!

I worked out why USBDriver lost it’s resources file after having a good look at the logs. Changing Territory to UK fixed it.

Try packaging the ROM as a uimage file. I think I’ve seen some versions of u-boot fail to flush the caches when using fatload/go (meanwhile uimages will work fine, because that’ll be the image format the port maintainers care about)

hmm. It’s worth looking into. I literally know nothing about it beyond vague memories of doing it via a menu when rolling my own Linux for H3/H5. I absolutely butchered the build scripts for my own purposes but that’s another story. Pretty sure I’m about the only person to do a native OS build of Linux on an Orange Pi instead of crosscompiling from PC though.

Back on topic. I’ll look into it. Otherwise, next thing I’ll try is setting up that whole cache walking invalidation thing, which I really shouldn’t need to do but it’s worth a try.

I got around to hammering away at this morning’s ROM build until it booted successfully to have a quick look at the properly built (but probably not properly implemented) USB.

Looks good I guess. I wouldn’t know what I’m looking for though.

*modules
...
 13 FC0E36A8 20003614  USBDriver                                                
 14 FC0EFE18 2000FCF4  EHCIDriver%2                                             
    FC0EFE18 2000C4D4  EHCIDriver%1
    FC0EFE18 20008634  EHCIDriver%Base        
...

*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

*usbbuses                                 
Transfers (3 buses):                                                            
Bus    Control Isochronous       Bulk  Interrupt                                
  1        383           0          0          0 
  2        397           0          0          5 
  3        383           0          0          0 

edit:

I just plugged a random USB drive in. Looking good!

*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   1   2  0/ 0 General USB Flash Disk

Cool with USB!! Lucky you that ehci is connected to the usefull ports :)

I had to look at your thread to work out how to go about it. I was extremely lucky with the way that USB is setup on the Allwinner SoCs. Everything is hardwired. I didn’t even need an init function to get this far. It’s just one port per bus. Funny thing is it has OHCI and EHCI for each bus. As I stated before I wasn’t sure what to do about that so I just did EHCI. There’s a USB OTG port too. It looks pretty easy to use as a host too, but I didn’t bother for now.
One of the main reasons I wanted to do this port is because the A3 and A5 have each USB port on their own bus, and the ethernet PHY isn’t USB. Unfortunate thing is the Orange Pi PC seems to have a GBit PHY but only 100MBit capable hardware attached. The Orange Pi PC2 (H5) has GBit hardware. Not that I could test it anyway. My LAN is 100MBit.

Funny thing is it has OHCI and EHCI for each bus.

That’s the standard arrangement – EHCI only supports USB2, so if a USB1 device is connected to the port it hands the port over to the OHCI controller.

OMAP3 (and OMAP4?) are the same, except that hardware bugs/restrictions mean that the handover can’t be done, so those ROMs only run with EHCI (+ MUSB for the OTG port). In turn, this requires a hub to be connected in order to use USB1 devices via EHCI (which the BeagleBoard/PandaBoard designers solved by adding the SMSC USB+LAN chip to the boards).

So yes, you’ll probably want OHCI enabling as well. You should be able to expose it via HAL_USBControllerInfo the same way as EHCI (although it might be a bit broken, since the only maintained platform that uses OHCI is the Iyonix, where the controllers are found via PCI rather than via the HAL)

If want to leave OHCI until later you can still use a keyboard and mouse – or any usb device – if you plug them in via a usb2 hub.

Jeffrey, as always extremely useful information.
From what you and Colin said, I’m going to take a wild guess that OHCI isn’t normally used because most other devices have an internal USB2.0 hub? Of course there’s the OMAP reason too.
At the moment I don’t have a whole lot of use for USB. It’s just after looking at the sources of other platforms and the Datasheet of the H3 it didn’t seem much more difficult than filling out a simple form.
While we’re talking about USB I came across something odd. At some point previously I briefly added ADFS and got it to build. This time around it fell over wanting headers pertaining to DMA. Before I set off another dependency chain reaction by trying again, does it want DMAManager? If so what is it?

Jumping subjects again. I was genuinely surprised to not see any HAL entries for DMA. I felt there would be a memcpy or blt that would try to call a HAL DMA entry with a failover to a PIO method.

Speaking of DMA and this platform. I’ve said it before, but it feels like a lot of copypaste went on. It has a DMA controller sith a lot of different channels to access different types of endpoints, and pretty much every device seems to have its own DMA controller too.

Back to USB. Let’s say I wanted to mount a filesystem on a USB drive via SVC, can I even do that? If so, what bare minimum modules would I need?

I just plugged it in to check what modules my current build has. Wahey! a brief walk down memory lane. Interesting.

...
HAL_TimerDevice
Requested Timer number= 00000000
Requested Timer IRQ number= 00000032
ÿÿÿÿÿÿ?¿u⇓ö¯×ýïÿ°ÿÿݺ¿¿ÿûÿÿÿÿÿÿßÖþÿ÷ÿûÿ^Éÿ÷rºÿãì¿ï÷½ÿd–ÿÿûÿ                 
                                                               Debug terminal on
HAL_InitDevices
HAL_InitDevices called
InitVariables
...

Different errors every time, if any.
That error looks like it came from the kernel.
Reading various source and documents is the majority of what I do on this project, trying to find the source of this issue. After a while it gets maddening so I implement a little more for a change.
The amount of messing around with Top.s isn’t reflected on the Git repository.

Also I’ve been reading up about uImage, the u Boot header format for it, and also mkimage, which I might add is a very unfriendly program. It needs help to explain the help to get help on it. I can’t seem to get it to list the supported parameters like image types etc.

At some point previously I briefly added ADFS and got it to build. This time around it fell over wanting headers pertaining to DMA. Before I set off another dependency chain reaction by trying again, does it want DMAManager? If so what is it?

Yes, ADFS will want DMAManager. It manages device-memory and memory-device DMA transfers. It controls the DMA HAL devices, which in turn are responsible for programming the DMA hardware. Each controller needs a controller device and one or more buffer or list channel devices. The documentation for DMAManager is a bit patchy – I think the SWI documentation on the wiki is complete (there was a big gap between me starting to write it up and then returning to it), but for anything else you’ll have to start with the documentation in PRM vol 5a and then overlay it with the documents in CVS that cover the changes that were made for HAL/RISC OS 5.

However, you don’t want ADFS in your ROM. Although the native RISC OS disc format is often called ADFS (since that was its name in the BBC era), under RISC OS it’s actually the FileCore module which handles the native disc format. ADFS is just a hardware driver for IDE/SATA & floppy controllers, none of which I believe are present on the Orange Pi.

For USB storage, SCSIFS is used. I listed (most of) the necessary modules for Michael over here – although as I said to Michael, if you’ve got timer 0 & interrupts working you should just be able to enable all the standard ROM modules and the system should start up OK.

Also I’ve been reading up about uImage, the u Boot header format for it, and also mkimage, which I might add is a very unfriendly program. It needs help to explain the help to get help on it. I can’t seem to get it to list the supported parameters like image types etc.

The ROM builder has native support for generating uimages. You just need to add %subformat, %load_addr, and %exec_addr directives to the components file. See the OMAP5 one for an example; in your case you’d probably want both load_addr and exec_addr set to 0×42000000 (the OMAP5 HAL has a +64 offset inherited from OMAP3, where the first N words of the ROM image were different entry points for the different board types, followed by the generic uImage entry point)

Thanks for all the info. I’m not 100% sure that legacy reasons is why OMAP has an offset for booting. If the load and boot address are 0×42000000 U-boot is going to try to start program execution at the beginning of the uImage header. I just popped open the freshly generated uImage (Thanks!!!) and had a look. The uImage header happens to be 64 bytes long.

I’ll sort that in a tic. I tried out that image anyway. It got stuck on trying to boot the kernel, but that’s okay. It showed me some nice information beforehand, so it’s happy with the image format.
I just really, really wish I could work out how to get access to the U-boot params which I’m sure are available to the OS, like RAM size and SoC type. It’s one reason I haven’t bothered touching the RAM detection code yet. No point until things like that, locations of things in RAM, and the interesting VRAM at the top of physical RAM issue are sorted completely.

I’m going to keep at it. If I manually “go” to the correct start address in the uImage it runs until it doesn’t, like usual. If I try to run it via bootm it throws a prefetch abort via the simple handler I put in.

If the load and boot address are 0×42000000 U-boot is going to try to start program execution at the beginning of the uImage header.

Incorrect – the addresses are specified as if the file has no header.

Hi Jeffrey. I slept on this one. Something’s not quite right somewhere. A uImage can be loaded by u Boot either from media or from RAM via bootm. If I were to load the image to 0×42000000, that would be a bad thing as it would read the header, then try to execute the header.
Next I tried loading the uImage to 0×41000000 because it’s still a safe area, then executing it with bootm. It’s only a guess, but I was guessing that u Boot would copy the image sans header to 0×42000000 before execution. Last thing I see is “Starting Kernel…” or something like that. It locks up.

Next thing I’m going to try is to do a fresh version of my u Boot SD card, but with a small FAT partition, and a FileCore partition, set it up and see what happens.
The FC partition of course isn’t necessary, but I might as well.
The Orange Pi PC requires a specific setup with the boot code in a specific position before the first partition. Like A PC in a way.

Anyway I’m going to try to get this done.

If the location the image was loaded to overlaps the load address in the image header, I’d assume u-boot is smart enough to move it without overwriting/corrupting it. But I don’t think we’ve actually tried that.

Whenever we use u-boot with RISC OS, I think we always specify an image load/exec address that’s different from the file load address. E.g. for OMAP5 I can see that the default fatload & bootm command sequence that’s compiled into u-boot loads the image to 0×80200000, but the load address specified in the uImage is 0×81000000.

Interesting.

It’ll probably be a little while before I can work through all this. I’ve spent my time today fighting with problems. Skipping the detail, I can’t get my OPiPC or PC2 to boot successfully into linux. Tried reimaging the PC2. The PC kept stopping. Usually at a specific point but many times at a random point during Linux kernel init. The USB voltage / current thing was telling me a healthy 5.2v. Current was 0.25A which is a little odd. Hmm.
Somehow I only just had the idea to plug it in to one of the OPi PCs USB ports. 0.0A of course, but the voltage was looking very sad, with it finally locking at 4.19v. I don’t know what 3.3v regulator it’s using but that has to be below dropout voltage.
Wow. The wires in the cable must be so bad. I’m using a PSP charger cable because the barrel size is the same. My previous homemade cable worked adequately until it didn’t. Internal breakage I think. Time for one of my go-to solution RPi prototyping board things I think with a normal size barrel connector feeding the +5v rail.

On the bright side I guess I did a fair bit of work on stability. Hopefully it’s vastly improved once I sort this cable issue.

I more or less knocked up the bare basics of what I needed to pump some current into the OPi PC. It’s one of those prototyping boards (Not technically a HAT because it lacks the camera? ribbon cable hole). +5v is provided directly to the +5v GPIO pins via a 10A electronic relay. All the power wiring is trailer wiring, right up to the 5V, 5A PSU. Earth was a little trickier because the *Pi GPIO layout has them scattered. The prototyping board didn’t appear to have them all wired, and the ones that were all went to the board ground rail via a tiny little track or two. So there’s a whole heap of hookup wire soldered on to each GPIO GND pin to the ground rail individually. Unfortunately I had to wire the relay on for now and there’s no caps on the power rails either. I been able to readily salvage those yet.
There is no voltage sag now. It booted second attempt which is pretty good. For reasons I haven’t quite worked out sometimes the boot dies somewhere in the MMU startup zone of the kernel.

My previous plan of accessing a USB drive has a slight failure. I’m stuck on the prompt “Waiting for boot drive to be ready; press Escape to cancel.”
I’m using !Connector. I’m not sure I can send escape.

You can patch the kernel so that it will skip trying to run the boot sequence and go straight to the command prompt instead – near the end of s.NewReset, change the BEQ DoStartSuper to B DoStartSuper.

One quirk of the debug terminal is that although single-tasking keyboard input will come from HAL_DebugRX, you should still be able to use a USB keyboard to press Escape (assuming your USB is working to a sufficient degree)

Changed to bypass the prompt as suggested.
I also added in some missing code and gobs more debug code. I really need to do a Git push at some point.

I’m seeing things that need some hard scrutiny.

There’s some info from a debug function I put in Top.s which has me a little unsettled.

...
=> go 0x42000000


	

		
Starting application at 0×42000000 …

PreMMU UART configured

MMU is off.

 HAL_Base is at:fc000000

…

e: Of course it should be. I’m displaying a value from the literal pool. I was clutching at straws.

Been tinkering some more. Unfortunately I’m well and truly at the stage of throwing things at it and seeing what works. It got as far as booting again. Perhaps because of some HAL_Init SCTLR fiddling, or perhaps just luck.
Good news is *usbdevices shows the EHCI controllers (I added OHCI too but whatever), the random USB3.0 hub I plugged in, and the Logitech wireless keyboard (and broken mouse) controller I plugged into that.
*help also spat out human readable text, although with the word per line formatting that BASIC seems to do.

I ran a BASIC program and built a simple assembly program in it.

I had to disable the SCSI modules again because they were causing lockups.

Bypassing the keypress prompt for a boot filesystem didn’t actually work for the few times I got it to boot that far. Didn’t try too hard to trace the kernel code back to see what was actually happening.

Progressing slowly but surely.

Any suggestions for anything I can do with a minimal CLI system with no persistent media to test it?

Here’s what this build has.

*modules                                                                        

No. Position Workspace Name                                                     

  1 FC028BE8 00000000  UtilityModule                                            

  2 FC04D5D0 20000014  PCI          

  3 FC04F57C 200001D4  FileSwitch                                               

  4 FC05C360 20001694  ResourceFS

  5 FC05D060 00000000  Messages  

  6 FC088FB8 200016F4  MessageTrans                                             

  7 FC08A3A4 20003234  UK          

  8 FC08BF60 00000000  SharedCLibrary                                           

  9 FC0C05D0 00000000  BASIC         

 10 FC0D18DC 00000000  BASIC64                                                  

 11 FC0E0DB0 20003314  BufferManager                                            

 12 FC0E2018 20003434  DeviceFS     

 13 FC0E4524 20003574  Portable

 14 FC0E4F4C 20003734  USBDriver                                                

 15 FC0F16BC 2000FDF4  EHCIDriver%2                                             

    FC0F16BC 2000C5D4  EHCIDriver%1

    FC0F16BC 20008734  EHCIDriver%Base                                          

 16 FC0F7828 00000000  FileCore       

 17 FC10ACB4 200151D4  Free    

 18 FC10C49C 200150F4  SerialDeviceSupport