* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: Mark Chambers @ 2006-02-09 13:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060209003459.0ED30352564@atlas.denx.de>
Wolfgang:>
> Unlikely. To be honest: for me that is not a good enough reason to
> get fingerprinted like a criminal. I guess I stay at home.
>
My apologies on behalf of my country. I've gotten myself on the
excrement list, and I've never even gotten a speeding ticket. We're
supposed to have this thing called the bill of rights that protects our
persons
and effects from search without probable cause. Sigh. Well, maybe
this is to make up for the European fools who gave us ROHS, the
new scourge of hardware designers. How about if I take my own
chances with terrorists and lead, thank you very much.
Rant of the day,
Mark Chambers
^ permalink raw reply
* Re: Common Flash Interface v1.4 and MTD support in Linux-2.4.4 kernel
From: David Woodhouse @ 2006-02-09 11:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: David Antliff, linuxppc-embedded
In-Reply-To: <1139309578.32218.7.camel@yoda.jdub.homelinux.org>
On Tue, 2006-02-07 at 05:52 -0500, Josh Boyer wrote:
> To note, 2.4.4 is ancient. And this whole question would be better
> asked on the MTD mailing list.
No, really it wouldn't. Don't bother asking about 2.4 on the MTD list.
--
dwmw2
^ permalink raw reply
* Re: eldk bug?how to fix
From: Wolfgang Denk @ 2006-02-09 9:07 UTC (permalink / raw)
To: S. Egbert; +Cc: linuxppc-embedded
In-Reply-To: <43EAF0B2.2070902@sbcglobal.net>
In message <43EAF0B2.2070902@sbcglobal.net> you wrote:
>
> # export CROSS_COMPILE=ppc_8xx- (DENK gcc 3.3.3)
> or
> # export CROSS_COMPILE=powerpc-linux- (GNU gcc)
Ummm.... the compiler included with the ELDK is GNU gcc, too.
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
An expert is a person who avoids the small errors while sweeping on
to the grand fallacy.
^ permalink raw reply
* [PATCH 00/10] Updated ML300 & ML403 patches
From: S. Egbert @ 2006-02-09 7:57 UTC (permalink / raw)
To: linuxppc-embedded
> > Really, this isn't statically defined anyway. The bootloader
> > (u-boot or zImage) passes the memory size into the kernel; and in
> > fact the kernel command line; or the board setup code can restrict
> > the amount of mem used by the kernel. XPAR_MEM_* isn't used by the
> > kernel proper at all.
> >
> > - Peter
>
> Thanks for the comments.
>
> Another issue we need to discuss is if/how to support the xilinx
> generated BSP in the kernel proper; but I'll leave that for a
> different email.
>
> If there's enough interest; I'll setup another git tree for the virtex
> specific patches.
I, for one, am interested in helping with the Virtex specific patches.
Is there a URL for this? git://?
S. Egbert
^ permalink raw reply
* eldk bug?how to fix
From: S. Egbert @ 2006-02-09 7:35 UTC (permalink / raw)
To: linuxppc-embedded
> In message <43B459C5.1060206 at chello.nl> you wrote:
> >
> > I've seen these messages before. They were gone when I compiled > using
> > ppc_8xx-gcc compiler of a different ELDK version.
> > What version of ELDK are you using? Which gcc version?
>
> This has nothing to do with ELDK versions, or any other toolchain
> issues.
>
> > >[root at localhost atmlz]# ppc_6xx-gcc -c -o temp atm_aalx.c
> > >atm_aalx.c: In function `main':
> > >atm_aalx.c:201: warning: return type of `main' is not `int'
> > >/tmp/cciJlehe.s: Assembler messages:
> > >/tmp/cciJlehe.s:916: Error: unsupported relocation against r3
> ...
> > > mfmsr r3
> > > ori r3,r3,0x8000
> > > andi. r3,r3,0xffbf
> > > mtmsr r3
>
> It's a user only problem (using symbolic names like "r3" in inline
> assember statements without incuding the proper header files to
> resolve thise names).
I had that exact same problem, ESPECIALLY when pulling in a fresh kernel
tree from kernel.org.
Fixed it by defining the CROSS_COMPILE environment variable or modifying
the Makefile's CROSS_COMPILE to the correct file prefix name, in your
case, it is probaly either
# export CROSS_COMPILE=ppc_8xx- (DENK gcc 3.3.3)
or
# export CROSS_COMPILE=powerpc-linux- (GNU gcc)
Check your PATH... make sure its picking up the right version...
# whereis ppc_8xx-gcc
# ppc_8xx-gcc --version
or
# powerpc-linux-gcc --version
S. Egbert
^ permalink raw reply
* Getting started with Xilinx V4 PPC? (Jaap de Jong)
From: S. Egbert @ 2006-02-09 6:07 UTC (permalink / raw)
To: linuxppc-embedded
XIP in flash won't occur in ML403 reference design until you build a new
bit file with Xilinx side-by-side data fetch option enabled.
^ permalink raw reply
* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: Wolfgang Denk @ 2006-02-09 0:34 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43EA3BC9.4090506@ovro.caltech.edu>
Dear David,
in message <43EA3BC9.4090506@ovro.caltech.edu> you wrote:
>
> You can't convince Wolfgang that someone needs to show up at the
> Embedded Systems Conference in San Jose, CA, in April, then eh!?
Unlikely. To be honest: for me that is not a good enough reason to
get fingerprinted like a criminal. I guess I stay at home.
Ummm... Why don't *you* come to the Embedded World trade show in
Nuremberg next week?
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
"Don't think; let the machine do it for you!" - E. C. Berkeley
^ permalink raw reply
* [PATCH resend, example] PPC-4xx DMA scatter/gather (to user memory)
From: Roger Larsson @ 2006-02-08 23:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <68997D3094017740BB875EB2A425A6EA02C1C11D@VCAEXCH01.hq.corp.viasat.com>
On onsdag 08 februari 2006 21.53, Buhler, Greg wrote:
> Does anyone have any example code they could provide me that shows
> correct usage of the Linux 2.6.x PPC-4xx scatter/gather DMA
> functionality? None of the mainline kernel tree sources or module
> sources seem to use this functionality.
These patches are for 2.4, and scatter/gather works with them
(transfering big images directly to user memory) and using all
channels for multiple purposes...
We have sent two messages to this list about issues in this part of the
kernel. But lets start with example code using the patches.
(part of this could be moved into generic case)
Disclaimer: I have not worked with this code for over a half year
(home with my son)...
#define DRIVER_DMA_IRQ_BASE xyz
#define DRIVER_DMA_TO_IRQ(dma) (DRIVER_DMA_IRQ_BASE + (dma))
#define DRIVER_IRQ_TO_DMA(irq) ((irq) - DRIVER_DMA_IRQ_BASE)
/*
* DMA read
*/
#include <asm/ppc4xx_dma.h>
#include <asm/io.h>
static volatile int driver_dma_status[MAX_PPC4xx_DMA_CHANNELS];
int driver_report_dma_error(const char *call, int ret)
{
switch (ret)
{
case DMA_STATUS_GOOD:
// printk(KERN_DEBUG "driver: %s STATUS_GOOD\n", call);
break;
case DMA_STATUS_BAD_CHANNEL:
printk(KERN_DEBUG "driver: %s STATUS_BAD_CHANNEL\n", call);
break;
case DMA_STATUS_BAD_HANDLE:
printk(KERN_DEBUG "driver: %s STATUS_BAD_HANDLE", call);
break;
case DMA_STATUS_BAD_MODE:
printk(KERN_DEBUG "driver: %s STATUS_BAD_MODE", call);
break;
case DMA_STATUS_NULL_POINTER:
printk(KERN_DEBUG "driver: %s STATUS_NULL_POINTER", call);
break;
case DMA_STATUS_OUT_OF_MEMORY:
printk(KERN_DEBUG "driver: %s STATUS_OUT_OF_MEMORY", call);
break;
case DMA_STATUS_SGL_LIST_EMPTY:
printk(KERN_DEBUG "driver: %s STATUS_SGL_LIST_EMPTY", call);
break;
case DMA_STATUS_GENERAL_ERROR:
printk(KERN_DEBUG "driver: %s STATUS_GENERAL_ERROR", call);
break;
case DMA_STATUS_CHANNEL_NOTFREE:
printk(KERN_DEBUG "driver: %s STATUS_CHANNEL_NOTFREE", call);
break;
default:
printk(KERN_DEBUG "driver: %s STATUS(0x%x)", call, ret);
break;
}
return ret;
}
#ifdef DEBUG_DMA
#define DBG_DMA(call) driver_report_dma_error(#call, call)
#else
#define DBG_DMA(call) call
#endif
/* Forward declaration */
static void driver_dma_irq_handler(int irq, void *dev_id, struct pt_regs
*regs);
// Returns DMA_STATUS
static unsigned driver_init_peripheral_dma(int dmanr, int write)
{
unsigned ret;
if (dmanr < 0 || dmanr >= MAX_PPC4xx_DMA_CHANNELS)
return DMA_STATUS_BAD_CHANNEL;
#ifdef DEBUG
int dma_irq = DRIVER_DMA_TO_IRQ(dmanr);
printk(KERN_INFO "driver: using DMA %d (and IRQ %d) for %s\n", dmanr,
dma_irq, write?"write":"read");
#endif
{
ppc_dma_ch_t p_init = {0,};
// default polarity?
p_init.buffer_enable = 1;
p_init.pl = EXTERNAL_PERIPHERAL;
p_init.pwidth = PW_32;
if(write) p_init.sai = 1; // source address increment on
else p_init.dai = 1; // destination address increment on
// no setup cycles
// no peripheral wait/hold cycles
p_init.cp = PRIORITY_LOW;
p_init.pf = 2; // memory (source) read prefetch
p_init.int_enable = 1;
p_init.etd_output = 0; // shall be 0. but if p_init.tce_enable is 1 this
must be 1. but it makes no dif
#ifdef DEBUG_DMA_IRQ_EVERY_PAGE
p_init.tce_enable = 1; // test only, should be off...
#endif
// shift, control - will be initiated
// mode, addr, ce - only in singel dma transfers
ret = DBG_DMA(ppc4xx_init_dma_channel(dmanr, &p_init));
}
return ret;
}
struct driver_device
{
sgl_handle_t dmalist;
};
// buf is pointer in user memory space
// size is size!
// dmanr is dmanr!
// write=1, transfer from user memory to device
// write=0, transfer from device to user memory
// Note: kiobufs does not exist in 2.6 but this code can be ported with less
// overhead...
static ssize_t driver_io_dma(char *buf, size_t size, int dmanr, int
write) //add parameter [int max_time_ms] for transfer
{
ssize_t ret;
size_t remains;
struct driver_device device = {0,};
struct kiobuf *kp = NULL;
int i, res;
ret = -EAGAIN; // retry should work...
int dma_irq = DRIVER_DMA_TO_IRQ(dmanr);
int transmode;
unsigned long flags;
time_to("io_dma begin");
spin_lock_irqsave(&driver_dma_lock, flags);
if ((ret = request_irq(dma_irq, driver_dma_irq_handler, SA_SHIRQ, "driver",
&device))) {
printk(KERN_ERR "driver: request_irq(%d) IRQ for DMA(%d) failed.\n",
dma_irq, dmanr);
spin_unlock_irqrestore(&driver_dma_lock, flags);
return ret;
}
// Note: Interrupt here gave OOPS - cause dmalist was uninitialized and
handler uses it.
if (DBG_DMA(request_dma(dmanr, "driver")) != DMA_STATUS_GOOD) // TODO:
driver_misc_device.name?
goto out_irqrestore;
// Clean spurious pending interrupts
#ifdef DEBUG_DMA
{
int dma_status = ppc4xx_get_dma_status();
printk(KERN_DEBUG "driver: dma_status when enabling DMA(%d) was 0x%08x,
requesting %d bytes\n", dmanr, dma_status, size);
}
#endif
driver_dma_status[dmanr] = DMA_STATUS_DMA_BUSY; /* changed by interrupt
handler */
// the ppc manual states no dma will start if they for some reason are set...
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};
mtdcr(DCRN_DMASR, status_bits[dmanr]);
spin_unlock_irqrestore(&driver_dma_lock, flags);
/* Interrupts should not happen here... nothing running... status cleared...
*/
//ppc4xx_disable_dma(dmanr); // should be disabled already...
ret = -EAGAIN; // retry should work...
if(write) transmode = DMA_MODE_WRITE;
else transmode = DMA_MODE_READ;
if (DBG_DMA(ppc4xx_alloc_dma_handle(&device.dmalist, transmode, dmanr)) !=
DMA_STATUS_GOOD)
{
spin_lock_irqsave(&driver_dma_lock, flags);
goto out_free_dma; /* reuse return path */
}
ret = -EINVAL; // page unlocked?
//setup kiobuf
res = alloc_kiovec(1, &kp);
if (res < 0 || kp==NULL)
{
printk(KERN_DEBUG "driver readdma: alloc_kiovec failed, res=%d\n", res);
goto out_free_dma_handle;
}
res = map_user_kiobuf(write /*rw 1 = to device, 0 = from device*/, kp,
(unsigned long)buf, size);
if (res != 0)
{
printk(KERN_DEBUG "driver readdma: map_user_kiobuf failed, res=%d\n", res);
free_kiovec(1, &kp);
goto out_free_dma_handle;
}
// NOTE: if I remember correctly this part, lock_kiovec, had to be removed for
// proper function, race when using same partial page from different threads
// (one bit for lock?). But I guess it would be equally dangerous to remove it
// when using swap - most don't...
res = lock_kiovec(1, &kp, 0);
if (res != 0)
{
printk(KERN_DEBUG "driver readdma: lock_kiovec failed, res=%d\n", res);
unmap_kiobuf(kp);
free_kiovec(1, &kp);
goto out_free_dma_handle;
}
//printk(KERN_DEBUG "fill the sg dma list #%d\n", kp->nr_pages);
remains = size;
for (i=0; i<kp->nr_pages; i++)
{
struct page *pg = kp->maplist[i];
//these two tests has never failed so they are probably not needed
//as long as map_user_kiobuf() and lock_kiovec() is successful
if (!VALID_PAGE(pg))
{
printk(KERN_DEBUG "driver: Page not valid\n");
goto out_free_kiobuf;
}
if (!PageLocked(pg))
{
printk(KERN_DEBUG "driver: Page valid but not locked(0x%x)\n", (unsigned
int)page_address(pg));
goto out_free_kiobuf;
}
//calculate physical address and length of mem
phys_addr_t part_start = virt_to_phys(page_address(pg));
size_t part_len = PAGE_SIZE;
if (i==0)
{
part_start += kp->offset;
part_len -= kp->offset;
}
if (part_len > remains)
part_len = remains;
if(write)
(void)DBG_DMA(ppc4xx_add_dma_sgl(device.dmalist, part_start,
(phys_addr_t)NULL, part_len));
else
(void)DBG_DMA(ppc4xx_add_dma_sgl(device.dmalist, (phys_addr_t)NULL,
part_start, part_len));
remains -= part_len;
}
/* User might have cleaned the destination, make sure it is written to memory
before DMA starts */
dma_cache_wback_inv((unsigned long)buf, size); //use for both read and write!
#ifdef DEBUG_DMA
printk(KERN_DEBUG "dma status 0x%08x\n", ppc4xx_get_dma_status()),
printk(KERN_DEBUG "Starting DMA%d!\n", dmanr);
#endif
time_to("io_dma: go");
//do dma transfer
ppc4xx_enable_dma_sgl(device.dmalist);
// this takes time... make sure that driver does not change _status early!
//printk(KERN_DEBUG "enable_dma_sgl done, dma status 0x%08x\n",
ppc4xx_get_dma_status());
if ((ret = wait_event_interruptible_timeout(driver_dma_event,
driver_dma_status[dmanr] != DMA_STATUS_DMA_BUSY, HZ*0.6)) <= 0)
{
unsigned long flags, src_addr, dst_addr;
spin_lock_irqsave(&driver_dma_lock, flags);
ppc4xx_disable_dma_sgl(device.dmalist);
printk(KERN_DEBUG "Wait Interrupted (%d), dma status 0x%08x - cancel
DMA(%d), residue %d\n", ret, ppc4xx_get_dma_status(), dmanr,
ppc4xx_get_dma_sgl_residue(device.dmalist, &src_addr, &dst_addr));
ppc4xx_set_sg_addr(dmanr, 0);
// ppc4xx_disable_dma(dmanr); says that channel is not used...
switch (dmanr) {
case 0:
mtdcr(DCRN_DMACR0, mfdcr(DCRN_DMACR0) & ~DMA_CE_ENABLE);
break;
case 1:
mtdcr(DCRN_DMACR1, mfdcr(DCRN_DMACR1) & ~DMA_CE_ENABLE);
break;
case 2:
mtdcr(DCRN_DMACR2, mfdcr(DCRN_DMACR2) & ~DMA_CE_ENABLE);
break;
case 3:
mtdcr(DCRN_DMACR3, mfdcr(DCRN_DMACR3) & ~DMA_CE_ENABLE);
break;
default:
printk("disable_dma: bad channel: %d\n", dmanr);
}
spin_unlock_irqrestore(&driver_dma_lock, flags);
if (ret == 0) // timeout
ret = -ETIMEDOUT;
goto out_free_kiobuf;
}
time_to("io_dma: wait done");
#ifdef DEBUG_DMA
printk(KERN_DEBUG "Wait Done, dma status 0x%08x\n", ppc4xx_get_dma_status());
#endif
// always run with enabled interrupts
// (void)DBG_DMA(ppc4xx_disable_dma_interrupt(dmanr));
switch (driver_dma_status[dmanr])
{
case DMA_STATUS_TS:
/* peripheral has transfered all its data, question is how much is that? */
{
phys_addr_t src_addr, dst_addr;
ret = ppc4xx_get_dma_sgl_residue(device.dmalist, &src_addr, &dst_addr);
ret = size - ret;
//mark_dirty_kiobuf(kp, ret);
break;
}
case DMA_STATUS_CS:
/* more pheripheral data available than space? or exact match? */
ret = size;
//mark_dirty_kiobuf(kp, ret);
break;
case DMA_STATUS_DMA_ERROR:
/* error occured during transfer */
ppc4xx_disable_dma_sgl(device.dmalist); /* to late? */
printk(KERN_ERR "driver: request dma transfer resulted in error\n");
ret = -EIO;
break;
default:
ppc4xx_disable_dma_sgl(device.dmalist);
printk(KERN_ERR "driver: request dma transfer result unhandled
(dma_status=%d)\n", driver_dma_status[dmanr]);
ret = -EIO;
break;
}
out_free_kiobuf:
{
time_to("io_dma teardown begin");
//end kiobuf
unlock_kiovec(1, &kp);
unmap_kiobuf(kp);
free_kiovec(1, &kp);
time_to("io_dma teardown done");
}
out_free_dma_handle:
//phys_addr_t tmp;
//while (ppc4xx_delete_dma_sgl_element(device.dmalist, &tmp, &tmp) ==
DMA_STATUS_GOOD) {};
//^freed in sgdma ppc4xx_free_dma_handle() now.
/* Disable interrupts - you never know what interrupt handler does with dma
channel othervice */
spin_lock_irqsave(&driver_dma_lock, flags);
ppc4xx_free_dma_handle(device.dmalist);
out_free_dma:
free_dma(dmanr);
out_irqrestore:
free_irq(dma_irq, &device);
/* No more interrupts are possible */
spin_unlock_irqrestore(&driver_dma_lock, flags);
#ifdef DEBUG_DMA
printk(KERN_DEBUG "driver_io_dma returns: %d\n", ret);
#endif
return ret;
}
volatile int irq_count = 0; //debug variable
static void driver_dma_irq_handler(int irq, void *dev_id, struct pt_regs
*regs)
{
unsigned long flags;
int dmanr = DRIVER_IRQ_TO_DMA(irq);
int dma_status = ppc4xx_get_dma_status();
struct driver_device *pDevice = (struct driver_device *)dev_id;
int flag_err = DMA_CH0_ERR | DMA_CH1_ERR | DMA_CH2_ERR | DMA_CH3_ERR;
int flag_ts = DMA_TS0 | DMA_TS1 | DMA_TS2 | DMA_TS3;
int flag_sg = DMA_SG0 | DMA_SG1 | DMA_SG2 | DMA_SG3;
unsigned int status_bits[] = {DMA_CS0 | DMA_TS0 | DMA_CH0_ERR | DMA_SG0,
DMA_CS1 | DMA_TS1 | DMA_CH1_ERR | DMA_SG1,
DMA_CS2 | DMA_TS2 | DMA_CH2_ERR | DMA_SG2,
DMA_CS3 | DMA_TS3 | DMA_CH3_ERR | DMA_SG3};
if (dmanr < 0 || dmanr >= MAX_PPC4xx_DMA_CHANNELS)
{
printk(KERN_DEBUG "driver dma irq handler - dma/irq out of range (%d/%d)\n",
dmanr, irq);
return;
}
spin_lock_irqsave(&driver_dma_lock, flags);
//now works for all dma channels
dma_status = ppc4xx_get_dma_status();
dma_status &= status_bits[dmanr];
if (dma_status)
{
int done=0;
irq_count++; //debug variable
#ifdef DEBUG_DMA
printk(KERN_DEBUG "irq 0x%x #%d\n", dma_status, irq_count);
#endif
if (dma_status & flag_err) //DMA_CHx_ERR
{
printk(KERN_DEBUG "irqhandler - DMA_CH%d_ERR\n", dmanr);
driver_dma_status[dmanr] = DMA_STATUS_DMA_ERROR;
//TODO: stop sg dma here, or it will continue with next element when DMA
SR-flags are cleared
done=1;
}
else if (dma_status & flag_ts) //DMA_TSx
{
#ifdef DEBUG_DMA
printk(KERN_DEBUG "irqhandler - DMA_TS%d\n", dmanr);
printk(KERN_DEBUG "irq#%d 0x%x 0x%08x 0x%08x\n", irq_count, dma_status,
mfdcr(DCRN_ASG3), mfdcr(DCRN_DMACT3));
#endif
driver_dma_status[dmanr] = DMA_STATUS_TS;
done=1;
}
else /*if (dma_status & DMA_CSn)*/
{
//printk(KERN_DEBUG "irqhandler - DMA_CSx\n");
/* set transfer finnished when no sgdma in progress (but device has more
data to send) */
if(!(dma_status & flag_sg)) //we don't need it if all goes well, because we
allocate a large enough buffer
{
#ifdef DEBUG_DMA
printk(KERN_DEBUG "irqhandler - DMA_CS%d end of data\n", dmanr);
#endif
driver_dma_status[dmanr] = DMA_STATUS_CS;
done = 1;
}
}
if (done)
{
/* Stop transfer before returning from interrupt handler
* or next link will be loaded...
*/
if (pDevice->dmalist == 0)
{
#ifdef DEBUG_DMA
printk(KERN_DEBUG "irqhandler - spurious interrupt on channel %d
(status=0x%x)\n", dmanr, dma_status);
#endif
}
else
{
ppc4xx_disable_dma_sgl(pDevice->dmalist);
wake_up(&driver_dma_event); //_interruptible
}
}
//clear dma statusreg, only clear those we have seen
//ppc4xx_clr_dma_status(dma); Clear even those not seen... DANGEROUS!!! (Not
- channel stops)
mtdcr(DCRN_DMASR, dma_status);
}
spin_unlock_irqrestore(&driver_dma_lock, flags);
}
We are actually still using the 2.4 tree with our own patches
to make SGDMA work.
Using a different approach...
1. We need more than one page of descriptors, so we allocate one
at a time. [Doing DMA transfers of hires images directly to user space]
2. Interrupt is handled in a simpler way:
If interrupts are enabled:
* always enable error
* always enable end of transfer interrupts
* only enable terminal count interrupt on last descriptor
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019442.html
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.
http://ozlabs.org/pipermail/linuxppc-embedded/2005-December/021225.html
^ permalink raw reply
* [PATCH] powerpc/ppc: Add missing isyncs in head_fsl_booke.S
From: Becky Bruce @ 2006-02-08 22:41 UTC (permalink / raw)
To: linuxppc-dev
The e500 core reference manual indicates that isync is required
after mtmsr(DE bit) and mtspr DBCR0. Add isyncs to make the code
conform to the spec.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit b9c7e75735829b3dc3d6ba3afa715896d96f1093
tree 08700b171fc4d8ddc6b42e9650261e5f735ebec8
parent 0ebd6b01576657e51c6023803f2de1d1181b67b9
author Becky Bruce <becky.bruce@freescale.com> Wed, 08 Feb 2006 16:29:50 -0600
committer Becky Bruce <becky.bruce@freescale.com> Wed, 08 Feb 2006 16:29:50 -0600
arch/powerpc/kernel/head_fsl_booke.S | 4 ++++
arch/ppc/kernel/head_fsl_booke.S | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 8d60fa9..0abd05f 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -316,6 +316,7 @@ skpinv: addi r6,r6,1 /* Increment */
*/
lis r2,DBCR0_IDM@h
mtspr SPRN_DBCR0,r2
+ isync
/* clear any residual debug events */
li r2,-1
mtspr SPRN_DBSR,r2
@@ -1002,12 +1003,15 @@ _GLOBAL(giveup_fpu)
_GLOBAL(abort)
li r13,0
mtspr SPRN_DBCR0,r13 /* disable all debug events */
+ isync
mfmsr r13
ori r13,r13,MSR_DE@l /* Enable Debug Events */
mtmsr r13
+ isync
mfspr r13,SPRN_DBCR0
lis r13,(DBCR0_IDM|DBCR0_RST_CHIP)@h
mtspr SPRN_DBCR0,r13
+ isync
_GLOBAL(set_context)
diff --git a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S
index 8d60fa9..0abd05f 100644
--- a/arch/ppc/kernel/head_fsl_booke.S
+++ b/arch/ppc/kernel/head_fsl_booke.S
@@ -316,6 +316,7 @@ skpinv: addi r6,r6,1 /* Increment */
*/
lis r2,DBCR0_IDM@h
mtspr SPRN_DBCR0,r2
+ isync
/* clear any residual debug events */
li r2,-1
mtspr SPRN_DBSR,r2
@@ -1002,12 +1003,15 @@ _GLOBAL(giveup_fpu)
_GLOBAL(abort)
li r13,0
mtspr SPRN_DBCR0,r13 /* disable all debug events */
+ isync
mfmsr r13
ori r13,r13,MSR_DE@l /* Enable Debug Events */
mtmsr r13
+ isync
mfspr r13,SPRN_DBCR0
lis r13,(DBCR0_IDM|DBCR0_RST_CHIP)@h
mtspr SPRN_DBCR0,r13
+ isync
_GLOBAL(set_context)
^ permalink raw reply related
* Re: Example PPC-4xx DMA scatter/gather usage
From: David Hawkins @ 2006-02-08 21:31 UTC (permalink / raw)
To: Buhler, Greg; +Cc: linuxppc-embedded
In-Reply-To: <68997D3094017740BB875EB2A425A6EA02C1C11D@VCAEXCH01.hq.corp.viasat.com>
Buhler, Greg wrote:
> Does anyone have any example code they could provide me that shows
> correct usage of the Linux 2.6.x PPC-4xx scatter/gather DMA
> functionality? None of the mainline kernel tree sources or module
> sources seem to use this functionality.
>
> I am working on a driver that runs on an embedded PPC-405gp running
> linux 2.4.21. The driver relies extensively on the PPC’s DMA controller
> using all 4 channels simultaneously. After some research I determined
> that the version of the dma code that was in 2.4.21 had been
> significantly modified in more recent kernel trees. As a result I have
> merged in the 2.6.x version of this code, but am running into some
> trouble with sg transfers. Specifically, after setting up an sgl the
> way I used to with the 2.4.21 kernel, and then kicking off the transfer,
> nothing seems to get transferred. When I attempt to remove sg elements
> from the sgl, the kernel complains saying that I’m trying to remove an
> element from an already empty sgl.
>
> Any help, advice, or examples would be greatly appreciated. Thanks.
Hey Greg,
I haven't tried to use any of the kernel source for DMA control.
I started by writing a simple driver that provides a page of
SDRAM (basically copied the nopage driver from Rubini's 3rd Ed).
Then wrote another driver that provided access to the DCRs.
Using the DCR driver and page driver, I manually loaded the
DMA controller DCRs and triggered transfers.
I know its not something that you'd use in real-life, but
it allowed me to manually think-out what needs to be done
for DMA transfers, and allowed me to control when the transfer
occurred, so that I could capture PCI bus transactions.
It wouldn't take too much to manually setup an S-G DMA with
a couple of smaller-than-a-page transfers.
Let me know if you want the code, for the SDRAM page driver,
and DCRs driver and I'll email it to you.
Once you have the DMA S-G programming interface confirmed, then go
back to the DMA API and see if that conforms to the requirements.
I need to finish some single DMA benchmarks using the manual
method (to check the EBC performance), and then I'll start
looking at the proper way to use DMA within kernel drivers.
Please send updates to the list on your progress.
Cheers
Dave
^ permalink raw reply
* Example PPC-4xx DMA scatter/gather usage
From: Buhler, Greg @ 2006-02-08 20:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
Does anyone have any example code they could provide me that shows
correct usage of the Linux 2.6.x PPC-4xx scatter/gather DMA
functionality? None of the mainline kernel tree sources or module
sources seem to use this functionality.
I am working on a driver that runs on an embedded PPC-405gp running
linux 2.4.21. The driver relies extensively on the PPC's DMA controller
using all 4 channels simultaneously. After some research I determined
that the version of the dma code that was in 2.4.21 had been
significantly modified in more recent kernel trees. As a result I have
merged in the 2.6.x version of this code, but am running into some
trouble with sg transfers. Specifically, after setting up an sgl the
way I used to with the 2.4.21 kernel, and then kicking off the transfer,
nothing seems to get transferred. When I attempt to remove sg elements
from the sgl, the kernel complains saying that I'm trying to remove an
element from an already empty sgl.
Any help, advice, or examples would be greatly appreciated. Thanks.
______________________
Greg Buhler
Embedded INFOSEC Systems
Network Systems Group
ViaSat, Inc
760.476.2699
greg.buhler@viasat.com
[-- Attachment #2: Type: text/html, Size: 4914 bytes --]
^ permalink raw reply
* MPC8248 DPRAM linker script
From: Paul Eaton @ 2006-02-08 20:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Hi,
I am looking for a Linker Script that would be permit me to run a small program entirely in the DPRAM region of a MPC8248. Also, which compiler and linker flags do I need for my PC hosted GNU PPC Cross-compiler? My own attempt, results in the Stack being steered outside of DPRAM. Could anyone please assist?
Thanks,
Paul
[-- Attachment #2: Type: text/html, Size: 1435 bytes --]
^ permalink raw reply
* Need help using JFFS2 as Root Filesystem
From: jimmy liu @ 2006-02-08 20:03 UTC (permalink / raw)
To: linuxppc-embedded
To all,
I need help for my Embedded Linux System. When I use
Ramdisk as the root filesystem, it works fine. When I
change to JFFS2 as the root filesystem, I got the
following message:
=> bootm ff100000
## Booting image at ff100000 ...
Image Name: Linux-2.4.25
Image Type: PowerPC Linux Kernel Image (gzip
compressed)
Data Size: 830399 Bytes = 810.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=16Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.25 (root@localhost.localdomain) (gcc
version 3.3.3 (DENX ELDK6
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock0
rootfstype=jffs2
Warning: real time clock seems stuck!
Calibrating delay loop... 111.00 BogoMIPS
Memory: 14252k available (1312k kernel code, 384k
data, 224k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384
bytes)
Inode cache hash table entries: 1024 (order: 1, 8192
bytes)
Mount cache hash table entries: 512 (order: 0, 4096
bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096
bytes)
Page-cache hash table entries: 4096 (order: 2, 16384
bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Memory resource not set for host bridge 0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society
NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch
(rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version
2.6.1 (20010830)
i2c-algo-8260.o: i2c mpc8260 algorithm module
CPM UART driver version 0.01
ttyS0 on SMC1 at 0x0000, BRG7
ttyS1 on SMC2 at 0x0040, BRG8
ttyS2 on SCC1 at 0x8000, BRG1
ttyS3 on SCC2 at 0x8100, BRG2
Generic RTC Driver v1.07
eth0: FCC1 ENET Version 0.4, 00:08:02:06:00:00
eth1: FCC2 ENET Version 0.4, 00:08:02:46:00:00
eth2: FCC3 ENET Version 0.4, 00:08:02:26:00:00
physmap flash device: d00000 at ff300000
phys_mapped_flash: Found 1 x16 devices at 0x0 in
16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind
2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Oops: kernel access of bad area, sig: 11
NIP: C00AA878 XER: 20000000 LR: C00AA01C SP: C0233CC0
REGS: c0233c10 TRAP: 0300d
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 20000000
TASK = c0232000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00000400 C0233CC0 C0232000 C02AA4E4 C03CB380
00020000 00000000 C03C0000
GPR08: 00D00000 C0238C00 00000000 C00AA164 82002028
00008800 00000000 0000005A
GPR16: 00000000 00000068 C0150000 C0150000 C0150000
C0150000 00CFFFFF 00000000
GPR24: 00D00000 00020000 00000000 C03CB380 00000000
C03CB380 C02AA4E4 00000000
Call backtrace:
C00AAEBC C00AA01C C00AD954 C00AE134 C00AFEAC C00B04C0
C003E83C
C003EC38 C00538C0 C0053C40 C0054178 C0003C98 C00039D8
C0006798
Kernel panic: Attempted to kill init!
<0>Rebooting in 180 seconds..
Could somebody help me figure out what is the problem.
Thanks.
Jimmy
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: David Hawkins @ 2006-02-08 18:43 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602081638.25905.sr@denx.de>
>>Anyways, here are the v1.18 page references;
>>
>>v1.18 p365-6 has the PLB-to-PCI Transaction Handling section
>> showing the cases where MRL and MRM will be used.
>>
>>v1.18 p407 has the PCI Memory to SDRAM DMA transfer section
>> with comments and forward references to the timing
>> diagram pages.
>
>
> Thanks. I have to admit that my only advice to you is, to send these questions
> to the AMCC support. This seems to be a hardware related question/problem.
> Sorry.
No problem! I appreciate you taking the time to look at it.
I'll contact AMCC and see what they have to say.
> Please keep me informed when you get an explanation for this PLB4 DMA
> behaviour.
I will.
> Thanks for the invitation. But our 9 month's old daughter will not "allow" us
> to make such a long trips in the next few years, I am afraid! :-(
Ahh, well come visit in a few years then :)
You can't convince Wolfgang that someone needs to show up at the
Embedded Systems Conference in San Jose, CA, in April, then eh!?
Dave
^ permalink raw reply
* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: Stefan Roese @ 2006-02-08 15:38 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43E79EDD.9010702@ovro.caltech.edu>
Hi David,
On Monday 06 February 2006 20:09, David Hawkins wrote:
> Anyways, here are the v1.18 page references;
>
> v1.18 p365-6 has the PLB-to-PCI Transaction Handling section
> showing the cases where MRL and MRM will be used.
>
> v1.18 p407 has the PCI Memory to SDRAM DMA transfer section
> with comments and forward references to the timing
> diagram pages.
Thanks. I have to admit that my only advice to you is, to send these questions
to the AMCC support. This seems to be a hardware related question/problem.
Sorry.
Please keep me informed when you get an explanation for this PLB4 DMA
behaviour.
> >>(I hope you had a nice vacation Stefan!)
> >
> > Thanks. Very nice. One week of sunshine in the snow. :-)
>
> I hope that means you got some nice snowboarding or skiing!
Yes, skiing! And a little Apres-Ski of course! ;-)
> We have a fun mountain just up the road;
> http://www.mammothmountain.com/
>
> Feel free to come and visit if you are in California anytime!
Thanks for the invitation. But our 9 month's old daughter will not "allow" us
to make such a long trips in the next few years, I am afraid! :-(
Best regards,
Stefan
^ permalink raw reply
* Re: asm-powerpc/highmem.h missing
From: Kumar Gala @ 2006-02-08 15:00 UTC (permalink / raw)
To: Olaf Hering; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20060208124045.GA14370@suse.de>
On Feb 8, 2006, at 6:40 AM, Olaf Hering wrote:
> On Wed, Feb 08, Stephen Rothwell wrote:
>
>> On Wed, 8 Feb 2006 10:34:39 +0100 Olaf Hering <olh@suse.de> wrote:
>>>
>>>
>>> Why was asm-ppc/highmem.h not migrated? linux/highmem.h and
>>> pagemap.h wants it.
>>
>> I guess it was not migrated because it is only required for
>> CONFIG_HIGHMEM
>> and, of course, ppc64 does not need HIGHMEM and presumably noone
>> has tried
>> to build with CONFIG_HIGHMEM set in ARCH=powerpc until now.
>
> zaptel wants it as well, via netdevice.h/skbuff.h. I wonder why 32bit
> compiles anyway, given the many users of linux/highmem.h. Looking...
>
>
>
>
> Argh, still these hacks:
>
> lrwxrwxrwx 1 olaf users 64 2006-02-04 13:16 arch/powerpc/include/
> asm ->
> /home/olaf/kernel/olh/ppc64/linux-2.6.16-rc2-olh/include/asm-ppc/
>
> So better move it over quick.
You do realize there are a slew of headers in include/asm-ppc/ that
we use in the arch/powerpc builds for ppc32.
- kumar
^ permalink raw reply
* Re: [PATCH] powerpc: Thermal control for dual core G5s
From: Kumar Gala @ 2006-02-08 14:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linuxppc64-dev, linuxppc-dev list
In-Reply-To: <Pine.LNX.4.64.0602072206290.2458@g5.osdl.org>
On Feb 8, 2006, at 12:07 AM, Linus Torvalds wrote:
>
>
> On Wed, 8 Feb 2006, Benjamin Herrenschmidt wrote:
>>
>> This patch adds a windfarm module, windfarm_pm112, for the dual
>> core G5s
>> (both 2 and 4 core models), keeping the machine from getting into
>> vacuum-cleaner mode ;)
>
> This seems to introduce a new warning..
>
> arch/powerpc/platforms/83xx/Kconfig:10:
> warning: 'select' used by config symbol 'MPC834x_SYS' refer to
> undefined symbol 'DEFAULT_UIMAGE'
That's my fault. Paul did push a simple build system update. I'll
ask him to do so.
http://ozlabs.org/pipermail/linuxppc-dev/2006-January/020980.html
- kumar
^ permalink raw reply
* Re: How to check which CPU we are using? PPC?
From: David Jander @ 2006-02-08 14:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200602081225331876279@126.com>
On Wednesday 08 February 2006 14:04, jeanwelly wrote:
> Hi,
> Acutally I am asking "Are there any command that os or BSP provided in
> shell to print the CPU information?". Thanks a lot!
One guess: cat /proc/cpuinfo
Will that be it?
Geetings,
--
David Jander
^ permalink raw reply
* Re: Re: How to check which CPU we are using? PPC?
From: jeanwelly @ 2006-02-08 13:04 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Linuxppc-embedded
In-Reply-To: <20060115171949.2EB36353AB0@atlas.denx.de>
SGksDQpBY3V0YWxseSBJIGFtIGFza2luZyAiQXJlIHRoZXJlIGFueSBjb21tYW5kIHRoYXQgb3Mg
b3IgQlNQIHByb3ZpZGVkIGluIHNoZWxsIHRvIHByaW50IHRoZSBDUFUgaW5mb3JtYXRpb24/Ii4g
DQpUaGFua3MgYSBsb3QhDQoNCgkNCg0KPT09PT09PSAyMDA2LTAxLTE2IDAxOjE5OjUyIMT61NrA
tNDF1tDQtLXAo7o9PT09PT09DQoNCj4NCj5JbiBtZXNzYWdlIDw0M0NBN0FGMS4xMTYwOUIuMDM2
NTU+IHlvdSB3cm90ZToNCj4+IFNHOTNJSFJ2SUdOb1pXTnJJSGRvYVdOb0lFTlFWU0IzWlNCaGNt
VWdkWE5wYm1jL0lFRnVlU0J0WlhSb2IyUnpQdzBLRFFvSkRRcFUNCj4+IGFHRnVhM01oRFFvTkNx
R2hvYUdob2FHaG9hR2hvYUdob2FGcVpXRnVkMlZzYkhrTkNxR2hvYUdob2FHaG9hR2hvYUdob2FG
cVpXRnUNCj4+IGQyVnNiSGxBTVRJMkxtTnZiUTBLb2FHaG9hR2hvYUdob2FHaG9hR2hvYUdob2FF
eU1EQTJMVEF4TFRFMURRcGZYMTlmWDE5ZlgxOWYNCj4+IFgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5
ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5Zlh3cE1hVzUxZUhCd1l5MWxiV0psWkdSbFpDQnQNCj4+
IFlXbHNhVzVuSUd4cGMzUUtUR2x1ZFhod2NHTXRaVzFpWldSa1pXUkFiM3BzWVdKekxtOXlad3Bv
ZEhSd2N6b3ZMMjk2YkdGaWN5NXYNCj4+IGNtY3ZiV0ZwYkcxaGJpOXNhWE4wYVc1bWJ5OXNhVzUx
ZUhCd1l5MWxiV0psWkdSbFpBPT0NCj4NCj5QbGVhc2UgZml4IHlvdXIgbWFpbGVyLiBEb24ndCB1
c2UgYmFzZTY0IGVuY3NkaW5nLiBQb3N0ICBwbGFpbiAgdGV4dCwNCj5wbGVhc2UuDQo+DQo+PiBI
b3cgdG8gY2hlY2sgd2hpY2ggQ1BVIHdlIGFyZSB1c2luZz8gQW55IG1ldGhvZHM/DQo+DQo+Q2hl
Y2sgdGhlIHByaW50IG9uIHRoZSBwcm9jZXNzb3I/IENoZWNrIHRoZSBkb2N1bWVudGF0aW9uPyBD
aGVjayAgdGhlDQo+c2NoZW1hdGljcz8NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+DQo+V29sZmdhbmcg
RGVuaw0KPg0KPi0tIA0KPlNvZnR3YXJlIEVuZ2luZWVyaW5nOiAgRW1iZWRkZWQgYW5kIFJlYWx0
aW1lIFN5c3RlbXMsICBFbWJlZGRlZCBMaW51eA0KPlBob25lOiAoKzQ5KS04MTQyLTY2OTg5LTEw
IEZheDogKCs0OSktODE0Mi02Njk4OS04MCBFbWFpbDogd2RAZGVueC5kZQ0KPlVzZSBDKysgdG8g
Y29uZnVzZSB5b3VyIGVuZW1pZXM7IHVzZSBDIHRvIHByb2R1Y2Ugc3RhYmxlIGNvZGUuDQo+DQo+
Lg0KDQo9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCgkJCQ0KDQqhoaGh
oaGhoaGhoaGhoaGh1sINCsDxo6ENCiANCgkJCQkgDQqhoaGhoaGhoaGhoaGhoaGhamVhbndlbGx5
DQqhoaGhoaGhoaGhoaGhoaGhamVhbndlbGx5QDEyNi5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGh
MjAwNi0wMi0wOA0KDQo=
^ permalink raw reply
* Re: asm-powerpc/highmem.h missing
From: Olaf Hering @ 2006-02-08 12:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20060208211600.28252f22.sfr@canb.auug.org.au>
On Wed, Feb 08, Stephen Rothwell wrote:
> On Wed, 8 Feb 2006 10:34:39 +0100 Olaf Hering <olh@suse.de> wrote:
> >
> >
> > Why was asm-ppc/highmem.h not migrated? linux/highmem.h and pagemap.h wants it.
>
> I guess it was not migrated because it is only required for CONFIG_HIGHMEM
> and, of course, ppc64 does not need HIGHMEM and presumably noone has tried
> to build with CONFIG_HIGHMEM set in ARCH=powerpc until now.
zaptel wants it as well, via netdevice.h/skbuff.h. I wonder why 32bit
compiles anyway, given the many users of linux/highmem.h. Looking...
Argh, still these hacks:
lrwxrwxrwx 1 olaf users 64 2006-02-04 13:16 arch/powerpc/include/asm ->
/home/olaf/kernel/olh/ppc64/linux-2.6.16-rc2-olh/include/asm-ppc/
So better move it over quick.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: asm-powerpc/highmem.h missing
From: Olaf Hering @ 2006-02-08 10:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20060208211600.28252f22.sfr@canb.auug.org.au>
On Wed, Feb 08, Stephen Rothwell wrote:
> On Wed, 8 Feb 2006 10:34:39 +0100 Olaf Hering <olh@suse.de> wrote:
> >
> >
> > Why was asm-ppc/highmem.h not migrated? linux/highmem.h and pagemap.h wants it.
>
> I guess it was not migrated because it is only required for CONFIG_HIGHMEM
> and, of course, ppc64 does not need HIGHMEM and presumably noone has tried
> to build with CONFIG_HIGHMEM set in ARCH=powerpc until now.
Well, thats not really true, ppc32 builds/works just fine with that, if you
want to use more than 768MB.
The quickcam kernel module did include pagemap.h, but it works just fine
without it. So nothing needs to be changed in the kernel.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: asm-powerpc/highmem.h missing
From: Stephen Rothwell @ 2006-02-08 10:16 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060208093439.GA9240@suse.de>
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
On Wed, 8 Feb 2006 10:34:39 +0100 Olaf Hering <olh@suse.de> wrote:
>
>
> Why was asm-ppc/highmem.h not migrated? linux/highmem.h and pagemap.h wants it.
I guess it was not migrated because it is only required for CONFIG_HIGHMEM
and, of course, ppc64 does not need HIGHMEM and presumably noone has tried
to build with CONFIG_HIGHMEM set in ARCH=powerpc until now.
Patches accepted :-)
--
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
* asm-powerpc/highmem.h missing
From: Olaf Hering @ 2006-02-08 9:34 UTC (permalink / raw)
To: linuxppc-dev
Why was asm-ppc/highmem.h not migrated? linux/highmem.h and pagemap.h wants it.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* powerCore 6750 nfs mount problem
From: Bora KARTAL @ 2006-02-08 9:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am trying to run linuxppc 2.4.20 with a nfs mounted root file system on=
=20a Force powerCore 6750 board with the following command-line options:
CONFIG_CMDLINE=3D"root=3D/dev/nfs nfsroot=3D15.20.11.58:/root/Linux/Monta=
Vista/opt/montavista/pro/devkit/ppc/7xx/target/ ip=3D15.20.8.204:15.20.11=
.58:15.20.0.0:255.255.0.0:test1:eth0:off"
I am giving a static IP to my target board so have no need to run DHCP cl=
ient on my target board.
My problem is:
The target can not mount to my server Linux machine and gives the followi=
ng error:
Looking up port of RPC 100003/2 on 15.20.11.58
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
I checked the nfs server at my host Linux and it is working properly. Any=
body can help?=20
Thanks,
Bora
######################################################################
Dikkat:
Bu elektronik posta mesaji kisisel ve ozeldir. Eger size=20
gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.=20
Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte,=20
guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki=20
gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi=20
gorusu olmak zorunda degildir.
######################################################################
Attention:=20
This e-mail message is privileged and confidential. If you are=20
not the intended recipient please delete the message and notify=20
the sender. E-mails to and from the company are monitored for=20
operational reasons and in accordance with lawful business practices.=20
Any views or opinions presented are solely those of the author and=20
do not necessarily represent the views of the company.
######################################################################
^ permalink raw reply
* RE: Voyager Video support color depths?
From: Martin Krause @ 2006-02-08 9:29 UTC (permalink / raw)
To: linuxppc-embedded
Hi Russ,
linuxppc-embedded-bounces@ozlabs.org wrote on :
> I had a question about the various video support that has been tested
> with the 2.4.25 DENX Kernel.
>=20
> To date I have had pretty good luck with by making sure I have
> compiled the kernel with the Voyager.h file set at 32 BPP mode.
>=20
> For speed optimization I wanted to cut it back to 16 BPP mode,
> however I couldn't hardly get it to boot the machine after I did this
> change by changing '#define SCREEN_BPP 16'. Most attempts the kernel
You are using an old driver. Please try the current top of git one.
The driver now supports kernel parameters. To set the color depth during
booting you could use for example:
video=3Dvoyager:bpp=3D16
> would lock up before a login prompt was available. When I tried
> SCREEN_BPP at 8 then it booted fine, however QT/Embedded had terrible
> colors.
Support for 8 bpp mode should be improved in the current driver.
> I was wondering if I should be looking for the trouble in some other
> code, or perhaps hardware, or if this is a known bug in the SM501 /
> Voyager driver, or perhaps the linux frame buffer driver.
How is your SM501 connected to your CPU? Which board are you using?
The default configuration of the driver assumes tht the SM501 is
connected via the SH4-Interface, not PCI.
Regards,
Martin
^ 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