RK3288 initial rants

And EHCI works!

*usbdevices
No. Bus Dev Class Description
1 1 1 9/ 0 Built-in EHCI root hub
2 1 2 0/ 0 Generic USB Audio

But I am kind of sad , because the normal USB ports are connected to the DWC controller :(
The only device that is on EHCI is audio.

The BSD DWC driver works on RK3288, so I will look on if it is possible to port that.

I am reading the RO dwc driver… what is MPHI used for? There is no such thing in RK3288.
The only RK patch to DWC in FreeBSD is to enable power..

The RO DWC driver has been customised fairly heavily for use with the Pi (since it’s based off the Linux version of the driver that’s also been customised heavily for the Pi).

The MPHI is a peripheral that was being abused as a way of downgrading FIQs to IRQs – i.e. the FIQ handler would poke the MPHI peripheral, then the MPHI would raise an IRQ (the Pi driver makes heavy use of FIQs, due to the DWC silicon in the Pi requiring the driver to do a lot of grunt work, compared to e.g. EHCI controllers). On something with a GIC, you might be able to use a software-generated interrupt for the same purpose (although I’m not sure offhand what the rules are for having a core send an interrupt to itself). Although you’ll also have the headache of trying to get FIQs working with the GIC (something that I don’t think we have support for any any RISC OS ports yet – I was thinking about adding support for it to the IMX6 HAL, but haven’t got round to it yet)

If you go back in time far enough (e.g. DWCDriver 0.04) you’ll find that most/all of the Pi-specific tweaks to DWCDriver are contained in #ifdef BCM2835 checks, where I tried to keep our version of the code a bit cleaner than the Pi version. But as the FIQ-related changes got more and more involved I ended up abandoning that approach (early versions of the driver only used IRQs).

The u-boot driver doesn’t use FIQs at all. I am optimistic!

The 0.4 version looks interesting. Can someone check it out for me and provide a archive? Might actually work.
Can expand it from there.

It looks more like the current FreeBSD driver than the current RO driver does.

Video is UP! Bring me USB!

BTW, I tried to force start Desktop using XOS_CLI. It tries to set screenmode several times, which I don’t support at all atm.
Can this be removed somewhere? I tried to issue “*configure wimpmode” but no effect.

I get a not so nice display with coloured bars etc.

EDIT: I changed my VetMode function to return “supported” if the suggested mode is the same as “my” mode. With that change the desktop doesn’t call setmode.
But the display is just garbage.

I switched to BGR in the VOP. The display is exactly the same. Gradient (looks quite nice) bars and random garbage. If you look closely you might see the riscos display as small rects at the top of the screen.

WIth 800×600 8bit I get four small windows att the top of the screen ( the message about boot sequence)
What kind of mode does Wimp want?

It’ll normally default to 640×480 8bpp (RISC OS mode 28), but it can also do strange things if the video driver is only half-functioning.

I think *Configure Wimpmode will only write the new value to CMOS (which I’m guessing you won’t have working yet), and not affect the “live” configuration. *Wimpmode will affect the live configuration (although without an MDF/EDID loaded into ScreenModes, you’ll be limited to using numbered modes).

To override the OS’s mode selection logic in a fairly reliable way, you can have your video driver implement GraphicsV 16. If you need to use something which isn’t a numbered mode (i.e. you can only describe the mode using a mode selector block) then you can also have your driver load an MDF containing an entry for that mode – similar to the code in IMXVideo that’s wrapped in the CustomBits option.

I use a old version of the i.MX6 video module. I use the included MDF. I was wrong in bits.. The VOP can¨t do 8-bit without much work so I am stuck at 24 bit (or 16).
I run : wimpmode X800Y600C16M
I end up with 4 small displays.. which would indicate that the Desktop runs in 8 bit (640×480) and ignores the wimpmode command.

I tried to include a BASIC program as resourcefile in Kernel.s.NewReset. But when I run “basic -quit Resources:….basicfile” I get file not found.
I have done exactly as in IMXVideo. It is RISCOSmark4, I thought it would be fun to see graphics.

It is strange with the desktop. The same configuration worked in the early I.mx6 days. Why might wimpmode be ignored?

Now I get a even more serious issue:
Error: UndefinedInstruction:Undefined instruction at &FA0001EC (Error Number &80
000000)

This is when RISC OS should be printed. Instead I get that error on screen.
I have added more modules, can it can from a module that is not Kernel or Video?

BAH. It was the Video module. Resetting that and a few another tweeks… gui runs with a error window :)
Se the other thread for photo.

I really could do with that old DWC module. Either help if I can access the CVS, or if some kind person can make a archive.
Probably need USBDriver to go with it.

I have been worried about the VOP clocking since it is a very hairy procedure.. I just found out that it isn’t needed. Apparently it is programmed with good defaults.
I don’t know if that’s the case for 4k displays, but I am not going to spend time on that now.

Managed to checkout old DWC. I am now stuck in that it can’t communicate with USBDriver. I get abort on instruction fetch at 0000004 as soon as it tries to call USBDriver_RegisterBus, it never gets there.

Hmm now it does, built with “NetBSD” from the same era. It now fails in ca_attach (hub). I have never managed to trace down what happens in that call.
Someone please enlighten me! I got a explanation last time I asked about ca_attach, but now it fails differently. When I had problems with EHCI the same error occurred when timer/interrupts was failing.

Error: DataAbort:Abort on data transfer at &FC1C3A8C (Error Number &

I have tried to read the symbol list, but no luck.

Hmm again
I upgraded back the USBDriver and now it runs thru , but no effect other than that the mouse gets powered down , when the module runs. That is , if I powered it up from u-boot.

Normally it would stay on.
Getting long this :) It crashes at the same point during startup if buuilt with debug. But from the debug output it looks like it explores the root hub:
USBDriver: Adding explore callback on bus 20019510
USBDriver: bus discover 20019510
USBDriver: dev:200273d4 uctl:200273d4
USBDriver: discovering 200273d4
USBDriver: finished callbacks, total sleep = 0
USBDriver: rediscover bus 1
USBDriver: Adding explore callback on bus 20019510
USBDriver: bus discover 20019510
USBDriver: dev:200273d4 uctl:200273d4
USBDriver: discovering 200273d4
USBDriver: finished callbacks, total sleep = 0
USBDriver: rediscover bus 1
USBDriver: Adding explore callback on bus 20019510
USBDriver: bus discover 20019510
USBDriver: dev:200273d4 uctl:200273d4
USBDriver: discovering 200273d4
USBDriver: finished callbacks, total sleep = 0
USBDriver: rediscover bus 1
USBDriver: Adding explore callback on bus 20019510
USBDriver: bus discover 20019510
USBDriver: dev:200273d4 uctl:200273d4
USBDriver: discovering 200273d4
USBDriver: finished callbacks, total sleep = 0

I’m just curious if the core of this thing is related to the one you are working on?
http://www.orangepi.org/Orange%20Pi%20RK3399/

I’m just curious if the core of this thing is related to the one you are working on

The SoC is similar, but the ARM core is different.

This call:
e = swix(USBDriverRegisterBus, INR|OUT,in,RISCOS_USBDRIVERAPIVERSION,out);

Fails like this:
Error: InstructionAbort:Abort on instruction fetch at &00000004 (Error Number &8
0000001)

In this:
(*usb_ca.ca_attach)(0, softc, bus);

The module looks identical to curent DWC up to that ( at least).

Old USBDriver doesn’t crash like that, but fails on checking USB1/2 etc.
My guess in all this is that there are differences in API. I have upgraded the dwc struct so that it looks the same as current.

The “bus” above is dwc.

Progress!
But the second device is a hub! OK it doesn’t find device #2.
From where doesn it find it? Does it have a notion of its existance or does it just try another unit, then stop?

*usbdevices prints the roothub.

USBDriver: adding bus 20027da4 using 20035c54 size 50
USBDriver: : USB revision 2.0
USBDriver: enter sleep:usbdly irqstate:0
USBDriver: leave sleep:usbdly irqstate:0
USBDriver: Trying match on ignore device
USBDriver: look for USB$Ignore_0000_0000.. got ""
USBDriver: Trying match on usb hub
USBDriver: Looking up v = 0, p = 0
USBDriver: Attach setup
USBDriver: USBHub0.69: Synopsys DWC OTG root hub, class 9/0, rev 2.00/1.00, add
r 1
USBDriver: USBHub0.69: single transaction translator
USBDriver: USBHub0.69: 1 port with 1 removable, self powered
USBDriver: enter sleep:usbdly irqstate:0
USBDriver: leave sleep:usbdly irqstate:0
USBDriver: Matched hub
USBDriver: Trying match on ignore device
USBDriver: look for USB$Ignore_0000_0000.. got ""
USBDriver: Trying match on usb mouse
USBDriver: Trying ums attach
USBDriver: Failed to match
USBDriver: Trying match on usb keyboard
USBDriver: Failed to match
USBDriver: couldn’t find unit 2
USBDriver: Failed to match Alias$USBDevice_*_*_*_0000_0000___0100_* USBDriver: Failed to match Alias$USBDevice_*_*_*_0000_0000___*_*
USBDriver: Failed to match Alias$USBDevice_09_00_01_0000_*___*_* USBDriver: Failed to match Alias$USBDevice_09_00_*_0000_*___*_*
USBDriver: Failed to match Alias$USBDevice_09_00_01_*_*___*_* USBDriver: Failed to match Alias$USBDevice_09_00_*_*_*___*_*
USBDriver: registered driver 20036134
USBDriver: first = 200276f4, last = 200276f8
USBDriver: total sleep = 0
USBDriver: Send USBDriver_Attach service call
USBDriver: Service call reason 210
DWCDriver: svce d2 reason 0
DWCDriver: svce d2 reason 0
DWCDriver: Registering with USB driver-done

You are making great progress. It looks like you almost have USB working properly. That’s a massive step!

I’ve been watching your progress. It’s very helpful to me because you are so far ahead, and seem to be facing similar issues.

Yea.. EHCI is fully working.. but this isn’t

Yea.. EHCI is fully working.. but this isn’tThe second device in the chain is a 4 port hub ( the physical ports on the board) It is being marked as generic in USBDriver and therefor UHUB attach doesn’t happen. If I skip the test for generic , it doesn’t register the roothub properly and stops.

Yea.. EHCI is fully working.. but this isn’tThe second device in the chain is a 4 port hub ( the physical ports on the board) It is being marked as generic in USBDriver and therefor UHUB attach doesn’t happen. If I skip the test for generic , it doesn’t register the roothub properly and stops.Jeffry, How is the supposed to work?

Why is the forum post all messed up?

I have now “hacked” the current DWC module to use the same IRQ way as the old one. Still stuck at the same place. The second device is marked as generic and isn’t matched against hub.

USBDriver: adding bus 20019d38 using 20023f74 size 50
USBDriver: : USB revision 2.0
USBDriver: enter sleep:usbdly irqstate:0
USBDriver: leave sleep:usbdly irqstate:0
USBDriver: Check for ‘USB$Ignore_0000_0000’ got ‘NULL’
USBDriver: Trying match on usb hub
USBDriver: Looking up v = 0, p = 0
USBDriver: Attach setup
USBDriver: USBHub1.27: Synopsys DWC OTG root hub, class 9/0, rev 2.00/1.00, add
r 1
USBDriver: USBHub1.27: single transaction translator
USBDriver: USBHub1.27: 1 port with 1 removable, self powered
USBDriver: enter sleep:usbdly irqstate:0
USBDriver: leave sleep:usbdly irqstate:0
USBDriver: Matched hub
USBDriver: Check for ‘USB$Ignore_0000_0000’ got ‘NULL’
USBDriver: Trying match on usb mouse
USBDriver: Trying ums attach
USBDriver: Failed to match
USBDriver: Trying match on usb keyboard
USBDriver: Failed to match
USBDriver: couldn’t find unit 1
USBDriver: Failed to match Alias$USBDevice_*_*_*_0000_0000___0100_* USBDriver: Failed to match Alias$USBDevice_*_*_*_0000_0000___*_*
USBDriver: Failed to match Alias$USBDevice_09_00_01_0000_*___*_* USBDriver: Failed to match Alias$USBDevice_09_00_*_0000_*___*_*
USBDriver: Failed to match Alias$USBDevice_09_00_01_*_*___*_* USBDriver: Failed to match Alias$USBDevice_09_00_*_*_*___*_*
USBDriver: registered driver 20024454

Wrong IRQ number .. !
Anyway now it just stops (timeouts?) in
dwc_otg_hcd_urb_dequeue

Both old and new driver.. From USBDriver it seems like it actually finds new device after root hub, but it fails on it.