ELDK Fedora Core 9

ELDK Fedora Core 9

[Russell McGuire]

Guys,

I know that DENX doesn't list ELDK 4.1 with FC9 as officially supported, but
has anyone tried to install it with FC9?

Attempts last night resulted in the install script freezing during install,
and no apparent error messages.

1) Has anyone tried this? Success?
2) Does anyone have suggestion on how turn on debugging with the install
script?

Thanks

-Russ

Re: ELDK Fedora Core 9

[Wolfgang Denk]

Dear "Russell McGuire",

In message <2EA59411B5534D8893C7CB74569C2DC2@absolutdaddy> you wrote:
> 
> I know that DENX doesn't list ELDK 4.1 with FC9 as officially supported, but
> has anyone tried to install it with FC9?
> 
> Attempts last night resulted in the install script freezing during install,
> and no apparent error messages.

Where exactly did it hang? What was the command you used, and what was the exact output?

> 1) Has anyone tried this? Success?

I tried it now, and it got stuck indeed:

...
Preparing...                ########################################### [100%]
   1:db4-devel-ppc_4xx      ########################################### [100%]
Preparing...                ########################################### [100%]
   1:db4-utils-ppc_4xx      ########################################### [100%]
Preparing...                ########################################### [100%]
   1:glib2-ppc_4xx          ########################################### [100%]
Preparing...                ########################################### [100%]
   1:glib2-devel-ppc_4xx    ########################################### [100%]
Preparing...                ########################################### [100%]

<hangs here>

> 2) Does anyone have suggestion on how turn on debugging with the install
> script?

It's not a a script, but a binary, so you are limited to  tools  like
strace, ltrace etc.

In my case I see this:

# strace -p 21197
Process 21197 attached - interrupt to quit
futex(0x96fe17c, FUTEX_WAIT_PRIVATE, 1, NULL

i. e. it's hanging in a futex call. [Futextes have often before  been
a major PITA].

A quick workaround seems to be to build the installer on  the  native
(Fedora  9) system; download the source and the Makefile from the git
repository:

http://git.denx.de/?p=eldk/build.git;a=tree;f=install;h=5f1a9bb9ca5757f4efbca7ff4f48bf869a2ef949;hb=90ed3ca5e1163d771badf1c26f76e95d95e13990

and run:

$ make TARGET_ARCH=ppc

Then use this "install" binary to replace 

Then reboot, and then try again.  Note  that  the  reboot  is  really
necessary,  or  at least I do not know of any other way to get rid of
the stuck futexes.


BTW: ELDK related questions are better posted on the ELDK mailing
list, see http://lists.denx.de/mailman/listinfo/eldk

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
People seldom know what they want until you give them what  they  ask
for.

virt_to_phys() in drivers w/dma - MPC8xxx

[Russell McGuire]

A style / function question. I have been seeing conflicting articles and
examples on what the proper method would be for some of the Freescale MPC
drivers. I am putting together an ATM driver, and 'might' be having some
erratic results due to this function. Not sure yet, but wanted to put this
out there for comments.

In many cases when dealing with TxBD or RxBD pointers a UCC or what not
driver will use the virt_to_phys() call to get what I assume is a physical
address that can be used for dma? Perhaps not in all cases, but a majority.
See ucc_geth.c for an example of the usage. I have also seen some prototype
drivers that use this call to get the physical address to place into the
QE_MURAM for the PRAM initialization.

I then ran across this link:

http://mirror.linux.org.au/linux.conf.au/2005/cdrom-beta-1/linux-mandocs-2.6
.12.6/virt_to_phys.html

Which states:

The returned physical address is the physical (CPU) mapping for the memory
address given. It is only valid to use this function on addresses directly
mapped or allocated via kmalloc.  This function does not give bus mappings
for DMA transfers. In almost all conceivable cases a device driver should
not be using this function.
-----------

So shouldn't we be using like dma_alloc_coherent, and then tracking the dma
address separately as a variable, and use it when necessary instead of
calling virt_to_phys()?

Or am I confused on what these are doing?

-Russ

Re: virt_to_phys() in drivers w/dma - MPC8xxx

[Scott Wood]

Russell McGuire wrote:
> So shouldn't we be using like dma_alloc_coherent, and then tracking the dma
> address separately as a variable, and use it when necessary instead of
> calling virt_to_phys()?

Yes.  On 8xxx (but not 8xx, and not with 36-bit memory), there'll be no 
practical difference, but the DMA mapping API *should* be used.

-Scott