port-work; won't compile or even work

[WIP] added usbstorage from libogc (by svpe)

THIS COMMIT WON'T COMPILE

fatfs: update to 0.07a

some usb stack related clean up; BULK still untested

some routines for removing a device on demand. thist do not work properly
(TODO!)

added set_rate for HID devices; keyboard driver works fine at proper
rate now, but console output still sucks a bit ;)

intterupt transfers done right now. however, the keyboard driver behave
still buggy.

bulk transfers also added, but UNTESTED!

fixed memory leak (in a few h memory would be full)

better solution in this case: let not return usb_hidkb_getChars()
newly allocated structure, but instead the user should provide
memory for the structure and let him pass a pointer to that structure
to the function (but i didn't want to change the interface so far)

fixed buffer overflow on str

added simple keycode->char lookup functionality

and tried to make it a bit more nice in main.c :)
don't know if it works though, hopefully it does...

add global hcca pointer for avoiding redundant code

+ makefile fix for the last commit

just deleted useless files

various changes

added [A-Z0-9] support ;)

all in all, very dirty, see HID spec for more details on it

Merge branch 'master' into usbkb_sauter

Conflicts:
Makefile
gecko.c
hollywood.h
main.c

will boot sysmenu when press reset button and again license stuff

license stuff

added hidkb driver and a simple example

w00000000000t

BLEH, WTF :( {s,g}et_configuration still won't work and I fucking don't know
anything why

added usb capture of linux when config my usb keyboard

first attempt to get interrupt transfers working. epic fail :(

{s,g}et_configuration still don't work (hence, so do {s,g}et_interface)

wtf, for some devices {s,g}et_configuration works:
o internal usb bluetooth dongle
o "Driving Force Pro" from Logitech
o USB RF Remote Receiver

do not work:
o Compaq USB Keyboard
o Gameport to USB adaptor
o Logitech USB mouse
o 2 various USB sticks
o Hercules DJ Control MP3
o Hauppauge Nova-T DVB-T stick

a Microsoft Sidewinder Wheel also don't work, but the Endpoint will
halt and output this:

>>>>>>>>
usb_set_configuration(ret: 0): 1
halted!
n: 0x800D6890
n(after) hexdump (32) @ 0x800D6890:
00000000  00 00 ec 03 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
**************** dbg_td_flag: 0x03EC0000 ***************
CC: 0 should be 0, see page 32 (ohci spec)
EC: 0 see page 20 (ohci spec)
 T: 3
DI: 7
DP: 1
 R: 1
********************************************************
prev: 0x800D6860
prev(after) hexdump (32) @ 0x800D6860:
00000000  00 00 f4 40 30 6e 01 00 20 68 0d 00 33 6e 01 00  ...@0n.. h..3n..
00000010  80 01 6e 30 00 00 00 04 00 00 00 00 00 00 00 00  ..n0............
prev->bufaddr(after) hexdump (4) @ 0x80016E30:
00000000  80 08 00 00                                      ....
**************** dbg_td_flag: 0x40F40000 ***************
CC: 4 should be 0, see page 32 (ohci spec)
EC: 0 see page 20 (ohci spec)
 T: 0
DI: 7
DP: 2
 R: 1
********************************************************
halted end!
=============
after usb_get_configuration:
00000000  80                                               .
=============
usb_get_configuration: 128
<<<<<<<<

where CC=4 means "DataOverrun". However, I don't think this information
is useful :/

oh, hello bluetooth dongle :D

do the whole thing more generic ...

fullspeed devices will be detected now

usb_{s,g}et_configuration doing it wrong :/

again a "funny" problem @ u/c/core.c: #{un,}define WTF and see
yourself

also look at "LOAD" messages and their values on gecko output

added lsusb and some more config stuff. except of some (simple) setter
functions it should be fine now for some interrupt transfer hax :)

more refactor

m00h @ previous commit: using wTotalLenght of CONFIGURATION you get
CONFIGURATION, INTERFACE(s) and ENDPOINT(s) in one big request. WIP

further refactoring; usb_get_desc_interfac doesn't work yet

refactoring ugly typedefs...

bleh, somehow the last character of a STRING do not receive :/

quirk replacement (control): simple delay (~11ms)

I noticed that when gecko-printf were disabled (by #ifdef):
on the first upload, all seems to be ok (aka "cold boot"). on further
uploads it stucked. after enable gecko-printf again, it worked quite
fine... so here zeh uber quirk!

btw ... wtf? :/

simple changes to the stack

@get_descriptor|String: disable control quirk *sigh* and keep in mind to do not request more data as defined in bLength otherwise the endpoint will halt

added debug defs

some more device info \o/

ed is static now, and it works! \o/

after a warm start we have really odd memory issues:
ohci0 isn't able to read or write (actually we don't know exactly) from an
allocated resource.
may some malloc/free/sync/mmu fail?! no idea! :(

therefore here a hack to in ohci_init. when the ohci isn't in the RESET
state (that is after an hardware reset), we know it is an warm start and
allocated some memory... but this is no real useful workaround :(

do-while for mr. stack!

done head fixed; we poll edhead->headp until it is null, to get sure
all TDs are done

ISI exception fixed. as expected, a sync fail. however, done head is
null. why?

weird ISI exception bug, WZF

also added reverse list lookup for done queue

do it more generic, but it fails :/

some cleanup, incl. free'ing of allocated stuff (without malloc fail)

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

sha1 patch for ppcskel

Steve Reid's SHA-1 C implementation is used here and slighty modified
for the SHA-1 Controller in Hollywood.
Some simple testcases showed that it is a bit faster as it would be done
in software, especially on a huge amount of data.
However, there is room for improvement :)

Further this patch uses the AHBPROT issue recently found, so Broadway is
able to acces the SHA-1 Controller *directly*.

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/