* ppc4xx DMA fixes for simultaneous sg transfers
From: ductusrhe @ 2005-12-07 21:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 12046 bytes --]
Linux 2.4.20 (probably 2.6 as well?)
Conclusion:
Scatter/gather DMA is not thread safe.
Background:
1. We run all four dma channels simultaneously in SG mode on the PPC440EP, starting and stopping them in different threads.
2. Also we need to change channel configs between different transfers, i.e. run ppc4xx_init_dma_channel() to set read or write mode.
Problem and cause:
1. All is well when running one channel at a time, but when starting/stopping a new channel during the time another is active can - if you are unlucky - cause problems.
Because all channels SG start/stop bits are in the same register (ASGC), it must not be read then changed and written to the way it was done.
That can cause a channel that is just done, to start again, or a newly started channel to stop.
The register includes a feature that can be used as a semaphore - the read enable (mask) bits, but it was not used correctly in the code, it was enabled for all channels in the start-up.
2. It is said in the comment of ppc4xx_init_dma_channel() that it should only be used once in the start-up. If you comply, you will not have any problem with it.
However, when running this for a channel when other channels are active, can cause channels to stop or maybe never give an interrupt or false interrupts. The method clears the entire status register, not only the bits for the given channel.
Solution:
1. - In ppc4xx_alloc_dma_handle(), do not touch the ASGC register!
- In ppc4xx_enable_dma_sgl() and ppc4xx_disable_dma_sgl(), when setting the ASGC register, only change the given channel.
That's done without reading the register at all, just set/clear the enable bit of the channel to change, then set the MASK_ENABLE for the same channel.
Probably this is the way the register was intended to be handled?
2. - In ppc4xx_init_dma_channel(), only clear the correct bits of the DMASR register, not the whole register.
(The polarity was also not set as it's supposed to in this function, but there exists a patch for that)
I can send a patch with our changes, that works very well and stable, but there are many changes and not all of them in line with the current official version of the files (we handle the sg descriptor list differently). Maybe someone feeling for it will take a look at the changes and make them into the real code, since the above fixes does not interfere with the usage, only improves thread safety.
I have no idea if this has been fixed in some patch already... but I have not seen it on this list anyway.
I'm not a regular poster, just want to help others avoid some of the struggle when running many channels.
/Ronnie Hedlund
Our changed code:
In "ppc4xx_dma.c"
-----------------------
/*
* The comment states that this function should only be run at start-up, and never more.
* That is unacceptable, with the fix it can be run anywhere as long as the given channel is not running.
*/
int ppc4xx_init_dma_channel(unsigned int dmanr, ppc_dma_ch_t * p_init)
{
unsigned int status_bits[] = { DMA_CS0 | DMA_TS0 | DMA_CH0_ERR,
DMA_CS1 | DMA_TS1 | DMA_CH1_ERR,
DMA_CS2 | DMA_TS2 | DMA_CH2_ERR,
DMA_CS3 | DMA_TS3 | DMA_CH3_ERR};
unsigned int polarity;
uint32_t control = 0;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
DMA_MODE_READ = (unsigned long) DMA_TD; /* Peripheral to Memory */
DMA_MODE_WRITE = 0; /* Memory to Peripheral */
if (!p_init) {
printk("ppc4xx_init_dma_channel: NULL p_init\n");
return DMA_STATUS_NULL_POINTER;
}
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_init_dma_channel: bad channel %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
#if DCRN_POL > 0
polarity = mfdcr(DCRN_POL);
#else
polarity = 0;
#endif
/* Setup the control register based on the values passed to
* us in p_init. Then, over-write the control register with this
* new value.
*/
control |= SET_DMA_CONTROL;
switch (dmanr) {
case 0:
/* clear all polarity signals and then "or" in new signal levels */
polarity &= ~GET_DMA_POLARITY(0);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR0, control);
break;
case 1:
polarity &= ~GET_DMA_POLARITY(1);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR1, control);
break;
case 2:
polarity &= ~GET_DMA_POLARITY(2);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR2, control);
break;
case 3:
polarity &= ~GET_DMA_POLARITY(3);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR3, control);
break;
default:
return DMA_STATUS_BAD_CHANNEL;
}
/* save these values in our dma channel structure */
memcpy(p_dma_ch, p_init, sizeof (ppc_dma_ch_t));
/*
* The peripheral width values written in the control register are:
* PW_8 0
* PW_16 1
* PW_32 2
* PW_64 3
*
* Since the DMA count register takes the number of "transfers",
* we need to divide the count sent to us in certain
* functions by the appropriate number. It so happens that our
* right shift value is equal to the peripheral width value.
*/
p_dma_ch->shift = p_init->pwidth;
/*
* Save the control word for easy access.
*/
p_dma_ch->control = control;
/*
* clear status register for the channel
* only TS, CS and RI needs to be cleared.
*/
mtdcr(DCRN_DMASR, status_bits[dmanr]);
return DMA_STATUS_GOOD;
}
In "ppc4xx_sgdma.c"
-----------------------
int
ppc4xx_alloc_dma_handle(sgl_handle_t * phandle, unsigned int mode, unsigned int dmanr)
{
sgl_list_info_t *psgl = NULL;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
//uint32_t sg_command;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_alloc_dma_handle: invalid channel 0x%x\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
if (!phandle) {
printk("ppc4xx_alloc_dma_handle: null handle pointer\n");
return DMA_STATUS_NULL_POINTER;
}
/* Get memory for the listinfo struct */
psgl = kmalloc(sizeof(sgl_list_info_t), GFP_KERNEL);
if (psgl == NULL) {
*phandle = (sgl_handle_t) NULL;
return DMA_STATUS_OUT_OF_MEMORY;
}
memset(psgl, 0, sizeof(sgl_list_info_t));
/* dma_addr is unused now */
psgl->dmanr = dmanr;
/*
* Modify and save the control word. These words will be
* written to each sgl descriptor. The DMA engine then
* loads this control word into the control register
* every time it reads a new descriptor.
*/
psgl->control = p_dma_ch->control;
/* Clear all mode bits */
psgl->control &= ~(DMA_TM_MASK | DMA_TD);
/* Save control word and mode */
psgl->control |= (mode | DMA_CE_ENABLE);
/* PPC Errata? DMA else ignore count on first in list */
psgl->control |= SET_DMA_TCE(1);
/* In MM mode, we must set ETD/TCE */
if (mode == DMA_MODE_MM)
psgl->control |= DMA_ETD_OUTPUT | DMA_TCE_ENABLE;
if (p_dma_ch->int_enable) {
/* Enable channel interrupt */
psgl->control |= DMA_CIE_ENABLE;
} else {
psgl->control &= ~DMA_CIE_ENABLE;
}
/* we must not touch the SGC, it can cause problems to other channels! */
psgl->sgl_control = SG_LINK;
if (p_dma_ch->int_enable) {
if (p_dma_ch->tce_enable)
{
/* reuse as Terminal Count Interrupt Enable on all descr. */
psgl->sgl_control |= SG_TCI_ENABLE;
}
psgl->sgl_control |= SG_ERI_ENABLE | SG_ETI_ENABLE;
}
*phandle = (sgl_handle_t) psgl;
return DMA_STATUS_GOOD;
}
void
ppc4xx_enable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
ppc_dma_ch_t *p_dma_ch;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_enable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_enable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
} else if (!psgl->phead) {
printk("ppc4xx_enable_dma_sgl: sg list empty\n");
return;
}
p_dma_ch = &dma_channels[psgl->dmanr];
psgl->ptail->control_count &= ~SG_LINK; /* make this the last dscrptr */
if (p_dma_ch->int_enable)
{
/* Require Terminal Count interrupt on last */
psgl->ptail->control_count |= SG_TCI_ENABLE;
}
/* No more changes to tail object allowed */
//dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
dma_cache_wback_inv((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
ppc4xx_set_sg_addr(psgl->dmanr, virt_to_phys(psgl->phead));
sg_command = 0;
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_ENABLE | SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_ENABLE | SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_ENABLE | SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_ENABLE | SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_enable_dma_sgl: bad channel: %d\n", psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* start transfer */
}
void
ppc4xx_disable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_disable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_disable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
}
sg_command = 0; //disable dma
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_disable_dma_sgl: bad channel: %d\n", psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* stop transfer */
}
[-- Attachment #2: Type: text/html, Size: 28296 bytes --]
^ permalink raw reply
* Re: Video Card to Lite5200
From: Wolfgang Denk @ 2005-12-07 22:53 UTC (permalink / raw)
To: Frank Bennett; +Cc: linuxppc-embedded
In-Reply-To: <439752BE.9030207@digis.net>
In message <439752BE.9030207@digis.net> you wrote:
>
> The denx.de web site looks great.
Thanks :-)
> Where can someone get this PCI card? Do I have to contact Fujitsu
> directly? Cost?
I guess you have to contact Fujitsu directly; we worked with Fujitsu
Microelectronics Europe.
> The Fujitsu CoralP evaluation board MB86295EB01? or did you use the
Yes.
> Coral PA?
No.
> I saw a posting that you also had some streaming video running. Tell me
> more.
See ftp://ftp.denx.de/pub/fujitsu/Coral-P/README.html
> What resolution? 4CIF (full DVD)
> What display? LCD SVGA (800x600) and/or VGA analog port?
We used a 1024 x 768 LCD.
> Software MPEG decoder or does the Coral have a decoder?
There was no decoder involved at all. The CoralP can stream video
directly, without any CPU load :-) We used the "zvideo" application
for demos - see above.
> Which player did you use?
None. Just a video source like a standard DVD player or a camera.
> Is all this covered in some release notes?
See the README.html
> Was the katix stuff ever integrated into linux_2_4_development?
Yes, it was. See the drivers/spi/ diretory in our linuxppc_2_4_devel
tree, or
http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=tree;h=464f005880de29947ee7d2d8941446c4ba76b0f8;hb=95300e1ab7d8a330784a882db868e355af6d638a;f=drivers/spi
> How does Wolfgang make a living if he spends all his time answering our
> questions?
Dunno. Next question, please :-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Bradley's Bromide: If computers get too powerful, we can organize
them into a committee - that will do them in.
^ permalink raw reply
* Re: Help needed : MCC driver for MPC8260 ADS
From: Manish Joshi @ 2005-12-08 0:09 UTC (permalink / raw)
To: Stevan Ignjatovic, linuxppc-embedded
In-Reply-To: <1133959955.3248.1.camel@stevan.iritel.co.yu>
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
This would also help you a lot.
http://www.ibiblio.org/gferg/ldp/MPC8260-MCC-HOWTO.txt
-Manish
Stevan Ignjatovic <stevan@iritel.com> wrote:
Start point for your MCC driver could be at
http://sourceforge.net/projects/mcc8260/
On Wed, 2005-12-07 at 11:41, s.maiti@tcs.com wrote:
> Hello All,
>
> For our project we need to have a MCC driver for MPC8260 ADS board. I
> couldn't find any driver in the linux source tree for the same.
> Any help in this regard will be highly appreciated.
> Thanks and regards,
>
> Souvik Maiti
> Tata Consultancy Services Limited
> Bengal Intelligent Park
> Bldg. - D, Plots - A2, M2 & N2
> Block - GP, Sector V
> Salt Lake Electronics Complex
> Kolkata - 700091, West Bengal
> India
> Mailto: s.maiti@tcs.com
> Website: http://www.tcs.com
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information.
> If you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If
> you have received this communication in error, please notify us by
> reply e-mail or telephone and immediately and permanently delete the
> message and any attachments. Thank you
>
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
---------------------------------
Yahoo! Shopping
Find Great Deals on Gifts at Yahoo! Shopping
[-- Attachment #2: Type: text/html, Size: 2463 bytes --]
^ permalink raw reply
* Re: Video Card to Lite5200
From: Alessandro Rubini @ 2005-12-08 0:25 UTC (permalink / raw)
To: blofeldus; +Cc: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>
> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).
I just published what I've done (on a previous 2.6.14-rc3 tree by Denx).
It's in ftp://gnudd.com/pub/patches/mpc5200/ (also http://).
I used Sylvain's FEC support, hacked a mb() to make PCI initialize
and ported PIO-mode IDE from 2.4 (with a gross hack about port addresses),
enabled some MTD configurations so cmdlineparts work fine.
/alessandro, who doesn't have a 5200 with him any more.
^ permalink raw reply
* Re: Video Card to Lite5200
From: White @ 2005-12-08 5:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>
Am Wed, 7 Dec 2005 09:23:21 -0800 (PST) schrieb roger blofeld
<blofeldus@yahoo.com> :
> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).
>
> http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
>
> The current kernel.org kernel doesn't appear to support fec/DMA. Is
> there a plan to get networking support into the mainstream kernel?
>
> Thanks
> -rb
>
i think Sylvians should be update in some days. I hope.
you can pull his rep. without problems on current 2.6.15-rc4.
DMA is a problem, because the implementation from Freescale use binary
data, and has some dirty points. This would never be included in the
mainstream kernel. Sylvian has included the new DMA .. works fine for
FEC.
If someone get this new implementtion running with AC97 or PCI would be
fine.
^ permalink raw reply
* patches in powerpc.git tree
From: Paul Mackerras @ 2005-12-08 6:22 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
Here is a list of patches currently in the powerpc.git tree that
aren't already in Linus' tree.
Paul.
Adrian Bunk:
PPC_PREP: remove unneeded exports
Andy Whitcroft:
powerpc: powermac adb fix dependency on btext_drawchar
powerpc: powermac adb fix udbg_adb_use_btext warning
powerpc32: clean up available memory models
powerpc32: fix definition of distribute_irqs
Arnd Bergmann:
spufs: The SPU file system, base
spufs: cooperative scheduler support
spufs: Make all exports GPL-only
spufs: fix local store page refcounting
spufs: Fix oops when spufs module is not loaded
spufs: Turn off debugging output
spufs: Improved SPU preemptability.
spufs: Improved SPU preemptability [part 2].
spufs: fix mailbox polling
cell: add platform detection code
Benjamin Herrenschmidt:
powerpc: Merge align.c (#2)
powerpc: Add OF address parsing code (#2)
powerpc: serial port discovery (#2)
powerpc: Unify udbg (#2)
powerpc: Add back support for booting from BootX (#2)
powerpc: convert macio_asic to use prom_parse
powerpc: Fix g5 build with xmon
powerpc: More serial probe fixes (#2)
powerpc: udbg updates
powerpc: Update OF address parsers
powerpc: Fix a huge page bug
powerpc: Remove debug code in hash path
David Gibson:
powerpc: Remove imalloc.h
powerpc: Make hugepage mappings respect hint addresses
is_aligned_hugepage_range() cleanup
powerpc: Remove ItLpRegSave area from the paca
powerpc: Remove some unneeded fields from the paca
David Woodhouse:
syscall entry/exit revamp
ppc64 syscall_exit_work: call the save_nvgprs function, not its descriptor.
powerpc: serial port discovery: cope with broken firmware
Save NVGPRS in 32-bit signal frame
Fix code that saves NVGPRS in 32-bit signal frame
ppc: Make ARCH=ppc build again with new syscall path
Heiko J Schick:
powerpc: IBMEBUS bus support
Hugh Dickins:
mm: powerpc ptlock comments
mm: powerpc init_mm without ptlock
Kumar Gala:
powerpc: moved ipic code to arch/powerpc
powerpc: Add support for building uImages
powerpc: Fix suboptimal uImage target
linas:
powerpc/pseries: dlpar-add crash on null pointer deref
powerpc: minor cleanup of void ptr deref
Linas Vepstas:
powerpc: PCI hotplug common code elimination
powerpc: make pcibios_claim_one_bus available to other code
powerpc: migrate common PCI hotplug code
PCI Error Recovery: header file patch
powerpc: PCI Error Recovery: PPC64 core recovery routines
powerpc: Split out PCI address cache to its own file
powerpc: Add "partitionable endpoint" support
powerpc: remove bogus printk
powerpc: Remove duplicate code
powerpc: bugfix: fill in uninitialized field
powerpc: Use PE configuration address consistently
powerpc: set up the RTAS token just like the rest of them.
powerpc: Don't continue with PCI Error recovery if slot reset failed.
powerpc: handle multifunction PCI devices properly
powerpc: IOMMU: don't ioremap null addresses
powerpc: Save device BARs much earlier in the boot sequence
powerpc: get rid of per_cpu EEH counters
Marcelo Tosatti:
ppc32: m8xx watchdog update
powerpc/8xx: Fix m8xx_wdt issues
Mark Nutter:
spufs: switchable spu contexts
kernel-side context switch code for spufs
spufs: add spu-side context switch code
Michael Ellerman:
powerpc: Merge kexec
powerpc: Propagate regs through to machine_crash_shutdown
powerpc: Add a is_kernel_addr() macro
powerpc: Separate usage of KERNELBASE and PAGE_OFFSET
powerpc: Add CONFIG_CRASH_DUMP
powerpc: Create a trampoline for the fwnmi vectors
powerpc: Reroute interrupts from 0 + offset to PHYSICAL_START + offset
powerpc: Fixups for kernel linked at 32 MB
powerpc: Add arch dependent basic infrastructure for Kdump.
powerpc: Parse crashkernel= parameter in first kernel
powerpc: Add arch-dependent copy_oldmem_page
powerpc: Add support for "linux,usable-memory" on memory nodes
Michal Ostrowski:
powerpc/pseries: Fix TCE building with 64k pagesize
Mike Kravetz:
Remove SPAN_OTHER_NODES config definition
powerpc: Minor numa memory code cleanup
powerpc: Minor numa memory code cleanup
powerpc: numa placement for dynamically added memory
powerpc/pseries: boot failures on numa if no memory on node
Olaf Hering:
powerpc: correct the NR_CPUS description text
Olof Johansson:
powerpc: remove redundant code in stab init
Otavio Salvador:
ppc: removed unused variable i from code.
Paul Mackerras:
powerpc: Update __NR_syscalls to account for SPU syscalls
ppc: remove duplicate bseip.h
powerpc: Fix up some compile errors in the PCI error recovery code
powerpc/pseries: Optimize IOMMU setup
ppc: Build in all three of powermac, PREP and CHRP support
Revert "powerpc: Minor numa memory code cleanup"
powerpc: Fix typo in head_64.S
Stephen Rothwell:
powerpc: remove arch/powerpc/include hack for 64 bit
powerpc: cleanup iseries irq.c
powerpc: use end_IRQ for iseries irqs
powerpc: partly merge iseries do_IRQ
powerpc: reduce include in irq.c
powerpc: more iseries irq work
powerpc: fix for "Update OF address parsers"
^ permalink raw reply
* Re: patches in powerpc.git tree
From: Stephen Rothwell @ 2005-12-08 6:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17303.53564.160668.376061@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Thu, 8 Dec 2005 17:22:52 +1100 Paul Mackerras <paulus@samba.org> wrote:
>
> Stephen Rothwell:
> powerpc: remove arch/powerpc/include hack for 64 bit
That one is in Linus' tree ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: Add TQM85xx (8540/8541/8555/8560) board support
From: Kumar Gala @ 2005-12-08 7:13 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200512011430.48271.sr@denx.de>
On Dec 1, 2005, at 7:30 AM, Stefan Roese wrote:
> This patch adds support for the TQ Components TQM85xx modules.
> Currently the
> modules TQM8540/8541/8555/8560 are supported.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> Best regards,
> Stefan
> <add-tqm85xx-board-support-2.patch>
Had a question on this, any reason you have to hookup the rtc with an
late_initcall()?
- kumar
^ permalink raw reply
* HR posix timers on mpc8xx??
From: David Jander @ 2005-12-08 8:55 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
With 2.6 now relatively stable running on mpc8xx, I was wondering if someone
has tried to patch in support for High-resolution Posix-timers, as from here:
http://sourceforge.net/projects/high-res-timers
It sounds really attractive, and I wonder why this still isn't officially part
of 2.6?
There is a patch for 2.6.10 for ppc, but I wonder if someone managed to port
it to 2.6.14 (or later) and runs it on an mpc8xx.
Greetings,
--
David Jander
^ permalink raw reply
* mpc823 SCC3 flow control bug
From: debora liu @ 2005-12-08 9:04 UTC (permalink / raw)
To: denx; +Cc: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
Hello denx:
I found one bug when SCC3 as UART, my cpu is mpc823.
cts/cd config as:
CTS PC5
CD PC4
your ELDK-3.1.1 linux-2.4.25 uart.c set pcpar,pcso, pcdir:
immap->im_ioport.iop_pcpar &= ~iobits;
immap->im_ioport.iop_pcso |= iobits;
immap->im_ioport.iop_pcdir &= ~iobits;
but MPC823UM tell me CD3 and CTS3 is bit6 and bit7 on PCSO register, so I modify:
fix_pcso = iobits;
#if defined(CONFIG_UART_CTS_CONTROL_SCC3)
fix_pcso &=~(1 << (15 - CONFIG_CTS3_PIN));
fix_pcso |= 0x0100;
#endif
#if defined(CONFIG_UART_CD_CONTROL_SCC3)
fix_pcso &=~(1 << (15 - CONFIG_CD3_PIN));
fix_pcso |= 0x0200;
#endif
immap->im_ioport.iop_pcpar &= ~iobits;
immap->im_ioport.iop_pcso |= fix_pcso;
immap->im_ioport.iop_pcdir &= ~iobits;
My board have success communication to moderm with SCC3 hard flow control.
debora liu
deboraliu@tom.com
2005-12-08
[-- Attachment #2: fox.gif --]
[-- Type: image/gif, Size: 9519 bytes --]
^ permalink raw reply
* Fix boot on some 12" powerbooks, need testers on others
From: Benjamin Herrenschmidt @ 2005-12-08 10:48 UTC (permalink / raw)
To: Guy Yasko; +Cc: linuxppc-dev list
In-Reply-To: <87bqzs5cio.fsf@oedipa.disorg>
This patch against 2.6.15-rc5 might help fixing boot on some recent
powerbooks like some 12" aluminium. However, I need urgently some
testers with other models of powerbooks and mac mini to tell me if it
causes any regression (that is before tomorrow) so it _might_ have a
chance to make it in 2.6.15.
Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2005-11-19 10:56:07.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2005-12-08 21:45:30.000000000 +1100
@@ -1650,11 +1650,17 @@
*/
if (macio->type == macio_intrepid) {
- if (enable)
- UN_OUT(UNI_N_CLOCK_SPREADING, 2);
- else
- UN_OUT(UNI_N_CLOCK_SPREADING, 0);
- mdelay(40);
+ struct device_node *clock =
+ of_find_node_by_path("/uni-n@f8000000/hw-clock");
+ if (clock && get_property(clock, "platform-do-clockspreading",
+ NULL)) {
+ if (enable)
+ UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+ else
+ UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+ mdelay(40);
+ }
+ of_node_put(clock);
}
while (machine_is_compatible("PowerBook5,2") ||
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c 2005-11-14 20:32:16.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_feature.c 2005-12-08 21:45:48.000000000 +1100
@@ -1606,11 +1606,17 @@
*/
if (macio->type == macio_intrepid) {
- if (enable)
- UN_OUT(UNI_N_CLOCK_SPREADING, 2);
- else
- UN_OUT(UNI_N_CLOCK_SPREADING, 0);
- mdelay(40);
+ struct device_node *clock =
+ of_find_node_by_path("/uni-n@f8000000/hw-clock");
+ if (clock && get_property(clock, "platform-do-clockspreading",
+ NULL)) {
+ if (enable)
+ UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+ else
+ UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+ mdelay(40);
+ }
+ of_node_put(clock);
}
while (machine_is_compatible("PowerBook5,2") ||
^ permalink raw reply
* Re: Fix boot on some 12" powerbooks, need testers on others
From: Michael Hanselmann @ 2005-12-08 11:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Guy Yasko, linuxppc-dev list
In-Reply-To: <1134038881.11760.11.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 208 bytes --]
> However, I need urgently some testers with other models of powerbooks
> and mac mini to tell me if it causes any regression [...]
Works for me on a PowerBook5,8 (15", 1.67 GHz, Oct 2005).
Greets,
Michael
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Netpoll controller support for PPC EMAC driver
From: Ruslan V. Sushko @ 2005-12-08 12:34 UTC (permalink / raw)
To: ebs; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 123 bytes --]
This patch adds netpoll controller support for PPC EMAC driver
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: ppc_emac_napi_netpoll.patch --]
[-- Type: text/x-patch, Size: 4097 bytes --]
This patch adds netpoll controller support for PPC EMAC driver
---
commit a482261f165edb7e6af363d13ea94e8e7429f085
tree b5bee5eb8a971c3f40867946225051e1ff320763
parent e4f5c82a92c2a546a16af1614114eec19120e40a
author Ruslan V. Sushko <rsushko@ru.mvista.com> Thu, 08 Dec 2005 15:22:38 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Thu, 08 Dec 2005 15:22:38 +0300
drivers/net/ibm_emac/ibm_emac_core.c | 42 +++++++++++++++++++++++++++++++++-
drivers/net/ibm_emac/ibm_emac_mal.c | 14 -----------
drivers/net/ibm_emac/ibm_emac_mal.h | 12 ++++++++++
3 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1071,8 +1071,16 @@ static int emac_start_xmit(struct sk_buf
struct ocp_enet_private *dev = ndev->priv;
unsigned int len = skb->len;
int slot;
+ u16 ctrl;
- u16 ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (unlikely(dev->tx_cnt == NUM_TX_BUFF)) {
+ netif_stop_queue(ndev);
+ return -EBUSY;
+ }
+#endif
+
+ ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
MAL_TX_CTRL_LAST | emac_tx_csum(dev, skb);
slot = dev->tx_slot++;
@@ -1938,6 +1946,33 @@ static int emac_ioctl(struct net_device
return -EOPNOTSUPP;
}
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+void
+poll_ctrl(struct net_device *dev)
+{
+ int budget = 16;
+ struct ibm_ocp_mal *mal = ((struct ocp_enet_private*)(dev->priv))->mal;
+ struct net_device *poll_dev = &(mal->poll_dev);
+
+ /* disable MAL interrupts */
+ mal_disable_eob_irq(mal);
+ netif_poll_disable(poll_dev);
+
+ emac_poll_rx(dev->priv, budget);
+ emac_poll_tx(dev->priv);
+
+ netif_poll_enable(poll_dev);
+ /* Enable mal interrupts */
+ mal_enable_eob_irq(mal);
+}
+
+int
+poll_fake(struct net_device *dev, int *budget)
+{
+ /* It will be never invoked */
+ return 0;
+}
+#endif
static int __init emac_probe(struct ocp_device *ocpdev)
{
@@ -2188,6 +2223,11 @@ static int __init emac_probe(struct ocp_
netif_carrier_off(ndev);
netif_stop_queue(ndev);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev->poll_controller = poll_ctrl;
+ ndev->poll = poll_fake;
+#endif
+
err = register_netdev(ndev);
if (err) {
printk(KERN_ERR "emac%d: failed to register net device (%d)!\n",
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c b/drivers/net/ibm_emac/ibm_emac_mal.c
--- a/drivers/net/ibm_emac/ibm_emac_mal.c
+++ b/drivers/net/ibm_emac/ibm_emac_mal.c
@@ -155,20 +155,6 @@ void mal_poll_del(struct ibm_ocp_mal *ma
local_bh_enable();
}
-/* synchronized by mal_poll() */
-static inline void mal_enable_eob_irq(struct ibm_ocp_mal *mal)
-{
- MAL_DBG2("%d: enable_irq" NL, mal->def->index);
- set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
-}
-
-/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
-static inline void mal_disable_eob_irq(struct ibm_ocp_mal *mal)
-{
- set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) & ~MAL_CFG_EOPIE);
- MAL_DBG2("%d: disable_irq" NL, mal->def->index);
-}
-
static irqreturn_t mal_serr(int irq, void *dev_instance, struct pt_regs *regs)
{
struct ibm_ocp_mal *mal = dev_instance;
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -216,6 +216,18 @@ static inline void set_mal_dcrn(struct i
mtdcr(mal->dcrbase + reg, val);
}
+/* synchronized by mal_poll() */
+static inline void mal_enable_eob_irq(struct ibm_ocp_mal *mal)
+{
+ set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
+}
+
+/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
+static inline void mal_disable_eob_irq(struct ibm_ocp_mal *mal)
+{
+ set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) & ~MAL_CFG_EOPIE);
+}
+
/* Register MAL devices */
int mal_init(void) __init;
void mal_exit(void) __exit;
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* Re: Video Card to Lite5200
From: Alan Carvalho @ 2005-12-08 13:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051206203343.67682353F5E@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
Hi Denx,
I still doing some tests with ATI Video cards, as I said before the card
work fine on my PC.
I compiled the 2.6.14 kernel to Lite5200 with /proc/pci support, then when I
execute:
/ # cat /proc/pci
PCI devices found:
Bus 0, device 26, function 0:
Class 0680: PCI device 1057:5803 (rev 0).
Master Capable. Latency=248.
Non-prefetchable 32 bit memory at 0xa0000000 [0xa003ffff].
/ #
It don't list the card placed at PCI slot, on PC using "lspci -v" I see:
0000:00:0c.0 VGA compatible controller: ATI Technologies Inc Rage Mobility
P/M (rev 64) (prog-if 00 [VGA])
Subsystem: 1002:4c52
Flags: bus master, stepping, medium devsel, latency 32, IRQ 10
Memory at ed000000 (32-bit, non-prefetchable) [size=16M]
I/O ports at d800 [size=256]
Memory at ec800000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at 20000000 [disabled] [size=128K]
Capabilities: [5c] Power Management version 1
What you think?
Is it normal Linux on Lite5200 don't show the PCI card info?
I am looking for an "ATI Rage XL Xpert98" because Linux kernel has support
to initialize it without BIOS help (CONFIG_FB_ATY_XL_INIT).
I see some post at some list from people using this board on no x86
platform.
Cheers,
Alan
[-- Attachment #2: Type: text/html, Size: 1812 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
From: Vitaly Bordug @ 2005-12-08 13:40 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-embedded list
In-Reply-To: <1133848163.7932.2.camel@localhost.localdomain>
Matt,
Matthew McClintock wrote:
> On Mon, 2005-11-28 at 10:00 -0700, Vitaly Bordug wrote:
>> + mpc82xx_fcc1_pdata.dpram_offset =
>> mpc82xx_fcc2_pdata.dpram_offset = (u32)cpm2_immr->im_dprambase;
>> + mpc82xx_fcc1_pdata.fcc_regs_c = mpc82xx_fcc2_pdata.fcc_regs_c
>> = (u32)cpm2_immr->im_fcc_c;
>
> I'm not sure if this has already been discussed, but what is stopping us
> from including this in the platform definition files along with the
> other offsets?
IIRC, because these values could vary along the PQ2 family, when all the stuff in pq2_devices.c should be static and applicable to any PQ2 which does have the corresponding device.
>
> -Matthew
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Denx vs kernel.org
From: Marcelo Tosatti @ 2005-12-08 14:31 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051206211459.E8976353F54@atlas.denx.de>
On Tue, Dec 06, 2005 at 10:14:59PM +0100, Wolfgang Denk wrote:
> In message <20051206164212.82779.qmail@web33505.mail.mud.yahoo.com> you wrote:
> > I'm looking at embedding linux into a PowerPC-based
> > system. I found the DENX website to be very helpful,
> > but I'm struggling to understand a few items:
>
> It would be helpful if you precisely stated which of the misc trees
> you are talking about.
>
> > 1) The source from kernel.org appears to have support
> > for the powerpc (arch/powerpc/8xx_io). But when using
> > 'make xconfig' I cannot select PowerPC from the list
> > of processors. Is this just a limitation on the the
> > configuration utility?
>
> Seems like you are trying to use the linux-2.6-denx tree and forgot
> to pass a "ARCH=ppc" argument to "make" (and did not set "ARCH=ppc"
> in your shell environment either).
>
> > 2) What is the difference between the sources on DENX
> > and kernel.org? Are there other places where PPC
>
> We have some stuff added which was submitted as patches to the list
> but not all of this has been accepted for or merged into the
> kernel.org tree yet.
Hi Wolfgang,
Is there a list of your fixes anywhere? Is the linux-2.6-denx tree
public?
^ permalink raw reply
* Re: Netpoll controller support for PPC EMAC driver
From: John W. Linville @ 2005-12-08 14:57 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1134045255.28438.4.camel@mephisto.spb.rtsoft.ru>
On Thu, Dec 08, 2005 at 03:34:15PM +0300, Ruslan V. Sushko wrote:
> This patch adds netpoll controller support for PPC EMAC driver
>
> Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
Patches in-line are easier to review... :-)
> @@ -1071,8 +1071,16 @@ static int emac_start_xmit(struct sk_buf
> struct ocp_enet_private *dev = ndev->priv;
> unsigned int len = skb->len;
> int slot;
> + u16 ctrl;
>
> - u16 ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + if (unlikely(dev->tx_cnt == NUM_TX_BUFF)) {
> + netif_stop_queue(ndev);
> + return -EBUSY;
> + }
> +#endif
Why is this necessary?
> +
> + ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
> MAL_TX_CTRL_LAST | emac_tx_csum(dev, skb);
>
> slot = dev->tx_slot++;
> @@ -1938,6 +1946,33 @@ static int emac_ioctl(struct net_device
> return -EOPNOTSUPP;
> }
> }
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +void
> +poll_ctrl(struct net_device *dev)
> +{
> + int budget = 16;
> + struct ibm_ocp_mal *mal = ((struct ocp_enet_private*)(dev->priv))->mal;
> + struct net_device *poll_dev = &(mal->poll_dev);
> +
> + /* disable MAL interrupts */
> + mal_disable_eob_irq(mal);
> + netif_poll_disable(poll_dev);
Is the call to netif_poll_disable necessary? Aren't NAPI and netpoll
aware of each other?
> +
> + emac_poll_rx(dev->priv, budget);
> + emac_poll_tx(dev->priv);
> +
> + netif_poll_enable(poll_dev);
> + /* Enable mal interrupts */
> + mal_enable_eob_irq(mal);
> +}
> +
> +int
> +poll_fake(struct net_device *dev, int *budget)
> +{
> + /* It will be never invoked */
> + return 0;
> +}
> +#endif
If it's never invoked, then why define it?
>
> static int __init emac_probe(struct ocp_device *ocpdev)
> {
> @@ -2188,6 +2223,11 @@ static int __init emac_probe(struct ocp_
> netif_carrier_off(ndev);
> netif_stop_queue(ndev);
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + ndev->poll_controller = poll_ctrl;
> + ndev->poll = poll_fake;
> +#endif
> +
->poll is not related to ->poll_controller. It is for NAPI, not
netpoll.
I'll defer to others to comment on the IBM EMAC manipulation code.
It looked reasonable to me at first glance.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: Fix boot on some 12" powerbooks, need testers on others
From: Dustin Lang @ 2005-12-08 15:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Guy Yasko, linuxppc-dev list
In-Reply-To: <1134038881.11760.11.camel@gaston>
It boots on my PowerBook6,2 (12" Oct'03).
Cheers,
dstn.
On Thu, 8 Dec 2005, Benjamin Herrenschmidt wrote:
> This patch against 2.6.15-rc5 might help fixing boot on some recent
> powerbooks like some 12" aluminium. However, I need urgently some
> testers with other models of powerbooks and mac mini to tell me if it
> causes any regression (that is before tomorrow) so it _might_ have a
> chance to make it in 2.6.15.
^ permalink raw reply
* Need help for Linux hangs
From: jimmy liu @ 2005-12-08 15:19 UTC (permalink / raw)
To: linuxppc-embedded
I have U-Boot running on a board similar to
MPC8260ADS.
bootargs=root=/dev/ram rw console=ttyS0,115200
When I run command: bootm ff060000 ff260000, the
prompt shows message:
## Booting image at ff060000 ...
Image Name: Linux-2.4.25
Image Type: PowerPC Linux Kernel Image (gzip
compressed)
Data Size: 621131 Bytes = 606.6 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ff260000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip
compressed)
Data Size: 1591658 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 00e07000, end 00f8b96a ... OK
The system hangs here. I have checked in the FAQs
provided in the Denx's site, could not find the
similar case.
I would appreciate any help.
Thanks & Regards,
Jimmy
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: USB on MPC8272
From: Vitaly Bordug @ 2005-12-08 15:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: Nathael PAJANI, linuxppc-embedded
In-Reply-To: <E3409EA9-80FF-4CFF-BF39-F2DE3BA4A609@kernel.crashing.org>
Kumar Gala wrote:
>
> On Nov 30, 2005, at 12:43 AM, Mike Rapoport wrote:
>
>> Nathael PAJANI wrote:
>>
>>> Hi all!
>>>
>>>
>>> I have to support USB hcd for an Actis board based on a MPC8248
>>> processor. I already have a 2.6.9 linux kernel running fine on it,
>>> and actualy have to use it rather than a newer one.
>>> I'm actualy looking for existing or ongoing jobs.
>>
>> Dear Nathael,
>> As far as I understand there are several drivers for the MPC8272 usb
>> host controller, and none of them is in
>> official kernel tree.
>> There's a driver in Metrowerks BSP for linux 2.6 for MPC8272 (the
>> Freescale driver), an orignally mpc8xx driver by Brad Parker ported to
>> linux 2.4 for MPC8272 by Pantelis Antoniou, there ought to be USB
>> driver by ArabellaSW also.
>> My driver ("http://cpm2usb.sourceforge.net./") is a port of the Brad
>> Parker's driver to linux 2.6 with some modifications.
>
> And, ideally we would like to see one driver get into the linux source
> tree that everyone is happy with. I'm told by someone that the FSL
> driver is suppose to have working host support "was tested/verified with
> keyboard/mouse/diskdrives/network".
>
We have that FS driver rework in progress, but even now it's quite hard to estimate the finish. The result will proceed upstream, anyway, but this is long-term I afraid.
> - kumar
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Need help for Linux hangs
From: Vitaly Bordug @ 2005-12-08 16:05 UTC (permalink / raw)
To: jimmy liu; +Cc: linuxppc-embedded
In-Reply-To: <20051208151926.74524.qmail@web53105.mail.yahoo.com>
jimmy liu wrote:
> I have U-Boot running on a board similar to
> MPC8260ADS.
> bootargs=root=/dev/ram rw console=ttyS0,115200
try to set console=ttyCPM0,115200 in the bootargs.
> When I run command: bootm ff060000 ff260000, the
> prompt shows message:
> ## Booting image at ff060000 ...
> Image Name: Linux-2.4.25
> Image Type: PowerPC Linux Kernel Image (gzip
> compressed)
> Data Size: 621131 Bytes = 606.6 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at ff260000 ...
> Image Name: Simple Embedded Linux Framework
> Image Type: PowerPC Linux RAMDisk Image (gzip
> compressed)
> Data Size: 1591658 Bytes = 1.5 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Ramdisk to 00e07000, end 00f8b96a ... OK
>
> The system hangs here. I have checked in the FAQs
> provided in the Denx's site, could not find the
> similar case.
>
> I would appreciate any help.
>
> Thanks & Regards,
>
> Jimmy
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Linux on MPC866
From: Gil Madar @ 2005-12-08 16:10 UTC (permalink / raw)
Hi All,
I'm working on an MPC866 based board. I needed to make changes related to
the RTC, as the MPC866 lacks an RTC, which is one difference between a
MPC860 and an MPC866.
I have no dedicated RTC chip on the board.
I wish to know if somebody ran linux (2.6.14/2.4.25 kernels) on such a
board.
If so: Could [s]he share some insight? what other things to take care of?
Thanks,
Gil
^ permalink raw reply
* Re: [PATCH] ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
From: Kumar Gala @ 2005-12-08 16:14 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <439837D4.7090304@ru.mvista.com>
On Dec 8, 2005, at 7:40 AM, Vitaly Bordug wrote:
> Matt,
> Matthew McClintock wrote:
>> On Mon, 2005-11-28 at 10:00 -0700, Vitaly Bordug wrote:
>>> + mpc82xx_fcc1_pdata.dpram_offset =
>>> mpc82xx_fcc2_pdata.dpram_offset = (u32)cpm2_immr->im_dprambase;
>>> + mpc82xx_fcc1_pdata.fcc_regs_c =
>>> mpc82xx_fcc2_pdata.fcc_regs_c
>>> = (u32)cpm2_immr->im_fcc_c;
>> I'm not sure if this has already been discussed, but what is
>> stopping us
>> from including this in the platform definition files along with the
>> other offsets?
> IIRC, because these values could vary along the PQ2 family, when
> all the stuff in pq2_devices.c should be static and applicable to
> any PQ2 which does have the corresponding device.
How much variation is there? I'm not sure how or why it would be
different from how we handle the FEC and TSEC on 8540.
- kumar
^ permalink raw reply
* Re: linux 2.4 on Xilinx ml403
From: Peter Ryser @ 2005-12-08 16:14 UTC (permalink / raw)
To: Paulinha; +Cc: linuxppc-embedded
In-Reply-To: <259581790512070010s3be8b3cfg6cfd17d2f503b0f7@mail.gmail.com>
Make sure your system.mss contains something like:
BEGIN OS
PARAMETER OS_NAME = linux_mvl31
PARAMETER OS_VER = 1.01.a
PARAMETER PROC_INSTANCE = ppc405_0
PARAMETER MEM_SIZE = 0x4000000
PARAMETER PLB_CLOCK_FREQ_HZ = 100000000
PARAMETER connected_periphs =
(RS232_Uart,IIC_EEPROM,SysACE_CompactFlash,Ethernet_MAC,opb_intc_0)
END
If it does not use XPS and in the menu select Platform Software
Settings. Use linux as Operating System and linux_mvl31_v1_01_a as the
MLD. The rerun the library generation. Also make sure that you have
enabled the interrupts for System ACE CF in the hardware.
- Peter
Paulinha wrote:
> Hi all,
>
> I have been trying to run linux 2.4.26 on Virtex 4 for a while and
> without success.
>
> I am trying to implement a simple design, with an UART, SystemACE and
> everything interrupt driven. When I try to make bzImage, there is an
> error in (SysACE) adapter.c file, because XPAR_INTC_0_SYSACE_0_VEC_ID
> is not defined.
>
> I have applied the patch given by Xilinx for switching from the ml300
> to the ml403, which copies the bsp, .config and xparameter files into
> the kernel.
>
> I am stucked here, and do not know how to keep going from that.
> Could anyone help me a little bit?
>
> Thanks and have a good day!
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Netpoll controller support for PPC EMAC driver
From: Ruslan V. Sushko @ 2005-12-08 17:13 UTC (permalink / raw)
To: John W. Linville; +Cc: linuxppc-embedded
In-Reply-To: <20051208145714.GA16049@tuxdriver.com>
Please see my answers bellow.
John W. Linville wrote:
> On Thu, Dec 08, 2005 at 03:34:15PM +0300, Ruslan V. Sushko wrote:
>
>> This patch adds netpoll controller support for PPC EMAC driver
>>
>> Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
>>
>
> Patches in-line are easier to review... :-)
>
>
>> @@ -1071,8 +1071,16 @@ static int emac_start_xmit(struct sk_buf
>> struct ocp_enet_private *dev = ndev->priv;
>> unsigned int len = skb->len;
>> int slot;
>> + u16 ctrl;
>>
>> - u16 ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> + if (unlikely(dev->tx_cnt == NUM_TX_BUFF)) {
>> + netif_stop_queue(ndev);
>> + return -EBUSY;
>> + }
>> +#endif
>>
>
> Why is this necessary?
>
When netpoll controller is enabled and packets are trapped bay netpoll
controller the netif_stop_queue function does nothing. As result the
packets which are queued for send may be overwritten/corrupted, because
CPU insert packets significantly faster then netdev send them.
>
>> +
>> + ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
>> MAL_TX_CTRL_LAST | emac_tx_csum(dev, skb);
>>
>> slot = dev->tx_slot++;
>> @@ -1938,6 +1946,33 @@ static int emac_ioctl(struct net_device
>> return -EOPNOTSUPP;
>> }
>> }
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> +void
>> +poll_ctrl(struct net_device *dev)
>> +{
>> + int budget = 16;
>> + struct ibm_ocp_mal *mal = ((struct ocp_enet_private*)(dev->priv))->mal;
>> + struct net_device *poll_dev = &(mal->poll_dev);
>> +
>> + /* disable MAL interrupts */
>> + mal_disable_eob_irq(mal);
>> + netif_poll_disable(poll_dev);
>>
>
> Is the call to netif_poll_disable necessary? Aren't NAPI and netpoll
> aware of each other?
>
In this case the device instance passed to netpoll controller
functionality is not the same which used by NAPI. As result conflict
will occurred if netpoll controller invokes polling in the time of NAPI
poll working. Please see my comments below.
>
>> +
>> + emac_poll_rx(dev->priv, budget);
>> + emac_poll_tx(dev->priv);
>> +
>> + netif_poll_enable(poll_dev);
>> + /* Enable mal interrupts */
>> + mal_enable_eob_irq(mal);
>> +}
>> +
>> +int
>> +poll_fake(struct net_device *dev, int *budget)
>> +{
>> + /* It will be never invoked */
>> + return 0;
>> +}
>> +#endif
>>
>
> If it's never invoked, then why define it?
>
Please see my comments bellow.
>
>>
>> static int __init emac_probe(struct ocp_device *ocpdev)
>> {
>> @@ -2188,6 +2223,11 @@ static int __init emac_probe(struct ocp_
>> netif_carrier_off(ndev);
>> netif_stop_queue(ndev);
>>
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> + ndev->poll_controller = poll_ctrl;
>> + ndev->poll = poll_fake;
>> +#endif
>> +
>>
>
> ->poll is not related to ->poll_controller. It is for NAPI, not
> netpoll.
>
The main idea is devices passed to netpoll controller are not the same
which is used for NAPI. This driver has three net_device instances. One
is virtual device which is used only for NAPI (for this device real NAPI
poll function is defined) and two others are usual devices without NAPI.
For each of these two devices poll handlers functions are defined
(emac_poll_rx and emac_poll_tx) which are invoked from NAPI device poll
handler. Function emac_poll_rx uses netif_receive_skb function to pass
skbs to high level. To pass skb to netpoll controller via
netif_receive_skb function the poll field must be defined:
-------------------- cut from netif_receive_skb (net/dev.c) ----------
if (skb->dev->poll && netpoll_rx(skb))
return NET_RX_DROP;
--------------------------------------------------------------------------------
So the poll_fake function and poll field are defined and initialized
only to cheat netif_receive_skb function. In same time the poll_fake
will be never invoked because devices for whom this function is defined
are not NAPI devices.
Thank you,
Ruslan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox