I've been looking at the __adeos_init_domain function with printk statements.
It looks like the ppc64's 64 bits
for unsigned long's have hosed up the positions of the structure elements. The
adp->m_link and adp->flags
both come back as zero from the call to the init_domain function. They were
non-zero in the function. I'll have
to re-compute the relative addresses for the structure elements.
Thanks,
Terry
________________________________
From: [EMAIL PROTECTED] on behalf of Philippe Gerum
Sent: Wed 2/23/2005 12:32 PM
To: Reynolds, Terry (Contractor-SIMTECH)
Cc: adeos
Subject: Re: [Adeos-main] Porting question
Reynolds, Terry (Contractor-SIMTECH) wrote:
> My apologies for being vague! I'd never looked at the 2.4 tree & didn't know
> there was a ppc port there, I'm working on a ppc64, 2.6 port.
>
> I have a newfound appreciation for everyone porting ppc drivers to ppc64, the
> differences are huge.
>
> My specific problem is in using the RTAI sample test (latency), via the
> adeos/generic.c implementation. In adeos_register_domain, when the root
> domain (linux) calls the adeos_switch_to function, the link register value
> stored for the RTAI_hal domain isn't set up properly to return to the
> register_domain function.
>
> At least I assume that's what's happening, since my system crashes in the
> adeos_switch_domain function, or in returning from there.
>
> This would be much easier to work on if there was a kdb available for ppc64!
> Printk statements, with the kernel crashing every time I run the program is
> very time consuming.
>
> My question is: in the process of registering a domain, when does it's stack
> get setup so that a call to switch domain will pull up the correct value to
> place in the link register so that the switch function will know where to
> return to?
>
>
__adeos_init_domain(). Really. Excerpt:
ksp[19] = (_cpuid == cpuid); /* r3 */
ksp[25] = (unsigned long)attr->entry; /* lr <====== */
ksp[26] = flags & ~MSR_EE; /* msr */
PS: please ask your mail client to wrap lines. (My 2700 inches CRT does
not fit on my office desk...)
> Thanks,
>
>
> Terry
>
> _______________________________________________
> Adeos-main mailing list
> [email protected]
> https://mail.gna.org/listinfo/adeos-main
--
Philippe.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
