Page 1 of 1

exec.library->AddTask() stack handling...

Posted: Sat Jun 09, 2018 6:17 am
by Belxjander
What would be the specific corrections needed to deal with the SPReg, SPLower and SPUpper in the "struct Task uTask;" as part of the "struct DEVICE_UNIT_CLASS *unit;" dyamically allocated within the following code ?

I'm looking at the example on the Amiga Developer CD 2.1 and trying to adapt from 68K Assembly into C... and apparently missing something during the translation?

Would like not to use dos.library for this one

Code: Select all

	struct DEVICE_UNIT_CLASS *unit=NULL;
	struct PCIResourceRange *Range=NULL;

	if(card)
		unit=Base->IExec->AllocVecTags(DEVICE_UNIT_SIZE,AVT_Type,MEMF_SHARED,AVT_ClearWithValue,0L,TAG_DONE,TAG_DONE);
	if(unit)
	{
		KDEBUG("XHCI::InitUnit()@unit=%lx\n",unit);
		Base->Library.lib_OpenCnt++;
		unit->Attrs[0].ti_Tag=AT_Param1;
		unit->Attrs[0].ti_Data=(uint32)unit;
		unit->Attrs[1].ti_Tag=AT_Param2;
		unit->Attrs[1].ti_Data=(uint32)Base;
		unit->Attrs[1].ti_Tag=TAG_END;
		unit->Attrs[2].ti_Data=(uint32)0L;
		card->Lock(PCI_LOCK_SHARED);
		HwCardReset((APTR)Base,card);
		Range=card->GetResourceRange(0UL);
		if(Range)
		{
			KDEBUG("XHCI::InitUnit() @Range=%lx\n",Range);
			KDEBUG("XHCI::InitUnit() @Range/BaseAddress=%lx\n",Range->BaseAddress);
			KDEBUG("XHCI::InitUnit() @Range/Size=%lx\n",Range->Size);
			KDEBUG("XHCI::InitUnit() @Range/Physical=%lx\n",Range->Physical);
			KDEBUG("XHCI::InitUnit() @Range/Flags=%lx\n",Range->Flags);

			card->FreeResourceRange(Range);
		}
		unit->InterruptService.is_Data=unit;
		unit->InterruptService.is_Code=(APTR)&HwInterruptService;
		unit->uStack=Base->IExec->AllocVecTags(UNIT_STACK_SIZE,AVT_Type,MEMF_SHARED,AVT_ClearWithValue,0L,TAG_DONE,TAG_DONE);
		if(unit->uStack)
		{
			unit->uTask.tc_IDNestCnt	= -1L;
			unit->uTask.tc_TDNestCnt	= -1L;
			unit->uTask.tc_SPReg		= unit->uStack;
			unit->uTask.tc_SPLower		= unit->uStack;
			unit->uTask.tc_SPUpper		= (APTR)((uint32)UNIT_STACK_SIZE +(uint32)(unit->uStack));
			Base->IExec->NewList(&unit->uTask.tc_MemEntry);
			unit->uTask.tc_UserData=(APTR)unit;
//			Base->IExec->AddTask(&unit->uTask, &ExecUnitTask, NULL, &unit->Attrs[0]);

			if(Base->IExec->AddIntServer(card->MapInterrupt(),&unit->InterruptService))
				KDEBUG("XHCI::InitUnit() @InterruptService = Mapped && Activated\n");
		}
		card->Unlock();
	}

	return;

Re: exec.library->AddTask() stack handling...

Posted: Sat Jun 09, 2018 7:50 am
by thomasrapp
The stack grows downwards from high to low addresses. So to start with an empty stack SPReg must point to the end of the stack, not to the beginning.

Re: exec.library->AddTask() stack handling...

Posted: Sat Jun 09, 2018 12:53 pm
by Belxjander
thomasrapp wrote:The stack grows downwards from high to low addresses. So to start with an empty stack SPReg must point to the end of the stack, not to the beginning.
so then ...

Code: Select all

unit->uTask.tc_SPReg		= (APTR)((uint32)UNIT_STACK_SIZE +(uint32)(unit->uStack));
unit->uTask.tc_SPLower		= unit->uStack;
unit->uTask.tc_SPUpper		= (APTR)((uint32)UNIT_STACK_SIZE +(uint32)(unit->uStack));
is more correct ?

Re: exec.library->AddTask() stack handling...

Posted: Sat Jun 09, 2018 8:51 pm
by thomasrapp
Yes.

I would do it like this:

Code: Select all

unit->uTask.tc_SPLower    = unit->uStack;
unit->uTask.tc_SPUpper    = ((uint8 *)unit->uStack) + UNIT_STACK_SIZE;
unit->uTask.tc_SPReg      = unit->uTask.tc_SPUpper;

Re: exec.library->AddTask() stack handling...

Posted: Sat Jun 09, 2018 10:26 pm
by Belxjander
@ThomasRapp: Thank you for clarifying that.

Will try it and see what happens next...

It will be nice to actually have a working XHCI USB3 controller added to my setup ...

@Everyone... if anyone wants the sources I'll be publishing them in full as an example device driver,
that works against *real* PCI hardware... maybe it can be used towards encouraging more devices to be supportable with less barrier to entry for making it happen ?

I missed seeing the specific points in the example ramdev.device assembly up until now
despite actually having a physical book for quite a long time (and only have a PDF version now)

EDIT: Output in Sashimi now has this...

Code: Select all

XHCI::HwCardReset(0x5ff8c69c)
XHCI::InitUnit() @Range=5fffd920
XHCI::InitUnit() @Range/BaseAddress=a0100000
XHCI::InitUnit() @Range/Size=2000
XHCI::InitUnit() @Range/Physical=a0100000
XHCI::InitUnit() @Range/Flags=2
XHCI::InitUnit() // IExec->AddTask(&unit->uTask,...);
XHCI::InitUnit() uTask Launched!!!
XHCI::InitUnit() @InterruptService = Mapped && Activated
XHCI::ExecUnitTaskMain(5fdd9000, 0)
XHCI::CloseDevice()
XHCI::HwInterruptService(20b9230,5fdd9000)
XHCI::HwInterruptService() Happening
XHCI::HwInterruptService(20b9230,5fdd9000)
XHCI::HwInterruptService() Happening

Re: exec.library->AddTask() stack handling...

Posted: Sun Jun 10, 2018 2:34 am
by Belxjander
Not a redeemable choice in following the example so closely...

changed from using AddTask() over to using CreateTask() [CreateTaskTags() variant] instead...

using AddTask() turns out to only be safe as long as code is hand-written assembly at that point.

otherwise *every* syscall will trigger DSI and ISI exception pairs...regardless

Re: exec.library->AddTask() stack handling...

Posted: Sun Jun 10, 2018 12:56 pm
by thomasrapp
Belxjander wrote:otherwise *every* syscall will trigger DSI and ISI exception pairs...regardless
You have to make sure that all interface pointers are set up correctly. Don't use global variables.

Here is an example which works on OS3 as well as OS4: http://thomas-rapp.homepage.t-online.de ... s/task.lha

Re: exec.library->AddTask() stack handling...

Posted: Sun Jun 10, 2018 6:27 pm
by Belxjander
well... everything I was doing before reworking that section was entirely localized for variable usage.

so I am not actually sure where the globals came from at all

Re: exec.library->AddTask() stack handling...

Posted: Mon Jun 25, 2018 2:49 pm
by Hypex
Belxjander wrote:It will be nice to actually have a working XHCI USB3 controller added to my setup ...
You're working on a USB3 driver? :shock:

I wish you well in your quest. :)

I wonder, would this be just for XHCI controllers in the PCI slot, or PCIe as well?

Re: exec.library->AddTask() stack handling...

Posted: Thu Jun 28, 2018 1:40 pm
by Belxjander
Hypex wrote:
Belxjander wrote:It will be nice to actually have a working XHCI USB3 controller added to my setup ...
You're working on a USB3 driver? :shock:

I managed to luck out and find a *PCI* card with XHCI Renasas PCI-Express Controller Bridged for use, and...
of all the shocking things... IT WORKED and powered up when installed in a sam440 (at least as far as slotting in and showing up to the OS...)
I wish you well in your quest. :)

I wonder, would this be just for XHCI controllers in the PCI slot, or PCIe as well?
Well... as the PCI and PCI-Express show up through expansion.library using the same set of functions... as long as the XHCI is provided by any form of
PCI(33MHz:32bit:3.3v / 66MHz:32bit:3.3v / AGP(??MHz:32bit?or64bit? yes I know...only here for completeness really...) / PCI-Express (??Mhz/32b?64b?)

right now I'm still completely new and freshly digging into drivers to try anything at all...

running into crazy problems... like an empty function with "void function(void) { return; }" returning an ISI/DSI GrimReaper... despite being empty?
that was from trying to use an updated GCC from adtools archived on os4depot.net

reverted to the SDK provided compiler and that "bug" vanished...

don't have much time each week to devote to testing and coding... 'I basically had a couple of days free and fixed up and debugged the skeletons I had written up but hadn't really done anything beyond minimal "library -> device" conversion on...

Needing to work out how to deal with device ownership... what do I provide to the USB stack...
How to provide data and settings to the USB stack...

Not really proceeding without reading the RKRM Libraries Book and RKRM Devices PDF I have ... though having both my tablets broken certainly makes reading things a lot more difficult (this laptop doesn't have a fully proper Linux install finished yet...)

and I still have to finish working up an adtools cross-compiler install on it that is native to gentoo and not some funky debian/redhat mangled thing.
however as I am working from the sba1/adtools github repo as the only variation of adtools that will build for me...

Kinda stuck with debianized packaging as the only thing that will let me actually do anything beyond "make" for having any kind of installable thing to work with...
*seriously* painful when debian/redhat basic systems aren't what I usually deal with.

Would *LOVE* having any developer take a little bit of time to mentor me through some driver basics.
( mostly I just need the option to discuss what I want to do and find out what my options are so I know a way forward... not really being able to imagine what kind of results to even look for isn't helping me...)

anyway... *need* to deal with the whole device driver level of doing things so I can work out some of the more "crazy" looking parts inside the polymorph-vmm design... as I'm not happy with a few parts that are essentially more fragile than glass that breaks on a "blank slate" install but works on my particular setup.

especially as I am trying to avoid any fixed pathing and using whatever system functionality I can for various details...
if there is already a system function group usable for a task... then I'm working around using them for the task intended.

I already have two *working* XHCI template drivers to work from... just need to work out quite exactly what I need to do and where to do it within an AmigaOS family device driver (I *am* already looking through the AROS subversion sources I irregularly checkout updates of and clone off to a private bitbucket repository)

other than that... if I had an updated python I could use an updated mercurial to show my working to date...
for drivers...I'm still feeling that my code is extremely crude and I have most likely missed details somewhere

I've got a snippet of old code at the beginning of this thread actually.