* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060210173133.964B53525CC@atlas.denx.de>
>>Of course there is also the option of finding another
>>PowerPC that matches my requirements;
>
> ...
>
> MPC834x comes to mind. But I have to admit that we never tried using
> this as a PCI device yet...
>
Thanks Wolfgang, I'll take a look at the user manual.
Regarding PowerPC devices that can be (uselessly) configured
as PCI agents/targets/peripherals;
- the Artesyn PMC board I got from eBay contains the
IBM CPC700 bridge - it can never generate PCI interrupts
as a target (non-monarch mode).
- the MPC5200 PowerPC, can also be configured as a target,
but will never generate PCI interrupts.
Gee, who knew. I didn't :)
Dave
^ permalink raw reply
* Stability of MPC5200 FEC
From: Asier Llano Palacios @ 2006-02-10 17:20 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sylvain Munaut, John Rigby
We are working with MPC5200 cpu.=20
We've been using it since early 2.6 kernel versions.
We're currently quite stabilished with the version of the kernel Sylvain
had before the Platform Device rework. But the problem is that we are
experiencing that the FEC stops working after a long uptime.
So, do you think that the current git version is more stable than the
one we are using? Do you think that there is anything that could stop us
upgrading to the latest version?
The problem is that we have a custom board, with some custom devices, so
it is not so easy to upgrade. We need to know that a new version, is
more stable than the previous one, before we upgrade. As soon as we
upgrade, we can help if we find any problem.
Thank you,
Asier Llano
--=20
Asier Llano Palacios
ZIV I+D Smart Energy Networks
Dpto. Ingenier=EDa de Desarrollo.
ZIV, Aplicaciones y Tecnolog=EDa.
Parque Tecnol=F3gico, 210
48170 ZAMUDIO (Bizkaia)
E-mail: a.llano@ziv.es
Tlfno: (+34)944037400=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
=B5SysCom uses virus scanning software but excludes any liability for =
viruses contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
=B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Wolfgang Denk @ 2006-02-10 17:31 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ECC7CE.1010409@ovro.caltech.edu>
Dear David,
in message <43ECC7CE.1010409@ovro.caltech.edu> you wrote:
>
> Of course there is also the option of finding another
> PowerPC that matches my requirements;
...
MPC834x comes to mind. But I have to admit that we never tried using
this as a PCI device yet...
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
I can type faster than I can move a mouse, so I find menu-driven
drawing packages time consuming and frustrating. - W. R. Stevens
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:26 UTC (permalink / raw)
To: Andrew Armitage; +Cc: linuxppc-embedded
In-Reply-To: <43ECCB4D.9080602@varisys.co.uk>
> We've used the 21555 on a couple of our designs (mated to a 7457/107
> pair) and have never had too many problems with them. The messaging
> unit has been very helpful.
>
> Just my $0.02,
Hey Andrew,
Thanks!
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:05 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602100847.54363.sr@denx.de>
Hi Stefan,
Thanks for confirming my analysis.
There's actually an additional issue with the 440EP
for my application. I'll be using it in a 5V PCI
environment (due to the reuse of the existing host
CPUs). Since the 440EP is not 5V tolerant, I figured
I would add clamps or buffers to the board design.
However, given the meager host-to-host communications
features, I think I would be better off putting an
Intel 21555 non-transparent bridge on the board.
That will provide 5V tolerance, and a full set of
messaging unit and I2O facilities. All for $50-80
or so according to the single-piece pricing from
Digikey. I'm not so happy to need to add another
chip, but if the 440EP passes all the other
benchmark requirements, then it seems the least
painful way to proceed.
Has anyone reading this list had good or bad experiences
with the Intel 21555 or perhaps some of the PLX offers,
eg. PCI 6254?
If only the GX/SP had an FPU ...
Of course there is also the option of finding another
PowerPC that matches my requirements;
- 300-500MHz CPU
- ~2W
- FPU
- three independent buses; SDRAM, PCI, external
- the external bus will contain multiple FPGAs
that generate 128kB of data every 10ms or so.
The data needs to be DMAed to SDRAM, where
the host CPU can convert it to float, FFT
it, process, and average the data. Transfers
to host over PCI occur every 100ms.
FPGA-to-SDRAM should occur in ~1ms;
128kB/1ms = 128MB/s
There will be up to 20 boards in a crate,
and transfers from all 20 boards need to
complete in 100ms, so
FPGA-to-host should occur in ~5ms;
128kB/5ms = 25MB/s
So I don't need stunning PCI performance, but
I do need a reasonable external memory bus
bandwidth.
The 440EP 16bit/66MHz 132MB/s would just meet
my requirement (and I can handle a 50% drop
in bus bandwidth if benchmarks go that way).
The PCI performance hits 50MB/s, so its ok.
I don't want to use a local-bus PCI interface
with the FPGAs, since then I'd need a PCI core
in each. I typically pack the FPGAs to 90%
with processing logic, so can't afford the
space for a complex host-to-FPGA interface.
I think I've shown you the current boards (that
use a TI DSP);
http://www.ovro.caltech.edu/~dwh/correlator
I had looked at the MPC8245 processor a while back,
but its SDRAM interface is multiplexed with its external
memory bus, so DMA from the external bus to SDRAM
would likely be pretty poor.
Do you have any experience with features of the PowerQUICC
processors? I've tried to avoid a full-up G4/G5 processor
since they typically also require a system controller
chip, and consume a lot more power.
I had also considered using a ColdFire processor, but
went with the PowerPC since I'll be using some Virtex
FPGAs with the PowerPC in a future project.
Anyway, just thought I'd give you an idea of what I'm
trying to figure out.
Cheers,
Dave
^ permalink raw reply
* Re: mv-linux: Problem to implement custom driver interrupt handling
From: Eckart Göhler @ 2006-02-10 15:25 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <43E767DE.4060003@ru.mvista.com>
Andrei Konovalov wrote:
> Hi,
>
> In the Linux driver you should not access the interrupt controller
> directly.
> The relevant XIntc_* calls are done by arch/ppc/syslib/xilinx_pic.c code.
> E.g. the particular interrupt is unmasked when one calls request_irq().
>
> Few more comments below.
Hi,
Thanks a lot. Actually I inserted the low-level code below after
request_irq() did not work. The note about xilinx_pic.c code (that is
located in my implementation in arch/ppc/kernel/xilinx_pic.c) lead me to
the problem origin that should be reported here for the community (which
I presume already know the very fact):
The interrupt numbering generated by the EDK is opposite to the one used
by linux, i.e. interrupt number 4 reported in EDK-generated
xparameters.h/xparameters_ml300.h becomes 31-4 = 27 when using request_irq.
Therefore the handler was not called because he was attached to the
wrong interrupt, and also was not able to reset the interrupt pending
flag, that must be done as you noted below.
cheers
eckart
>
>
> Thanks,
> Andrei
>
>
> Eckart Göhler wrote:
>> Hi,
>>
>> We try to run montavista Linux pro 3.1 on an ml300 like embedded
>> system on an Virtex V2-Pro system. The system works fine with UART,
>> Xilinx enet
>> driver (booting with Das U-Boot).
>> Now we try to implement some custom GPIO driver that must be triggered
>> from outside interrupts. Polling for data works fine but the handler
>> for HW-timer interrupts does behaves strange.
>>
>> The relevant Linux driver part that requests the interrupt and starts
>> the timer look like below.
>>
>> Installing such a driver works but
>> - No report of driver interrupt called is sent
>> - installing the driver results in a system that almost gets stuck and
>> has poor response (~sec) till the driver is rmmodded.
>>
>> Checking the implementation with native Xilinx example timer
>> application works fine, provided the Xilinx exception handling is
>> implemented.
>>
>> Its not clear for me whether on ppc environment something specific
>> must be done for custom interrupts, though implementation of
>> xilinx_enet/xilinx_uartlite does not hint for something specific.
>>
>>
>> sincerely
>>
>> eckart goehler
>>
>>
>> -----------------------------------------------------------------(snip)
>>
>> // driver snippet that reacts on timer interrupts:
>>
>> // timer\interrupt base addresses, modified by ioremap:
>> unsigned long timer_base, interrupt_base;
>>
>>
>> /* interrupt handler: */
>> static
>> void drv_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs)
>> {
>> printk(KERN_INFO DEVICE_NAME "interrupt occurred\n");
>
> Most probably you should clear the interrupt source here.
> Otherwise you could get back into the interrupt handler as
> soon as you return from it due to the interrupt request still
> being active.
>
>> }
>>
>>
>>
>> static int __init drv_init_module(void)
>> {
>>
>> interrupt_base = (unsigned long)
>> ioremap(XPAR_INTC_BASEADDR,XPAR_INTC_HIGHADDR-XPAR_INTC_BASEADDR);
>> timer_base = (unsigned long)
>> ioremap(XPAR_TIMER_BASEADDR,XPAR_TIMER_HIGHADDR-XPAR_TIMER_BASEADDR);
>>
>> // install interrupt handler:
>> if (request_irq(DRV_IRQ, commdrv_interrupt_handler,
>> 0, DEVICE_NAME, NULL)
>> )
>
> You call request_irq() (i.e. unmask this interrupt) too early.
> Configure the timer first.
>
>> {
>> printk(KERN_INFO DEVICE_NAME ": can¢t get assigned irq %i\n",
>> COMM_IRQ
>> );
>> }
>> else { /* enable interrupt */
>>
>> printk(KERN_INFO DEVICE_NAME ": interrupt installed\n");
>>
>> /* Start the interrupt controller */
>> XIntc_mMasterEnable(interrupt_base);
>
> - must not be used in the driver
>
>> // here: enable timer interrupt:
>> /* Set the number of cycles the timer counts before interrupting */
>> XTmrCtr_mSetLoadReg(timer_base, 0, TIMER_VALUE * 80000000l);
>>
>>
>> printk(KERN_INFO DEVICE_NAME ": clear timer\n");
>>
>> /* Reset the timers, and clear interrupts */
>> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_INT_OCCURED_MASK
>> | XTC_CSR_LOAD_MASK );
>>
>> printk(KERN_INFO DEVICE_NAME ": enable interrupt\n");
>>
>> /* Enable timer interrupts in the interrupt controller */
>>
>> XIntc_mEnableIntr(interrupt_base, DRV_IRQ_MASK);
>
> - must not be used in the driver. Unmasking the interrupt is done inside
> request_irq().
>
>> //printk(KERN_INFO DEVICE_NAME ": start timer\n");
>> /* Start the timers */
>> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_ENABLE_TMR_MASK
>> | XTC_CSR_ENABLE_INT_MASK
>> | XTC_CSR_AUTO_RELOAD_MASK |
>> XTC_CSR_DOWN_COUNT_MASK);
>>
>> }
>> }
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* Re: yaboot 1.3.14 release candidate 1
From: Ben Collins @ 2006-02-10 14:21 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev list
In-Reply-To: <1139538538.3638.14.camel@enki.eridu>
On Thu, 2006-02-09 at 21:28 -0500, Paul Nasrat wrote:
> It's been some time in the making but I'd like to put out what is on
> HEAD for people to test. Key features are improved netbooting on IBM
> pSeries machines (Nathan Lynch), Amiga partition support (Sven Luther),
> Software RAID support on IBM pSeries machines (Dustin Kirkland), plus
> many small fixups. Thanks to all the contributors involved. It should be
> listed in the snapshot section at http://yaboot.ozlabs.org/
Not sure if you have anything like this in your tree at the moment, but
here's a patch we use for Ubuntu. It's based in part on code in silo (I
maintain silo upstream). Since the two are very close in code, this made
sense :). Silo allows you to add an arch in the image stanza like:
image[sun4,sun4m,sun4c]=/boot/foo
image[sun4u]=/boot/foo-64
This basically allows you to do things like this for ppc:
image=/boot/vmlinux-ppc32
name=Linux
...
image[macrisc4]=/boot/vmlinux-ppc64
name=Linux
...
One a powerpc64 (G5 for instance), this will override the default target
of "Linux" with the 64-bit image. The name is checked against the
root /compatible node in the device tree. (e.g. on my powerbook it has
"PowerBook5,9", "MacRISC3", and "Power Macintosh" as possible values).
This seemed a lot better than just doing "32-bit" and "64-bit", since it
also allows for things like:
image[powerbook5,8|powerbook5,9]=/boot/...
and
image[macrisc|macrisc3]=/boot/...
(note, | is the entry separator, so you can have more than one match).
We only use this for 32/64 kernels, but it's really useful for more than
that.
--- yaboot-1.3.13.orig/lib/ctype.c
+++ yaboot-1.3.13/lib/ctype.c
@@ -44,3 +44,11 @@
}
}
+int strncasecmp(const char *cs,const char *ct,size_t n)
+{
+ signed char __res = 0;
+ while (n--)
+ if ((__res = tolower(*cs) - tolower(*ct++)) != 0 || !*cs++)
+ break;
+ return __res;
+}
--- yaboot-1.3.13.orig/second/cfg.c
+++ yaboot-1.3.13/second/cfg.c
@@ -28,6 +28,7 @@
/* Imported functions */
extern int strcasecmp(const char *s1, const char *s2);
+extern int strncasecmp(const char *cs, const char *ct, size_t n);
typedef enum {
cft_strg, cft_flag, cft_end
@@ -101,10 +102,12 @@
static char *endp = NULL;
static char *file_name = NULL;
static CONFIG *curr_table = cf_options;
+static int ignore_entry;
static jmp_buf env;
static struct IMAGES {
CONFIG table[sizeof (cf_image) / sizeof (cf_image[0])];
+ int obsolete;
struct IMAGES *next;
} *images = NULL;
@@ -277,6 +280,16 @@
return 1;
}
+static char *cfg_get_strg_i (CONFIG * table, char *item)
+{
+ CONFIG *walk;
+
+ for (walk = table; walk->type != cft_end; walk++)
+ if (walk->name && !strcasecmp (walk->name, item))
+ return walk->data;
+ return 0;
+}
+
#if 0
// The one and only call to this procedure is commented out
// below, so we don't need this unless we decide to use it again.
@@ -287,13 +300,85 @@
}
#endif
+static int match_arch(const char *name)
+{
+ static prom_handle root;
+ static char model[256], *p;
+
+ if (!root) {
+ if (!(root = prom_finddevice("/")))
+ return 0;
+ }
+
+ if (!model[0]) {
+ if (!prom_getprop(root, "compatible", model, sizeof(model)))
+ return 0;
+ }
+
+ for (p = model; *p; p += strlen(p) + 1) {
+ if (!strcasecmp(p, name))
+ return 1;
+ }
+
+ return 0;
+}
+
+static void check_for_obsolete(const char *label)
+{
+ struct IMAGES *p;
+ char *cur_label;
+
+ /* Make sure our current entry isn't obsolete (ignored) */
+ for (p = images; p; p = p->next) {
+ if (curr_table == p->table && p->obsolete)
+ return;
+ }
+
+ for (p = images; p; p = p->next) {
+ if (curr_table == p->table)
+ continue;
+
+ cur_label = cfg_get_strg_i (p->table, "label");
+ if (!cur_label)
+ cur_label = cfg_get_strg_i (p->table, "image");
+
+ if (!cur_label)
+ continue;
+
+ if (!strcasecmp(cur_label, label))
+ p->obsolete = 1;
+ }
+}
+
static int cfg_set (char *item, char *value)
{
CONFIG *walk;
- if (!strcasecmp (item, "image")) {
+ if (!strncasecmp (item, "image", 5)) {
struct IMAGES **p = &images;
+ int ignore = 0;
+
+ if (item[5] == '[' && item[strlen(item) - 1] == ']') {
+ char *s, *q = item;
+
+ /* Get rid of braces */
+ item[strlen(item) - 1] = 0;
+ item[5] = 0;
+
+ for (s = item + 6; q; s = q) {
+ q = strchr(s, '|');
+ if (q)
+ *q++ = 0;
+
+ if (match_arch(s))
+ goto cfg_set_cont;
+ }
+ /* This just creates an unused table. It will get ignored */
+ ignore = 1;
+ } else if (item[5])
+ goto cfg_set_redo;
+cfg_set_cont:
while (*p)
p = &((*p)->next);
*p = (struct IMAGES *)malloc (sizeof (struct IMAGES));
@@ -302,9 +387,12 @@
return -1;
}
(*p)->next = 0;
+ (*p)->obsolete = ignore;
curr_table = ((*p)->table);
memcpy (curr_table, cf_image, sizeof (cf_image));
}
+
+cfg_set_redo:
for (walk = curr_table; walk->type != cft_end; walk++) {
if (walk->name && !strcasecmp (walk->name, item)) {
if (value && walk->type != cft_strg)
@@ -312,6 +400,8 @@
else if (!value && walk->type == cft_strg)
cfg_warn ("Value expected for '%s'", walk->name);
else {
+ if (!strcasecmp (item, "label"))
+ check_for_obsolete(value);
if (walk->data)
cfg_warn ("Duplicate entry '%s'", walk->name);
if (walk->type == cft_flag)
@@ -322,9 +412,12 @@
break;
}
}
+
if (walk->type != cft_end)
return 1;
-// cfg_return (item, value);
+
+ //cfg_return (item, value);
+
return 0;
}
@@ -369,6 +452,9 @@
if (!image)
return cfg_get_strg_i (cf_options, item);
for (p = images; p; p = p->next) {
+ if (p->obsolete)
+ continue;
+
label = cfg_get_strg_i (p->table, "label");
if (!label) {
label = cfg_get_strg_i (p->table, "image");
@@ -417,6 +503,9 @@
printl_count = 0;
for (p = images; p; p = p->next) {
+ if (p->obsolete)
+ continue;
+
label = cfg_get_strg_i (p->table, "label");
if (!label) {
label = cfg_get_strg_i (p->table, "image");
@@ -439,15 +528,21 @@
char *cfg_get_default (void)
{
char *label;
+ struct IMAGES *p;
char *ret = cfg_get_strg_i (cf_options, "default");
if (ret)
return ret;
if (!images)
return 0;
- ret = cfg_get_strg_i (images->table, "label");
+
+ for (p = images; p && p->obsolete; p = p->next);
+ if (!p)
+ return 0;
+
+ ret = cfg_get_strg_i (p->table, "label");
if (!ret) {
- ret = cfg_get_strg_i (images->table, "image");
+ ret = cfg_get_strg_i (p->table, "image");
label = strrchr (ret, '/');
if (label)
ret = label + 1;
--
Ben Collins
Kernel Developer - Ubuntu Linux
^ permalink raw reply
* [PATCH] poison invalid cpus
From: Olaf Hering @ 2006-02-10 14:00 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
from Anton Blanchard <anton@samba.org>
Novell bug145459
Ensure that per cpu access to !possible cpus causes a fault instead of silent
corruption.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/setup_64.c | 8 ++++++++
1 files changed, 8 insertions(+)
Index: linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-2.6.16-rc1-git3.orig/arch/powerpc/kernel/setup_64.c
+++ linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
@@ -670,6 +670,14 @@ void __init setup_per_cpu_areas(void)
size = PERCPU_ENOUGH_ROOM;
#endif
+ /*
+ * Poison invalid cpus, with lots of high bits set this should
+ * always fault
+ */
+ for (i = 0; i < NR_CPUS; i++) {
+ paca[i].data_offset = 0xeeeeeeeeeeeeeeeeULL;
+ }
+
for_each_cpu(i) {
ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
if (!ptr)
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: HELP! Memory mapping and address space doubts
From: Tore Martin Hagen @ 2006-02-10 13:04 UTC (permalink / raw)
To: "Jose França (Ext_GTBC)"; +Cc: linuxppc-embedded
In-Reply-To: <16FD2D70D281D44F9BFCF6ACF9B6117102AD0EED@lisi053a.siemens.pt>
Hi Vitaly,
It seams that you are mixing virtual addresses and physical addresses.
You must put RAM at physical address 0 and you can keep the flash and
fpga as it is. The 0xc0000000 is the virtual address of the kernel, and
has nothing to do with the physical address.
Where have you mapped the IMMR?
If you have problems with probing of the CFI flash I would try to find
out what the problem realy is. I was given a board with what I would
call SwapEndian, I had to use littleendian for read and bigendian for
writes.
/Tore Martin Hagen
Jose França (Ext_GTBC) wrote:
>Vitaly,
>
> I'm using a linux 2.4.31 kernel. In the present situation I have BRx/ORx well configured and i can boot u-boot normally and without problems. I have a flash eprom with base address 0xD0000000 and a FPGA in 0xE0000000. In linux, i have the mtd driver similar to the rpxlite board. cfi_probe doesn't find my flash eprom. My colleague developped an fpga driver, but he can't access it either... It seem's that all the addresses that we try to access are all mixed-up. In ppc_md.map_io, i'm doing io_block_mapping for the CPM (from 0xf0000000 to the end of memory) , 0x80000000 and 0xa0000000 for PCI address space, both with 256MB of length. We are a bit lost... It seems that we forgot something to do. Can you help me on this?
>
>
>Best regards,
>Filipe.
>
> -----Mensagem original-----
> De: linuxppc-embedded-bounces@ozlabs.org em nome de Vitaly Bordug
> Enviada: sex 27-01-2006 13:37
> Para: Jose França (Ext_GTBC)
> Cc: linuxppc-embedded@ozlabs.org
> Assunto: Re: HELP! Memory mapping and address space doubts
>
>
>
> Jose,
> Can you please be a bit more specific in targets you want to achieve?
>
> An example how to setup br/or and use the device could be found as a part of PQ2 PCI support,
> where interrupt controller is implemented as a CPLD device (arch/ppc/syslib/m82xx_pci.{c,h}).
>
>
> On Thu, 26 Jan 2006 14:04:49 -0000
> Jose França (Ext_GTBC) <Jose.Franca.Ext@siemens.com> wrote:
>
> > Hello u all!
> >
> > I need to clarify some aspects of the memory management in ppc linux and i hope that you could help me.
> > Lets imagine we have a mpc8272 based board with 3 devices A, B and C.In the bootloader (in my case, i use u-boot), i configured the BRx and Orx so that A has base address X, B has base address Y and C has base address Z. My first doubt arrises here: what address should i use? Being SDRAM base address 0x00000000 and kernel base address 0xC0000000, where will i put these devices mapped on? Above 0xC0000000 or in between the end of physical memory and 0xC0000000? Do i really need to configure the BAT registers in u boot?
> > In linux 2.4 kernel, we have ppc_md.setup_io_mappings to map address blocks into the BAT registers... As i observed in the kernel source tree examples, we must map CPM (why?). And what about the other devices A, B and C? How will i setup them in this case and what addresses i can use? Above 0xC0000000 or in between the end of physical memory and 0xC0000000? Is the SDRAM included?
> >
> > Thanks in advance to all contributions! All of them will be most welcomed!
> >
> >
> >
> >
> >
> > Best regards,
> > Filipe
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
>
> --
> Sincerely,
> Vitaly
> _______________________________________________
> 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
>
^ permalink raw reply
* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Russell King @ 2006-02-10 8:44 UTC (permalink / raw)
To: Linux Kernel List, linux-mips, linuxppc-dev, pfg
In-Reply-To: <20060121211407.GA19984@dyn-67.arm.linux.org.uk>
On Sat, Jan 21, 2006 at 09:14:07PM +0000, Russell King wrote:
> The ioc4_serial driver is worse. It assumes that it can set/clear
> ASYNC_CTS_FLOW in the uart_info flags field, which is private to
> serial_core. It also seems to set TTY_IO_ERROR followed by immediately
> clearing it (pointless), and then it writes to tty->alt_speed... which
> isn't used by the serial layer so is also pointless.
Okay, the only remaining part of this patch which hasn't been applied
is this - can anyone ack it?
diff --git a/drivers/serial/ioc4_serial.c b/drivers/serial/ioc4_serial.c
--- a/drivers/serial/ioc4_serial.c
+++ b/drivers/serial/ioc4_serial.c
@@ -1717,11 +1717,9 @@ ioc4_change_speed(struct uart_port *the_
}
if (cflag & CRTSCTS) {
- info->flags |= ASYNC_CTS_FLOW;
port->ip_sscr |= IOC4_SSCR_HFC_EN;
}
else {
- info->flags &= ~ASYNC_CTS_FLOW;
port->ip_sscr &= ~IOC4_SSCR_HFC_EN;
}
writel(port->ip_sscr, &port->ip_serial_regs->sscr);
@@ -1760,18 +1758,6 @@ static inline int ic4_startup_local(stru
info = the_port->info;
- if (info->tty) {
- set_bit(TTY_IO_ERROR, &info->tty->flags);
- clear_bit(TTY_IO_ERROR, &info->tty->flags);
- if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
- info->tty->alt_speed = 57600;
- if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
- info->tty->alt_speed = 115200;
- if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
- info->tty->alt_speed = 230400;
- if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
- info->tty->alt_speed = 460800;
- }
local_open(port);
/* set the speed of the serial port */
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Linux MontaVista Fujitsu CoralP SDL - Please help
From: Wolfgang Denk @ 2006-02-10 8:04 UTC (permalink / raw)
To: White; +Cc: linuxppc-embedded
In-Reply-To: <20060210062813.2feca6cb@White64>
In message <20060210062813.2feca6cb@White64> you wrote:
>
> But last time, i looked at the Denx CoralP Driver, it was only used as
> an big Framebuffer with some Bitblitting Hardware Support.
Deoends on what you are looking at. There is a plain stupid
frambuffer driver, there is an accelerated X11 driver, and an
accelerated driver for QtEmbedded.
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
panic: kernel trap (ignored)
^ permalink raw reply
* YNT: powerCore 6750 nfs mount problem
From: Bora KARTAL @ 2006-02-10 8:03 UTC (permalink / raw)
To: linuxppc-embedded
Hi David,
Unfortunately I am not using u-boot. I think this is not a physical link =
problem. Becouse in the bootup phase it gets the the lsp via ftp correctl=
y. But I thought that this errror is somehow board specific, because when=
=20I tried the same configuration with another target board (Motorolla MV=
ME5100) it successfully mount to the root file system. =20
________________________________
Kimden: linuxppc-embedded-bounces@ozlabs.org bu ki=FEinin yerine: Hunter,=
=20David
G=F6nderilmi=FE: Per 09.02.2006 16:44
Kime: linuxppc-embedded@ozlabs.org
Konu: RE: powerCore 6750 nfs mount problem
Bora,
> NETDEV WATCHDOG: eth0: transmit timed out
This usually means the Ethernet driver's transmitter is stuck. Did it
initialize correctly? Did the PHY go link up?
How does network behave in your bootloader? (Hopefully you're using
U-Boot. :)
-Dave
-----Original Message-----
Date: Wed, 8 Feb 2006 11:15:41 +0200
From: "Bora KARTAL" <bkartal@aselsan.com.tr>
Subject: powerCore 6750 nfs mount problem
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
=20 =20
<C379193B17749F4BA82ABF87E7DCB6A62CF0D0@papatyaint.aselsan.com.tr>
Content-Type: text/plain; charset=3D"ISO-8859-9"
Hi,
I am trying to run linuxppc 2.4.20 with a nfs mounted root file system
on a Force powerCore 6750 board with the following command-line options:
CONFIG_CMDLINE=3D"root=3D/dev/nfs
nfsroot=3D15.20.11.58:/root/Linux/MontaVista/opt/montavista/pro/devkit/pp=
c
/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
client on my target board.
My problem is:
The target can not mount to my server Linux machine and gives the
following 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.
Anybody can help?
Thanks,
Bora
DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or o=
therwise protected from disclosure. If you are not an intended recipient =
of this e-mail, do not duplicate or redistribute it by any means. Please =
delete it and any attachments and notify the sender that you have receive=
d it in error. Unintended recipients are prohibited from taking action on=
=20the basis of information in this e-mail.E-mail messages may contain co=
mputer viruses or other defects, may not be accurately replicated on othe=
r systems, or may be intercepted, deleted or interfered with without the =
knowledge of the sender or the intended recipient. If you are not comfort=
able with the risks associated with e-mail messages, you may decide not t=
o use e-mail to communicate with IPC. IPC reserves the right, to the exte=
nt and under circumstances permitted by applicable law, to retain, monito=
r and intercept e-mail messages to and from its systems.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
######################################################################
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: Yosemite/440EP 'issues' as a PCI target
From: Stefan Roese @ 2006-02-10 7:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43EBD715.4020303@ovro.caltech.edu>
Hi David,
On Friday 10 February 2006 00:58, David Hawkins wrote:
> Now what if the host wants to interrupt the 440EP.
> Errr, there is no register defined for this purpose.
> The UIC chapter, p220-222 v1.18 manual indicates
> all the interrupt bits. Sure there are a couple of
> PCI source interrupts, one for writes to the PCI
> configuration-space command register (so can't really
> use that),
You could use it but I wouldn't recommend it.
> and another for power-management events.
>
> Have I missed something?
No. This sounds pretty much like the 405GP(r) which also lacks this
host-to-target interrupt facility.
> I'll have an FPGA/CPLD on the external bus, so I guess
> I can implement a mailbox/doorbell register in that
> and then have that register trigger an external interrupt
> on the 440EP. The 440EP PCI target BARs will then need
> to be setup to decode to the EBC decode range.
> Sounds like a hack ... (even more of a hack is to
> loop back a GPIO onto an EXTINT and setup the target
> decode to cover the GPIO registers, and the x86 can
> toggle a GPIO directly).
Yes, those are the choices available. If the CPU doesn't offer such features
directly, I wouldn't even call those solutions a "hack". ;-)
> Of course if I have a few unused peripherals I might
> be able to cause them to generate an interrupt. But
> that gets tricky since in a lot of cases, as device
> interrupts are often controlled via DCRs.
I wouldn't go this way.
Best regards,
Stefan
^ permalink raw reply
* Re: Getting started with Xilinx V4 PPC?
From: Paula Saameño @ 2006-02-10 7:47 UTC (permalink / raw)
To: linuxppc-embedded, bennett78
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
Hi!!
I am using ML403 right now and everything works fine with the
linuxppc_2_4_devel. My basic design has a simple UART, DDR, Ethernet, IIC
and XSysAce.
I haven't measured the power consumption yet, but I will soon. I'll let you
know when I do it.
I thought about using the internal FPGA MAC as a complete PHY. For Ethernet
over fiber it's ok, but for Ethernet over copper, we should implement the
collision detector, serder... "manually" and I don't think we had enough
space in the FPGA (XC4VFX12), since the actual design uses the 85% of
slices.
Maybe with a bigger FPGA we could do the complete design "inside".
Have a good weekend!
Paula
[-- Attachment #2: Type: text/html, Size: 735 bytes --]
^ permalink raw reply
* Re: Linux MontaVista Fujitsu CoralP SDL - Please help
From: White @ 2006-02-10 5:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060210011750.85501352564@atlas.denx.de>
The ALT Software Company provides additional Support (not cheap) ,
Driver and so on, for Coral P / Coral PA and the Rest of this Family.
The Coral P is a very tricky G-Processor. If you found the Bugs it has,
you can get much Power out of it.
But last time, i looked at the Denx CoralP Driver, it was only used as
an big Framebuffer with some Bitblitting Hardware Support.
Is this always correct? Please correct me if i'm wrong.
Am Fri, 10 Feb 2006 02:17:50 +0100 schrieb Wolfgang Denk <wd@denx.de> :
> In message <4ed3a66fe66b3d155bd7e98500c463a9@embeddedalley.com> you wrote:
> >
> > Well, I think Wolfgang Denk gets all of the credit for originally
> > writing the software. ...
>
> Not me personally. It was the excellent engineers in our team...
>
> 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
> Only a fool fights in a burning house.
> -- Kank the Klingon, "Day of the Dove", stardate unknown
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Getting started with Xilinx V4 PPC?
From: Frank Bennett @ 2006-02-10 2:13 UTC (permalink / raw)
To: David Summers; +Cc: David H. Lynch Jr., linuxppc-embedded
In-Reply-To: <e4619cf30601311317j10900b5dvf953011f97ae0c50@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 10775 bytes --]
David Summers wrote:
> Thanks for all of the great advice.
>
>
> I think my plan is to stick with the 2.4 kernel for now until I run
> into a compelling reason to switch to 2.6. It sounds like the 2.6
> support is getting very close to maturity and if I get some free time
> I would love to pitch in and help.
>
>
> Is anyone out there using JFFS2 on a NAND flash device in 2.4? If
> this works in 2.4 then I should be OK. My dev board only has 4MB of
> NOR flash so this is one part of the processor subsystem that I cannot
> test.
>
Per my previous response: I had some trouble with MTD/JFFS2 until I
picked up to the DENX cvs
version of linuxppc_2_4_devel (just the MTD part) which added a few
additional flash parts and is
working well for me under 2.4.25 (on Lite5200, MPC5200)
What about the following dev brd? Anybody porting here?
http://www.nuhorizons.com/products/xilinx/v4/ml403/index.html
for $100 or so more? Looks like it might have NAND flash.
Anybody got a power measurement for a configured ML403 dev board running
PPC/Linux, flash, DDR, Ethernet,etc?
Also why not put the extternal PHY controller (Serdes, collision detect,
5b4, etc) on the FPGA?
Should then only need external magnetics & a RJ45
-Frank Bennett
> -David Summers
>
>
> On 1/31/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>> David;
>>
>> I just completed a port of 2.6 to the Pico E-12 which is a Xilinx
>> Virtex-4 with very little hardware.
>>
>> I had the advantage of a system that already had a elf loader (not
>> U-Boot), but not a Linux loader.
>> If I could load Linux as an elf file then I did not need another loader.
>> In the end I had to make some very trivial modifications to Pico's
>> loader to pass a board information structure. But otherwise the decision
>> to use the existing loader saved me having to port u-boot.
>>
>> I also chose to boot into a ramdisk. Using the existing loader precluded
>> having the ramdisk as a separate file.
>> the intramfs feature of 2.6 allowed me to wrap the ramdisk into the same
>> file as the kernel. Documentation on initramfs is spartan, and somewhat
>> opaque. The good news was that despite the documentation initramfs
>> proved trivially easy to use.
>>
>> After that I took the 2.6 kernel source, and litterally went through
>> looking for all references to the xilinx ml300.
>> Wherever there was an ml300 specific file I created an new one for the
>> pico_e12. Wherever there was an ml300 configuration option I created a
>> PICO_E12 one.
>>
>> The E-12 had substatnitially less hardware than the ml300 (or the ml403)
>> so mostly I just ended up ripping code out of my private version of the
>> ml300 code that was transmuting into the pico_e12 code.
>>
>> The next obstacle I bumped into was that the e-12 had two devices
>> suitable for a console - a highspeed fifo interface to a host
>> development system called the keyhole port, and the xilinx uartlite
>> serial port. Neither are supported in 2.6. I looked at the Xilinx
>> Uartlite 2.4 driver and it was coded substantially different from other
>> serial drivers. I decided not to try to port it to 2.6. I started from
>> scratch using the 8250 code as a base. I picked the 8250 because:
>> It must be the most heavily used linux serial driver and therefore I
>> hoped the most uptodate and well debugged.
>> The 8250 had boot through console IO support. Most other serial devices
>> require getting fairly far into the boot process before you get any output.
>>
>> The really early IO proved fairly simple. Implimenting xxxx_dbg.c and
>> xxxx_tty.c for both the uartlite and the keyhole was fairly trivial.
>>
>> Additionally the keyhole port had a "debug" feature where if you output
>> a single 32 bit word to one of the fifo ports it would be displayed in
>> hex on the host. As this could be done in an assembler macro that proved
>> indispensiable early on.
>>
>> I was stalled for about 3 weeks trying to get the sucker into virtual
>> mode. In the end I had to disable Machine Check exceptions to make the
>> transition to virtual mode. Pico claims there is not a hardware problem,
>> but if I do nto disable machine checks on the e-12 it will never make
>> the tansition to virtual mode.
>>
>> The full serial driver for the Uartlite (and Keyhole) proved more
>> daunting than anything else. In some ways the 8250 proved a bad choice
>> as a template there as there are more permutations, busses, etc
>> associated with the 8250 than anything else. I ended up stripping out
>> huge hunks of code. Eventually, I used the m32r_sio as a simpler
>> template. The driver was much simpler, and it had the critical features
>> I needed - both interupt driven and polled IO support - some
>> implimentations of the E12 do not include a PIC. The serial drivers took
>> much longer than the whole rest of the port combined - including the
>> machine check detour.
>>
>> Just as I was finishing up the E12 port, Grant posted a set of patches
>> for the ml403. There were some fundimental differences at a fairly low
>> level between Grant's approach and mine. And I think Grant's Virtex-4
>> code appears to reflect more of the direction things are going, so I am
>> in the process of remodeling my port for the E12 on his for the ml403.
>> But I have not completed that.
>>
>> Absent the machine check issue and having to write serial drivers thus
>> was atmost 2 weeks work.
>>
>>
>> BTW while you appear to be a hardware guy with alot of software
>> experience, I am a software guy with alot of hardware experience.
>>
>>
>> The E-12 has flash, but it uses a proprietary flash file system, and
>> using it would have required writing a filesystem driver - which I would
>> be happy to do if I got paid for it. Write performance on flash can be
>> extremely slow. If you are recording a significant amount of data in
>> realtime, you may want to skip the flash and just use a ramdisk. However
>> the ramdisk will not survive the system loosing power - which might be
>> an issue in a rocket.
>>
>> If you are going to start with the 2.6 Kernel, I would get git. use it
>> to DL Linus's current 2.6 git repository, adn apply all of Grant's ml403
>> patches from the mailing list to it.
>> Then I would start an approach somewhat similar to what I described
>> above - except using Grant's ml403 as the base to create your own board
>> spec from instead of the ml300 that I used.
>> How tightly constrained are you for gates in the FPGA ?
>> If you are not tight, use the Xilinx 16550 serial IP and then you can
>> use standard Kernel 8250 dirvers (making Grant's patches work with
>> Uartlite is one of the things I am having trouble with) It would be my
>> guess that if you use the 16550 serial IP, you may be able to use
>> Grant's ml403 stuff asis.
>>
>>
>>
>>
>>
>> David Summers wrote:
>>
>>
>>> I am starting a new project where I need to have a flash file system
>>> and an ethenet interface (HTTP and FTP). The project is a solar
>>> physics experiment that will be launched on a sub-orbital rocket
>>> flight this fall. The idea is that the experiment will write data
>>> files to the flash file system while in flight, and then I can
>>> download the data using ethernet after the experiment returns to
>>> earth.
>>>
>>> I think that Linux is the way to go for this project because of the
>>> JFFS2 filesystem and the strong networking support. The only problem
>>> is that I am totally new to embedded linux.
>>>
>>> I am prototyping my system on an Avnet FX12 development board ( Specs
>>> here: http://tinyurl.com/4gfdv ) which is pretty similar to the Xilinx
>>> ML403 board except with less memory and no SystemACE slot.
>>>
>>> I will eventually build my own custom board with the same Xilinx
>>> Virtex 4 FX12 FPGA and additional flash memory and some custom
>>> interface hardware. My background is primarily as a hardware designer,
>>> and I am very confortable with the FPGA part of this project. I am
>>> comfortable as a Linux user, and I am a pretty good C coder (for a
>>> hardware guy anyway :). I have never built a linux system (embedded
>>> or desktop) before, and I need some help getting started with embedded
>>> linux.
>>>
>>> I have already found the following websites which have been a big help so far:
>>>
>>> http://www.klingauf.de/v2p/index.phtml
>>> http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm
>>> http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html#toc1
>>>
>>> I have a few questions that I hope someone can help me with:
>>>
>>> 1. What is the best linux distribution to start out with? I am
>>> currently working with the 2.4 kernel code from
>>> ppc.bkbits.net/linuxppc_2_4_devel, but I'm not sure that this version
>>> be being updated. (MontaVista also seems to be making it rather
>>> difficult to download their free Linux Preview Kit, so I wouldn't mind
>>> finding another distribution) Does the DENX distribution have good
>>> PPC support? Are there any others that I should look at, or should I
>>> just download the kernel source directly from kernel.org?
>>>
>>>
>>> 2. kernel 2.4 or 2.6?
>>>
>>> It is my understanding that the latest version of MTD and JFFS2 have
>>> dropped support for kernel 2.4. I would like to use JFFS2 on a NAND
>>> flash device, so it seems like I should use 2.6. (Can I use JFFS2 on
>>> a NAND device with kernel v 2.4?)
>>>
>>> Being a complete newbie, am I biting off more that I can handle by
>>> trying to use 2.6?
>>>
>>> I have been lurking on the mailing list for a while, and I know that
>>> there are several people working on 2.6.x patches for the Xilinx
>>> virtex 4 parts. Could someone point me to a list of the patches that
>>> I need to get me started? I think that the ML403 patches should work
>>> with my board, but I don't know which ones I need to download.
>>>
>>>
>>> Thank you for your help,
>>>
>>> David Summers
>>> University of Colorado
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>>
>>>
>> --
>> Dave Lynch DLA Systems
>> Software Development: Embedded Linux
>> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net:8888
>>
>>
>>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
*/Frank Bennett
CEO/*
Mathegraphics,LLC
613 Bentley Pl
Fort Collins,CO 80526
970-229-9269 (hm) 970-402-9269 (cell)
www.mathegraphics.com <http://www.mathegraphics.com>
bennett78@digis.net <mailto:bennett78@digis.net>
[-- Attachment #2: Type: text/html, Size: 12279 bytes --]
^ permalink raw reply
* yaboot 1.3.14 release candidate 1
From: Paul Nasrat @ 2006-02-10 2:28 UTC (permalink / raw)
To: linuxppc-dev list
It's been some time in the making but I'd like to put out what is on
HEAD for people to test. Key features are improved netbooting on IBM
pSeries machines (Nathan Lynch), Amiga partition support (Sven Luther),
Software RAID support on IBM pSeries machines (Dustin Kirkland), plus
many small fixups. Thanks to all the contributors involved. It should be
listed in the snapshot section at http://yaboot.ozlabs.org/
c955afa8188dcb927db09cb30e82cef0c00dbedb yaboot-1.3.14rc1.tar.gz
Most of the stuff is already in a variety of distributions, but I'd
invite wider testing.
Thanks to ozlabs for putting up the hosting at short notice when
penguinppc.org had hardware issues.
Paul
^ permalink raw reply
* Re: Linux MontaVista Fujitsu CoralP SDL - Please help
From: Wolfgang Denk @ 2006-02-10 1:17 UTC (permalink / raw)
To: Dan Malek; +Cc: kumar.gala, linuxppc-embedded, Eli Orr, alebas
In-Reply-To: <4ed3a66fe66b3d155bd7e98500c463a9@embeddedalley.com>
In message <4ed3a66fe66b3d155bd7e98500c463a9@embeddedalley.com> you wrote:
>
> Well, I think Wolfgang Denk gets all of the credit for originally
> writing the software. ...
Not me personally. It was the excellent engineers in our team...
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
Only a fool fights in a burning house.
-- Kank the Klingon, "Day of the Dove", stardate unknown
^ permalink raw reply
* Re: Linux MontaVista Fujitsu CoralP SDL - Please help
From: Dan Malek @ 2006-02-10 0:24 UTC (permalink / raw)
To: Eli Orr; +Cc: kumar.gala, alebas, linuxppc-embedded
In-Reply-To: <0IUF0040OPKQ6PK0@i_mtaout2.012.net.il>
On Feb 9, 2006, at 2:15 PM, Eli Orr wrote:
> I was goggling around and found you listed as people who somehow=20
> related to Fujitsu CoralP.
Well, I think Wolfgang Denk gets all of the credit for originally
writing the software. I've used it to enable the STx GT3D CoralP
board on the MEN5200 board with various Linux kernel
distributions.
> I need help to find a source code /=A0 object for:
> Fujitsu CoralP SDL for Linux MontaVista 3.1 Kernel 2.6.x
There are a few of us here in the business of providing
such services :-) Somehow MontaVista 3.1 and
Linux 2.6 don't seem like a match. Have you asked them?
Thanks.
-- Dan
^ permalink raw reply
* Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-09 23:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060209003459.0ED30352564@atlas.denx.de>
Hi all,
I'm evaluating the 440EP for use as the control processor
on a PCI peripheral. Today I have been looking at what I
can use for processor-to-processor communications over
the PCI bus. The boards will be used in existing
equipment that does not have ethernet in the backplane.
It appears that the 440EP has very limited options for
interrupt-based communications over the PCI bus.
Lets assume the following basic host-to-host protocol
(interrupt-based handshake).
1) PCI system slot machine 'host' has all the IRQs routed
to it. This will be an x86-based machine.
The host interrupts the device when it wants to
send it data, or when it wants to send an acknowledge.
2) PCI device slot; a 440EP based board.
The device interrupts the host when it wants
to send it data, or when it wants to send an
acknowledge.
If the 440EP board wants to interrupt the host, it can
generate an interrupt by writing to the PCI Interrupt
Control/Status Register, PCIC0_ICS, with only 1 bit
available for interrupt generation (i.e., there is
no concept of a mailbox or doorbell register, just a bit)
(see p388 of the v1.18 manual).
Now what if the host wants to interrupt the 440EP.
Errr, there is no register defined for this purpose.
The UIC chapter, p220-222 v1.18 manual indicates
all the interrupt bits. Sure there are a couple of
PCI source interrupts, one for writes to the PCI
configuration-space command register (so can't really
use that), and another for power-management events.
Have I missed something?
I'll have an FPGA/CPLD on the external bus, so I guess
I can implement a mailbox/doorbell register in that
and then have that register trigger an external interrupt
on the 440EP. The 440EP PCI target BARs will then need
to be setup to decode to the EBC decode range.
Sounds like a hack ... (even more of a hack is to
loop back a GPIO onto an EXTINT and setup the target
decode to cover the GPIO registers, and the x86 can
toggle a GPIO directly).
Of course if I have a few unused peripherals I might
be able to cause them to generate an interrupt. But
that gets tricky since in a lot of cases, as device
interrupts are often controlled via DCRs.
I realize that some of the other devices have I2O messaging
units (440GX and 440SP), so are more suited to PCI comms
applications. However, I require the hardware FPU on
the 440EP. From the selector guide, its only the 440EP
and 440EPx that contain the FPU.
Any comments on this?
Dave
^ permalink raw reply
* Linux MontaVista Fujitsu CoralP SDL - Please help
From: Eli Orr @ 2006-02-09 19:15 UTC (permalink / raw)
To: alebas, markc, afleming, kumar.gala, robin.gilks, ebs, mporter,
linuxppc-embedded, bora.sahin, mgreer, jjboor
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
Dear Experts,
I was goggling around and found you listed as people who somehow related to
Fujitsu CoralP.
I need help to find a source code / object for:
Fujitsu CoralP SDL for Linux MontaVista 3.1 Kernel 2.6.x
Best Regards,
Eli Orr
Mobile : +972 54 737 9604
<mailto:EliOrr@Albatronics.com> EliOrr@Albatronics.com
Your Developments Partner
<http://www.albatronics.com/> www.Albatronics.com
[-- Attachment #2: Type: text/html, Size: 5474 bytes --]
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-02-09 14:51 UTC (permalink / raw)
To: S. Egbert; +Cc: linuxppc-embedded
In-Reply-To: <43EAF5EC.7050204@sbcglobal.net>
On 9-Feb-06, at 12:57 AM, S. Egbert wrote:
>>> 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://?
The patches have now been accepted into paul's powerpt.git tree.
http://www.kernel.org/git/?p=linux/kernel/git/paulus/
powerpc.git;a=summary
^ permalink raw reply
* Re: asm-powerpc/highmem.h missing
From: Olaf Hering @ 2006-02-09 14:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <335AACC0-4227-4D0F-9B4B-2B89F1368ECB@kernel.crashing.org>
On Wed, Feb 08, Kumar Gala wrote:
> You do realize there are a slew of headers in include/asm-ppc/ that
> we use in the arch/powerpc builds for ppc32.
Yes, I just realized that I have to patch both asm/io.h files. ARGH!
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* RE: powerCore 6750 nfs mount problem
From: Hunter, David @ 2006-02-09 14:44 UTC (permalink / raw)
To: linuxppc-embedded
Bora,
> NETDEV WATCHDOG: eth0: transmit timed out=20
This usually means the Ethernet driver's transmitter is stuck. Did it
initialize correctly? Did the PHY go link up?
How does network behave in your bootloader? (Hopefully you're using
U-Boot. :)
-Dave
-----Original Message-----
Date: Wed, 8 Feb 2006 11:15:41 +0200
From: "Bora KARTAL" <bkartal@aselsan.com.tr>
Subject: powerCore 6750 nfs mount problem
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
=09
<C379193B17749F4BA82ABF87E7DCB6A62CF0D0@papatyaint.aselsan.com.tr>
Content-Type: text/plain; charset=3D"ISO-8859-9"
Hi,
I am trying to run linuxppc 2.4.20 with a nfs mounted root file system
on a Force powerCore 6750 board with the following command-line options:
CONFIG_CMDLINE=3D"root=3D/dev/nfs
nfsroot=3D15.20.11.58:/root/Linux/MontaVista/opt/montavista/pro/devkit/pp=
c
/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
client on my target board.
My problem is:
The target can not mount to my server Linux machine and gives the
following 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.
Anybody can help?=20
Thanks,
Bora
DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or =
otherwise protected from disclosure. If you are not an intended =
recipient of this e-mail, do not duplicate or redistribute it by any =
means. Please delete it and any attachments and notify the sender that =
you have received it in error. Unintended recipients are prohibited from =
taking action on the basis of information in this e-mail.E-mail messages =
may contain computer viruses or other defects, may not be accurately =
replicated on other systems, or may be intercepted, deleted or =
interfered with without the knowledge of the sender or the intended =
recipient. If you are not comfortable with the risks associated with =
e-mail messages, you may decide not to use e-mail to communicate with =
IPC. IPC reserves the right, to the extent and under circumstances =
permitted by applicable law, to retain, monitor and intercept e-mail =
messages to and from its systems.
^ permalink raw reply
* 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
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