w00t, finally we get some serioes response from a usb device! \o/

GET_DESCRIPTOR (with 8 bytes) works!

as promised, brand new ugly hax!!11

some clean up (for more dirt!! \o/)

amend it!

discoverd weird endianness bug in sauter's usport. fixed

data{0,1} now decided by endpoint (for PID_IN) (see p22/23 @ ohci specs
for details)

control_quirk seems to be evil and our buf must be "80 06 00 01 00 00 40 00" for setup!

some changes... still blah

@a097034:
with my usb keyboard, the buffer pointer will be set to NULL. afaik that
is a proper value

cbp will be count up, but only with low speed devices (except my usb
keyboard o_X)

further pfusch :) as usual, see difflog for details

corrected memalign call

various changes, see difflog for details!

adapted setup_port to old, clean state

but with our evil return; hack :)

port enable and reset problem solved (tmp commit)

it works now, but we don't know why... *sigh* :(

tmp commit

roothubports will be configured after init of ohci

tried to fix port enable/reset bug - didn't work

some roothub stuff added. TD transfer without errors, w00t!

added HC roothub output to isr (only on "RootHubStatusChange")

dummyconfig is now static, however control_quirk is still needed. (wtf)

add debugfunction for td->flag

finally we get some response from HC :) however our TDs seems to be
bullshit :/

@commit 8dbf7ef007d1d:
I think the problem here was that tailp and headp of the ED structure
was set to the same location. In this case, the HC thinks all TDs are
done! So HC set CLF to null. (search for this somewhere in the ohci specs...)
In fact, just headp must be set.

ehm..., something happen! :D

so, the HC clears CLF (ControlListFilled bit of the register "Command Status") immediately after setting it.
the ohci specs says:
"This bit is used to indicate whether there are any TDs on the Control
list. It is set by HCD whenever it adds a TD to an ED in the Control
list." [so far so good]
"When HC begins to process the head of the Control list, it checks CLF.
As long as ControlListFilled is 0, HC will not start processing the
Control list. If CLF is 1, HC will start processing the Control list and
will set ControlListFilled to 0. If HC finds a TD on the list, then HC
will set ControlListFilled to 1 causing the Control list processing to
continue. If no TD is found on the Control list, and if the HCD does not
set ControlListFilled, then ControlListFilled will still be 0 when HC
completes processing the Control list and Control list processing will
stop."

What does it mean for us? HC don't find the TD?

amend it!

new hottie: calloc != memalign. after s/calloc/memalign the HC
don't move HEAD to CURRENT, wtf? :/

some debugoutputstuff and few changes

[tmp] byte order changes in usb_control_msg() (usb.c). somehow it need
fewer packets (more realistic?). further investigation will be done
soon.

removed decrementer exception message

because it's getting on my nerves while browsing
the host controller output...

first usage of ACCESS_LE throughout the file

it is NOT tested yet, but hey, it compiles ;-)

add macro for u32 little endian access from ppc

[tmp] speicherprobleme behoben; in current bleibt der erste endpoint
"haengen"
weiters steht merkuwerdiger weise die adresse (0x80008000) nach
"warmstart" in current -- WTF?
im "done head" leider noch immer nix :( vielleicht ist die endianess
schuld?! (le<>be)

[tmp] geht grad nix :(

attempt to get some TDs through the HC -> fail :(

happy whitespace hunting in sauter stack

(only files that are relevant for us)

some debug stuff. let zeh ohci hack begin! \o/

first adaption of 'usbport' by Benedikt Sauter
see http://www.embedded-projects.net/index.php?page_id=186

first adaption of linux ohci irq handler

the whitespace hunter has struck again!

sync before write hcca_SRC? else just peanuts

ohci0 finally goes in operational mode -- silly confusion with
{set,write}32 *shame*

dirty ohci commit for thestack; nicer patch will follow

killed the ohci_init FM_INTERVAL fail

lol noobs, how about clearing OHCI0_HC_INT_STATUS?! :)

just commented out unneeded line in irq init

due to the fact that (HW_PPCIRQMASK+0x04 == HW_ARMIRQFLAG),
that write concerns arm irqs and is thus not needed here.
besides that, writing 0 to a flag register seems to be
senseless anyway (what have mini people done here? :P).

WIP: irq handler

hw-pic still don't work, but the irq #14 will be cleared...
maybe all hw-ppc-flags should be cleared -- how?!

write32(HW_PPCIRQFLAG, ~0);
don't work :(

WIP: irq_handler

Merge branch 'isr_test' of git://github.com/theStack/ppcskel into isr_test

Conflicts:
ohci.c

WIP: copy irq_handler from mini to ppcskel

untracked all those annoying .d files

added (empty) handling for decrementer exception

fixed dma_addr() macro in ohci.c

implemented simple irq handler, added irq.h

ohci0 interrupt will be thrown - hooray++ \o/

reset interrupt will be thrown - hooray \o/

add .gitignore

bootmii-devel.googlegroups.com/web/ppcskel.zip