8360 UCC_GETH INIT_WORK compile error

8360 UCC_GETH INIT_WORK compile error

[Russell McGuire]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

Kumar / ALL,

 

I was having problems compiling the UCC_GETH driver for 8360.

INIT_WORK declared with 2 parameters instead of 3.

 

Googling around, I noticed that somebody posted a temporary patch back in
December 14, 2006.

 

Has this been resolved?

I am not able to boot the 2.6.19.2 Kernel the moment since the Ethernet/UCCF
driver won't compile.

 

-Russ


[-- Attachment #2: Type: text/html, Size: 2881 bytes --]

RE: 8360 UCC_GETH INIT_WORK compile error

[Li Yang-r58472]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Russ,

 

Please use the latest git tree.  The fix has been merged.

- Leo 

________________________________

From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On
Behalf Of Russell McGuire
Sent: Friday, January 26, 2007 2:07 PM
To: linuxppc-embedded@ozlabs.org
Subject: 8360 UCC_GETH INIT_WORK compile error

 

Kumar / ALL,

 

I was having problems compiling the UCC_GETH driver for 8360.

INIT_WORK declared with 2 parameters instead of 3.

 

Googling around, I noticed that somebody posted a temporary patch back
in December 14, 2006.

 

Has this been resolved?

I am not able to boot the 2.6.19.2 Kernel the moment since the
Ethernet/UCCF driver won't compile.

 

-Russ


[-- Attachment #2: Type: text/html, Size: 4856 bytes --]

Re: 8360 UCC_GETH INIT_WORK compile error

[Kumar Gala]

On Jan 26, 2007, at 12:18 AM, Li Yang-r58472 wrote:

> Russ,
>
> Please use the latest git tree.  The fix has been merged.
>
> - Leo
>
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org =20
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] =20=

> On Behalf Of Russell McGuire
> Sent: Friday, January 26, 2007 2:07 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: 8360 UCC_GETH INIT_WORK compile error
>
> Kumar / ALL,
>
> I was having problems compiling the UCC_GETH driver for 8360.
>
> INIT_WORK declared with 2 parameters instead of 3.
>
> Googling around, I noticed that somebody posted a temporary patch =20
> back in December 14, 2006.
>
> Has this been resolved?
>
> I am not able to boot the 2.6.19.2 Kernel the moment since the =20
> Ethernet/UCCF driver won=92t compile.

As Leo said, 2.6.20-rc6 has the fixes from myself/Timur that address =20
this:
http://master.kernel.org/git/?p=3Dlinux/kernel/git/torvalds/=20
linux-2.6.git;a=3Dcommit;h=3Ddf19b6b020791b4c42e7cf2e4f582454cbc49251
http://master.kernel.org/git/?p=3Dlinux/kernel/git/torvalds/=20
linux-2.6.git;a=3Dcommit;h=3D6bf446522b246194551cf167f0168792080d6118

(not sure if you need the second or not on 2.6.19).

- k=

mem=XXXM ioremap DMA

[Eric Nuckols]

I've seen a couple posts out there about issuing a kernel boot parameter of 
mem=XXXM, say for example mem=504M on a 512 MiB system followed by issuing 
an ioremap function call from a module/driver such as: ioremap( 0x1F800000, 
0x800000 ) where an attempt is made to remap the unclaimed (by the kernel) 
physical memory from 504MiB up to 512MiB.

I've tried this route which looks to make great logical sense and I've tried 
to actually use the remapped range for DMA with no luck.  I've seen posts 
from all the way back in 2003 where folks are doing the same thing and have 
the same bad results... and no replies to the posts.

Can this ram really be used for DMA?

I'm afraid that since I'm using a PCI device (PLX) with device specific 
hardware address decoding on the LOCAL bus side of the PLX, that by taking 
this approach, the kernel comes back with virtual addresses that, after 
being mapped back to bus addresses still won't allow for DMA to work 
properly.   Can anyone give some insight into this?

I'm basically trying the following:
  boot kernel (2.4.xx) with mem=504M

in my driver, I'm calling
my_virt_address =   ioremap( 0x1F800000, 0x800000  );
my_bus_address = virt_to_bus( my_virt_address );

Then, I'm telling my FPGA bus master device (across a PLX chip) that it's 
starting DMA address is my_bus_address.

I get interrupts, but no data in my_virt_address.  I've seen several posts 
exactly like this and have yet to see any answers to these posts...

I've tried an alternative approach of calling one of the alloc_bootmem_xxx 
functions early in start_kernel and have had positivie results ONLY on the 
montavista 3.1 pro kernel with preemption enabled.  On the Denx 2.4.25 
Kernel from ELDK 3.1 I just get a locked up/frozen kernel when I trie to use 
the alloc_bootmem_xx approach and when I use the mem=504M / ioremap 
approach, I don't get any DMA data from either kernel...

Please help!!
Thanks,
Eric

_________________________________________________________________
FREE online classifieds from Windows Live Expo – buy and sell with people 
you know 
http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06

Re: mem=XXXM ioremap DMA

[Sylvain Munaut]

Eric Nuckols wrote:
> in my driver, I'm calling
> my_virt_address =   ioremap( 0x1F800000, 0x800000  );
> my_bus_address = virt_to_bus( my_virt_address );
>
You can't use virt_to_bus on address returned by ioremap AFAIK.

I think you could do
my_bus_address = virt_to_bus(phys_to_virt(0x1f800000));

Altough it slightly misuse the functions ... but that should work.


        Sylvain

Re: mem=XXXM ioremap DMA

[Eric Nuckols]

>
>Eric Nuckols wrote:
> > in my driver, I'm calling
> > my_virt_address =   ioremap( 0x1F800000, 0x800000  );
> > my_bus_address = virt_to_bus( my_virt_address );
> >
>You can't use virt_to_bus on address returned by ioremap AFAIK.
>
>I think you could do
>my_bus_address = virt_to_bus(phys_to_virt(0x1f800000));
>
>Altough it slightly misuse the functions ... but that should work.
>
>
>         Sylvain
>

If I use this approach in a driver, won't I still need to use the ioremap 
function to make sure the kernel does not reassign the virtual addresses to 
some other physical memory locations?

I want to hand off bus address descriptors to a hardware device that will 
perform bus master DMA back into the memory starting at 0x1f800000, but I 
want to make sure the virt addresses don't coincide with anything other than 
this range of memory (no matter what context I'm in 
--ISR/application...etc.etc..).

Thank,
Eric

_________________________________________________________________
Turn searches into helpful donations. Make your search count. 
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG

Re: mem=XXXM ioremap DMA

[Sylvain Munaut]

Eric Nuckols wrote:
>   
>> Eric Nuckols wrote:
>>     
>>> in my driver, I'm calling
>>> my_virt_address =   ioremap( 0x1F800000, 0x800000  );
>>> my_bus_address = virt_to_bus( my_virt_address );
>>>
>>>       
>> You can't use virt_to_bus on address returned by ioremap AFAIK.
>>
>> I think you could do
>> my_bus_address = virt_to_bus(phys_to_virt(0x1f800000));
>>
>> Altough it slightly misuse the functions ... but that should work.
>>
>>
>>         Sylvain
>>
>>     
>
> If I use this approach in a driver, won't I still need to use the ioremap 
> function to make sure the kernel does not reassign the virtual addresses to 
> some other physical memory locations?
mmh, I wasn't clear :
You must do :

my_virt_address =   ioremap( 0x1F800000, 0x800000  );
my_bus_address = virt_to_bus(phys_to_virt(0x1f800000));

The virtual address returned by phys_to_virt won't be really valid ... but it
will be good enough for virt_to_bus. In the end, it will just do
PCI_DRAM_OFFSET + 0x1f800000;


Sylvain

reprogramming boot flash from live kernel

[Eric Nuckols]

I've got a PrPMC800 and I want to bypass using the PPC7-Bug bootloader to 
reprogram the boot flash/kernel image?

Has anybody reprogrammed their bootup flash image while running a live linux 
kernel?

I don't want to re-invent the wheel if it's already been done.

I'm also not sure if U-boot builds and functions easily on the PrPMC800, so 
I hadn't bothered going that route.


Also, is there a way to telnet into PPC bug rather than access it soley from 
the jtag/serial connection?

_________________________________________________________________
Get in the mood for Valentine's Day. View photos, recipes and more on your 
Live.com page. 
http://www.live.com/?addTemplate=ValentinesDay&ocid=T001MSN30A0701

RE: reprogramming boot flash from live kernel

[DI BACCO ANTONIO - technolabs]

> Has anybody reprogrammed their bootup flash image while running a live
linux=20
> kernel?
I think that's not a good thing to do. The kernel could decide to load
something from the flash filesystem that you've overwritten and BOOM!!
Let me know if you find a safe way to do it.

Bye,
Antonio.