* Re: SMP on MV64460
From: Mark A. Greer @ 2005-12-16 22:26 UTC (permalink / raw)
To: Lance Ware; +Cc: linuxppc-embedded
In-Reply-To: <000601c6028c$85eaea80$2d01a8c0@jalexander>
Hi Lance,
On Fri, Dec 16, 2005 at 05:03:14PM -0500, Lance Ware wrote:
>
> Hello group,
>
> I am currently working on a board which has MV64460 linked between
> two 7447a processors. I wanted to know if someone has been able to get
> the Linux 2.6 kernel working with any MV64xxx bridge.
I think there are people out there that have made this work. However, I
haven't b/c I do not have access to any SMP hardware that has all of the
necessary h/w errata implemented.
Perhaps others that have hardware will speak up?
Mark
^ permalink raw reply
* [PATCH] ppc: ppc4xx_dma DMA_MODE_{READ,WRITE} fix
From: Al Viro @ 2005-12-16 22:35 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
DMA_MODE_{READ,WRITE} are declared in asm-powerpc/dma.h and their
declarations there match the definitions. Old declarations in
ppc4xx_dma.h are not right anymore (wrong type, to start with).
Killed them, added include of asm/dma.h where needed.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/ppc/syslib/ppc4xx_dma.c | 1 +
include/asm-ppc/ppc4xx_dma.h | 3 ---
2 files changed, 1 insertions(+), 3 deletions(-)
fc830a6f62230c04590f711798ea8de44e567439
diff --git a/arch/ppc/syslib/ppc4xx_dma.c b/arch/ppc/syslib/ppc4xx_dma.c
index f15e642..05ccd59 100644
--- a/arch/ppc/syslib/ppc4xx_dma.c
+++ b/arch/ppc/syslib/ppc4xx_dma.c
@@ -30,6 +30,7 @@
#include <asm/system.h>
#include <asm/io.h>
+#include <asm/dma.h>
#include <asm/ppc4xx_dma.h>
ppc_dma_ch_t dma_channels[MAX_PPC4xx_DMA_CHANNELS];
diff --git a/include/asm-ppc/ppc4xx_dma.h b/include/asm-ppc/ppc4xx_dma.h
index a415001..46a086f 100644
--- a/include/asm-ppc/ppc4xx_dma.h
+++ b/include/asm-ppc/ppc4xx_dma.h
@@ -33,9 +33,6 @@
#define MAX_PPC4xx_DMA_CHANNELS 4
-/* in arch/ppc/kernel/setup.c -- Cort */
-extern unsigned long DMA_MODE_WRITE, DMA_MODE_READ;
-
/*
* Function return status codes
* These values are used to indicate whether or not the function
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] ppc: booke_wdt compile fix
From: Al Viro @ 2005-12-16 22:35 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
booke_wdt.c had been missed in cpu_specs[] removal sweep
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
drivers/char/watchdog/booke_wdt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
c845a90e7ff367deb10a66dbf37c3709b8d76325
diff --git a/drivers/char/watchdog/booke_wdt.c b/drivers/char/watchdog/booke_wdt.c
index c800cce..b664060 100644
--- a/drivers/char/watchdog/booke_wdt.c
+++ b/drivers/char/watchdog/booke_wdt.c
@@ -173,7 +173,7 @@ static int __init booke_wdt_init(void)
int ret = 0;
printk (KERN_INFO "PowerPC Book-E Watchdog Timer Loaded\n");
- ident.firmware_version = cpu_specs[0].pvr_value;
+ ident.firmware_version = cur_cpu_spec->pvr_value;
ret = misc_register(&booke_wdt_miscdev);
if (ret) {
--
0.99.9.GIT
^ permalink raw reply related
* POSIX High Resolution Timers in LinuxPPC 2.4
From: Martin, Tim @ 2005-12-16 22:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 531 bytes --]
Could someone give me a brief history lesson on POSIX high resolution timers
(e.g. timer_create() function) implemented in the Linux kernel on the
PowerPC 405 architecture? Specifically:
Confirm they are in the mainline 2.6 kernel now (e.g. kernel.org)?
Were they ever a part of the "mainline" 2.4 linuxppc kernel (e.g
ppc.bkbits.net)?
If no, were they ever available as a patch? The stuff at
sourceforge.net/projects/high-res-timers stops at 2.4.20 and looks like it
was only ever working for i386, not ppc.
Tim
[-- Attachment #2: Type: text/html, Size: 2665 bytes --]
^ permalink raw reply
* Re: Required functions for relocating not part of relocate section
From: Tom Rini @ 2005-12-16 23:04 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20051104180605.GA3271@logos.cnet>
On Fri, Nov 04, 2005 at 04:06:05PM -0200, Marcelo Tosatti wrote:
> Hi Paul,
>
> Recent 2.6-git (from Wednesday) tree fails to boot on 8xx due to:
>
> BDI>i
> Target state : debug mode
> Debug entry cause : trace
> Current PC : 0x005ba8e8
> BDI>md 0x005ba8e8
> 005ba8e8 : 00000000 00000000 00000000 00000000 ................
> 005ba8f8 : 00000000 00000000 00000000 00000000 ................
> 005ba908 : 00000000 00000000 00000000 00000000 ................
> 005ba918 : 00000000 00000000 00000000 00000000 ................
> 005ba928 : 00000000 00000000 00000000 00000000 ................
> ...
> BDI>go
> - TARGET: stopped
> BDI>i
> Target state : debug mode
> Debug entry cause : software emulation exception
> Current PC : 0x005ba8e8
>
> Problem is that flush_instruction_cache (and flush_data_cache)
> from boot/common/util.S are not being copied to the relocate section,
> even though the file contains the proper entry:
So while I don't know why, someone else noted this problem to me
recently, as hit on I believe the Walnut (405GP Eval), saying that
flush_instruction_cache worked prior to relocation, but failed
afterwards. And if the function was put into the .data section, all was
well (_GLOBAL changed meaning 'recently' which changed this behavior).
No solution, but hopefully more hints..
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Typo in arch/ppc/kernel/head.S?
From: Benjamin Herrenschmidt @ 2005-12-17 0:43 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: linuxppc-dev
In-Reply-To: <61AB94A8-8912-4699-A32A-70AC1155BA34@dataarmor.net>
On Fri, 2005-12-16 at 01:35 -0600, Andrei Warkentin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hello,
>
> I was looking at head.S under arch/ppc/kernel and it seems the
> comment above ".globl __start" is slightly off. Under
> the PMAC section it mentions that .text/.data/.bss are loaded @ 0x0,
> while they could be pretty much loaded anywhere but 0x0, with OF
> exception vectors being there. Am I understanding this correctly?
The comment is pre-historical :) The zImage used to put the kernel at 0
and BootX puts it there too, but the former has been changed. The kernel
can indeed be loaded pretty much anywhere.
Ben.
^ permalink raw reply
* Re: Powermac real-mode? setting?
From: Benjamin Herrenschmidt @ 2005-12-17 0:45 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: linuxppc-dev
In-Reply-To: <E6B18F88-0CD3-4832-8BB6-232580280009@gmail.com>
On Fri, 2005-12-16 at 02:53 -0600, Andrei Warkentin wrote:
> Hello,
>
> As far as I understand, linux expects to be started in virt-mode,
> with MMU on.
No, Linux doesn't care. All it expects is that if MMU is on, it will be
started with a 1:1 mapping. In fact, pSeries (and CHRP) generally boot
in real mode, as does BootX.
> Does anyone know if setting real-mode? to true will work correctly? I'm
> trying to get something in the way of a home-brew
> kernel going on an G4 OF 3.0-based machine, and was wondering if it
> was possible to start out with the MMU off.
I doubt Apple's OF 3.0 will boot at all in real mode :) It's not a
kernel problem per-se, it's Apple's OF who tend to really only work in
virtual mode nowadays.
There should be no problem however switching MMU off from within your
"home brew" kernel. Look at how the linux kernel does in head.S
> Thank you very much and have a nice day.
>
> Andrei Warkentin
> andrey.warkentin@gmail.com
> Cell: (+1) (847) 321-15-55
> Office: (+1) (312) 756-15-00 x614
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2.6 2/2] usb/input: Add Geyser 2 support to appletouch driver
From: Michael Hanselmann @ 2005-12-17 1:19 UTC (permalink / raw)
To: linux-kernel; +Cc: kernel-stuff, linuxppc-dev, linux-input
In-Reply-To: <20051213224019.GC20017@hansmi.ch>
This patch adds support for the Geyser 2 touchpads used on post Oct 2005
Apple PowerBooks to the appletouch driver.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Stelian Pop <stelian@popies.net>
---
Rediffed without relayfs and made loops out of the manually unrolled
assignment code.
diff -rup linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt b/Documentation/input/appletouch.txt
--- linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt 2005-12-13 00:09:24.000000000 +0100
+++ b/Documentation/input/appletouch.txt 2005-12-17 02:06:27.000000000 +0100
@@ -3,7 +3,7 @@ Apple Touchpad Driver (appletouch)
Copyright (C) 2005 Stelian Pop <stelian@popies.net>
appletouch is a Linux kernel driver for the USB touchpad found on post
-February 2005 Apple Alu Powerbooks.
+February 2005 and October 2005 Apple Aluminium Powerbooks.
This driver is derived from Johannes Berg's appletrackpad driver[1], but it has
been improved in some areas:
@@ -13,7 +13,8 @@ been improved in some areas:
Credits go to Johannes Berg for reverse-engineering the touchpad protocol,
Frank Arnold for further improvements, and Alex Harper for some additional
-information about the inner workings of the touchpad sensors.
+information about the inner workings of the touchpad sensors. Michael
+Hanselmann added support for the October 2005 models.
Usage:
------
diff -rup linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c b/drivers/usb/input/appletouch.c
--- linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c 2005-12-13 22:44:24.000000000 +0100
+++ b/drivers/usb/input/appletouch.c 2005-12-17 02:13:02.000000000 +0100
@@ -6,6 +6,7 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
@@ -38,6 +39,11 @@
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
+/* These names come from Info.plist in AppleUSBTrackpad.kext */
+#define GEYSER_ANSI_PRODUCT_ID 0x0214
+#define GEYSER_ISO_PRODUCT_ID 0x0215
+#define GEYSER_JIS_PRODUCT_ID 0x0216
+
#define ATP_DEVICE(prod) \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
USB_DEVICE_ID_MATCH_INT_CLASS | \
@@ -53,13 +59,17 @@ static struct usb_device_id atp_table []
{ ATP_DEVICE(0x020F) },
{ ATP_DEVICE(0x030A) },
{ ATP_DEVICE(0x030B) },
- { } /* Terminating entry */
+
+ /* PowerBooks Oct 2005 */
+ { ATP_DEVICE(GEYSER_ANSI_PRODUCT_ID) },
+ { ATP_DEVICE(GEYSER_ISO_PRODUCT_ID) },
+ { ATP_DEVICE(GEYSER_JIS_PRODUCT_ID) },
+
+ /* Terminating entry */
+ { }
};
MODULE_DEVICE_TABLE (usb, atp_table);
-/* size of a USB urb transfer */
-#define ATP_DATASIZE 81
-
/*
* number of sensors. Note that only 16 instead of 26 X (horizontal)
* sensors exist on 12" and 15" PowerBooks. All models have 16 Y
@@ -108,6 +118,8 @@ struct atp {
signed char xy_old[ATP_XSENSORS + ATP_YSENSORS];
/* accumulated sensors */
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
+ int overflowwarn; /* overflow warning printed? */
+ int datalen; /* size of an USB urb transfer */
};
#define dbg_dump(msg, tab) \
@@ -124,7 +136,7 @@ struct atp {
if (debug) printk(format, ##a); \
} while (0)
-MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
+MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Michael Hanselmann");
MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
MODULE_LICENSE("GPL");
@@ -132,6 +144,16 @@ static int debug = 1;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+/* Checks if the device a Geyser 2 (ANSI, ISO, JIS) */
+static inline int atp_is_geyser_2(struct atp *dev)
+{
+ int16_t productId = le16_to_cpu(dev->udev->descriptor.idProduct);
+
+ return (productId == GEYSER_ANSI_PRODUCT_ID) ||
+ (productId == GEYSER_ISO_PRODUCT_ID) ||
+ (productId == GEYSER_JIS_PRODUCT_ID);
+}
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -168,13 +190,20 @@ static inline void atp_report_fingers(st
static void atp_complete(struct urb* urb, struct pt_regs* regs)
{
int x, y, x_z, y_z, x_f, y_f;
- int retval, i;
+ int retval, i, j;
struct atp *dev = urb->context;
switch (urb->status) {
case 0:
/* success */
break;
+ case -EOVERFLOW:
+ if(!dev->overflowwarn) {
+ printk("appletouch: OVERFLOW with data "
+ "length %d, actual length is %d\n",
+ dev->datalen, dev->urb->actual_length);
+ dev->overflowwarn = 1;
+ }
case -ECONNRESET:
case -ENOENT:
case -ESHUTDOWN:
@@ -189,23 +218,45 @@ static void atp_complete(struct urb* urb
}
/* drop incomplete datasets */
- if (dev->urb->actual_length != ATP_DATASIZE) {
+ if (dev->urb->actual_length != dev->datalen) {
dprintk("appletouch: incomplete data package.\n");
goto exit;
}
/* reorder the sensors values */
- for (i = 0; i < 8; i++) {
- /* X values */
- dev->xy_cur[i ] = dev->data[5 * i + 2];
- dev->xy_cur[i + 8] = dev->data[5 * i + 4];
- dev->xy_cur[i + 16] = dev->data[5 * i + 42];
- if (i < 2)
- dev->xy_cur[i + 24] = dev->data[5 * i + 44];
-
- /* Y values */
- dev->xy_cur[i + 26] = dev->data[5 * i + 1];
- dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ if (atp_is_geyser_2(dev)) {
+ memset(dev->xy_cur, 0, sizeof(dev->xy_cur));
+
+ /*
+ * The values are laid out like this:
+ * Y1, Y2, -, Y3, Y4, -, ..., X1, X2, -, X3, X4, -, ...
+ * '-' is an unused value.
+ */
+
+ /* read X values */
+ for (i = 0, j = 19; i < 20; i += 2, j += 3) {
+ dev->xy_cur[i] = dev->data[j];
+ dev->xy_cur[i + 1] = dev->data[j + 1];
+ }
+
+ /* read Y values */
+ for (i = 0, j = 1; i < 9; i += 2, j += 3) {
+ dev->xy_cur[ATP_XSENSORS + i] = dev->data[j];
+ dev->xy_cur[ATP_XSENSORS + i + 1] = dev->data[j + 1];
+ }
+ } else {
+ for (i = 0; i < 8; i++) {
+ /* X values */
+ dev->xy_cur[i ] = dev->data[5 * i + 2];
+ dev->xy_cur[i + 8] = dev->data[5 * i + 4];
+ dev->xy_cur[i + 16] = dev->data[5 * i + 42];
+ if (i < 2)
+ dev->xy_cur[i + 24] = dev->data[5 * i + 44];
+
+ /* Y values */
+ dev->xy_cur[i + 26] = dev->data[5 * i + 1];
+ dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ }
}
dbg_dump("sample", dev->xy_cur);
@@ -216,16 +267,24 @@ static void atp_complete(struct urb* urb
dev->x_old = dev->y_old = -1;
memcpy(dev->xy_old, dev->xy_cur, sizeof(dev->xy_old));
- /* 17" Powerbooks have 10 extra X sensors */
- for (i = 16; i < ATP_XSENSORS; i++)
- if (dev->xy_cur[i]) {
- printk("appletouch: 17\" model detected.\n");
+ /* 17" Powerbooks have extra X sensors */
+ for (i = (atp_is_geyser_2(dev)?15:16); i < ATP_XSENSORS; i++) {
+ if (!dev->xy_cur[i]) continue;
+
+ printk("appletouch: 17\" model detected.\n");
+ if(atp_is_geyser_2(dev))
+ input_set_abs_params(dev->input, ABS_X, 0,
+ (20 - 1) *
+ ATP_XFACT - 1,
+ ATP_FUZZ, 0);
+ else
input_set_abs_params(dev->input, ABS_X, 0,
(ATP_XSENSORS - 1) *
ATP_XFACT - 1,
ATP_FUZZ, 0);
- break;
- }
+
+ break;
+ }
goto exit;
}
@@ -282,7 +341,8 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, !!dev->data[80]);
+ input_report_key(dev->input, BTN_LEFT,
+ !!dev->data[dev->datalen - 1]);
input_sync(dev->input);
@@ -353,6 +413,8 @@ static int atp_probe(struct usb_interfac
dev->udev = udev;
dev->input = input_dev;
+ dev->overflowwarn = 0;
+ dev->datalen = (atp_is_geyser_2(dev)?64:81);
dev->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urb) {
@@ -360,7 +422,7 @@ static int atp_probe(struct usb_interfac
goto err_free_devs;
}
- dev->data = usb_buffer_alloc(dev->udev, ATP_DATASIZE, GFP_KERNEL,
+ dev->data = usb_buffer_alloc(dev->udev, dev->datalen, GFP_KERNEL,
&dev->urb->transfer_dma);
if (!dev->data) {
retval = -ENOMEM;
@@ -369,7 +431,7 @@ static int atp_probe(struct usb_interfac
usb_fill_int_urb(dev->urb, udev,
usb_rcvintpipe(udev, int_in_endpointAddr),
- dev->data, ATP_DATASIZE, atp_complete, dev, 1);
+ dev->data, dev->datalen, atp_complete, dev, 1);
usb_make_path(udev, dev->phys, sizeof(dev->phys));
strlcat(dev->phys, "/input0", sizeof(dev->phys));
@@ -385,14 +447,25 @@ static int atp_probe(struct usb_interfac
set_bit(EV_ABS, input_dev->evbit);
- /*
- * 12" and 15" Powerbooks only have 16 x sensors,
- * 17" models are detected later.
- */
- input_set_abs_params(input_dev, ABS_X, 0,
- (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
- input_set_abs_params(input_dev, ABS_Y, 0,
- (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ if (atp_is_geyser_2(dev)) {
+ /*
+ * Oct 2005 15" PowerBooks have 15 X sensors, 17" are detected
+ * later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ ((15 - 1) * ATP_XFACT) - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ ((9 - 1) * ATP_YFACT) - 1, ATP_FUZZ, 0);
+ } else {
+ /*
+ * 12" and 15" Powerbooks only have 16 x sensors,
+ * 17" models are detected later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ }
input_set_abs_params(input_dev, ABS_PRESSURE, 0, ATP_PRESSURE, 0, 0);
set_bit(EV_KEY, input_dev->evbit);
@@ -427,7 +500,7 @@ static void atp_disconnect(struct usb_in
usb_kill_urb(dev->urb);
input_unregister_device(dev->input);
usb_free_urb(dev->urb);
- usb_buffer_free(dev->udev, ATP_DATASIZE,
+ usb_buffer_free(dev->udev, dev->datalen,
dev->data, dev->urb->transfer_dma);
kfree(dev);
}
^ permalink raw reply
* Re: Unable to open an initial console
From: Nigel Cunningham @ 2005-12-17 5:23 UTC (permalink / raw)
To: Addison Baldwin; +Cc: linuxppc-embedded
In-Reply-To: <af313df20512161201u39280d30kdf1ace1c4569d50a@mail.gmail.com>
Hi.
On Sat, 2005-12-17 at 06:01, Addison Baldwin wrote:
> I was sucessful to port U-Boot to our 8272 board. Now I'm experiencing
> a problem:
>
> Our Kernel hangs with the message that says it was trasnferring
> control to linux. A post morten analyzes indicated that it stopped at
> "Unable to open an initial console" in the memory sapce where console
> output should be out (in the sdram, like I had found somewhere in this
> list, how to do it).
>
> I have checked the bootargs values, it is ok:
> bootargs root=/dev/ram console=ttyS0,115200
>
> We also checked our "/dev" and there was a link to console, pointing
> ttyS0. Also, ttyS0 was there too.
Are you using an initrd or initramfs? If so, the device node needs to
exist on that filesystem. This message will only occur if the kernel is
unable to open /dev/console for rw access.
Hope this helps.
Nigel
^ permalink raw reply
* Building a Root Filesystem
From: Michael Boutte @ 2005-12-17 8:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I seem to be stuck at one point in my first embedded Linux project. I
built a custom MPC875 board and have figured out how to get U-Boot to
compile and run. Then I learned to compile an initial Linux 2.4.25 using
the ELDK with a basic root filesystem via the "SELF" included in the
ELDK (thank you WD and others). Now I want to build a new root
filesystem with the modules included. So then I have used the "make
modules" and "make ... modules_install" commands plus used the procedure
in the DULG section 9.6 to unpack the ramdisk image and mount it in the
/mnt/tmp/ directory.
That is point where I do not know what to do next. It would seem that I
need to merge the modules and other items I may want to add (for example
appWeb) with the simple root filesystem and re-compress it for use just
like the original ramdisk image. I just do not seem to find any
information on this process either in the DULG or anywhere else on the web.
Any help would be greatly appreciated.
Mike Boutte
^ permalink raw reply
* Re: Building a Root Filesystem
From: bennett78 @ 2005-12-17 18:32 UTC (permalink / raw)
To: Michael Boutte; +Cc: linuxppc-embedded
In-Reply-To: <43A3C9B2.6040401@pacbell.net>
Michael Boutte wrote:
> Hi,
> I seem to be stuck at one point in my first embedded Linux project. I
> built a custom MPC875 board and have figured out how to get U-Boot to
> compile and run. Then I learned to compile an initial Linux 2.4.25
> using the ELDK with a basic root filesystem via the "SELF" included in
> the ELDK (thank you WD and others). Now I want to build a new root
> filesystem with the modules included. So then I have used the "make
> modules" and "make ... modules_install" commands plus used the
> procedure in the DULG section 9.6 to unpack the ramdisk image and
> mount it in the /mnt/tmp/ directory.
> That is point where I do not know what to do next. It would seem that
> I need to merge the modules and other items I may want to add (for
> example appWeb) with the simple root filesystem and re-compress it for
> use just like the original ramdisk image. I just do not seem to find
> any information on this process either in the DULG or anywhere else on
> the web.
> Any help would be greatly appreciated.
I'm also using Linux 2.4.25 using the ELDK and I would recommend
getting a NFS root file system going first discussed in the following
paper, although written for a MPC5200 is an excellent guideline:
http://emsys.denayer.wenk.be/emcam/Linux_on_MPC5200_(UK).pdf
Worry about a compressed system later. There is also a script for
building a
small root file system (mkrootfsdenx) from a working reference one and
MTD is the way to go to manage your flash for F/W updates and NVdata store.
happy ELDKing,
Frank Bennett
>
> Mike Boutte
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Benjamin Herrenschmidt @ 2005-12-17 21:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <200512062048.56131.arnd@arndb.de>
> - Do we need a way to identify the type of soc bus? There are different
> standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
> My initial idea was to have different device-type properties for these,
> but I now think that device_type = "soc" makes sense for all of them.
> Maybe we could add a model or compatible property for them.
That would be a good idea.
Also, it might be useful to ass a "clock-frequency" to it for processors
where it makes sense. One of the things we are passing from uboot
currently is the list of clock frequencies for PLB/OPB/PCI/... we need
to replace this with appropriate nodes and their respective
"clock-frequency" properties
> - It does not really belong into this document, but is related anyway:
> how do you want to represent this in Linux? Currently, most of these
> would be of_platform_device, but I think it would be good to have
> a new bus_type for it. The advantage would be that you can see the
> devices in /sys/devices/soc@xxx/ even if the driver is not loaded
> and the driver can even be autoloaded by udev.
> Also, which properties should show up in sysfs? All of them or just
> those specified in this document or a subset of them?
If we go that way, we also need to have the SOC type take optionally
part in the matching. That is, the driver matching infos should be based
on model & compatible like OF does, thus we could recommend something
like:
- Define a unique SOC name per SOC bus type/family, for example,
ppc4xxPLB, etc... This goes into /soc/model.
- Optionally, use compatible for similar busses. For example, if you
have a new rev of that PLB that is similar but has extensions called
PLB2, you can have model be ppc4xxPLB2 and compatible containing
ppc4xxPLB.
- Define that the "model" property of a device under /soc is of the
form "socname,devicename"... For example, EMAC would be ppc4xxPLB,emac",
Same rule applies with compatible (this one could be compatible, among
others, with "ppc4xxPLB,emac" and model "ppc4xxPLB2,emac".
> - What do we do with pci root devices? They are often physically connected
> to the internal CPU bus, so it would make sense to represent them
> this way in the device tree. Should we add them to the specification
> here? Would it even work the expected way in Linux?
They are generally below the root of the tree, they don't have to
though. Linux shouldn't care as there is no generic code to instanciate
them, it's platform specific. I may change that in the future though but
this isn't the case yet. The only rule is their name should be "pci"
> - For some devices, you mandate a model property, for others you don't.
> Is this intentional? It might be easier to find the right device
> driver if the match string always contains a model name.
>
> - How would I represent nested interrupt controllers? E.g. suppose I
> have a Cell internal interrupt controller on one SOC bus and
> and an external interrupt controller on another SOC bus but have
> that deliver interrupts to the first one.
Read OF interrupt binding :) Typically, nodes contain either an
interrupt-parent or a parent device with interrupt routing info (like a
PCI bridge) which points to their actual parent controller. If it's a
nested controller, it will itself have an interrupt parent and
"interrupts" property to link it to its parent controller.
> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
> PLB5 bus?
>
Do we have many of these horrors in real life ?
> - The title says 'without Open Firmware', but it should also be allowed
> to use the same SOC bus layout when using SLOF or some other OF
> implementation, right?
Yes, in fact, this document does cover open firmware as well. It defines
the flattened tree format, but doesn't exclude open firmware, and then
defines the subset of OF required by the kernel.
> - Also not new in this version, but still: Should there be support for
> specifying CPUs with multiple SMT threads?
We need to think about this...
Ben.
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Segher Boessenkool @ 2005-12-18 6:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <1134856762.6102.54.camel@gaston>
>> - Do we need a way to identify the type of soc bus? There are
>> different
>> standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
>> My initial idea was to have different device-type properties for
>> these,
>> but I now think that device_type = "soc" makes sense for all of
>> them.
>> Maybe we could add a model or compatible property for them.
>
> That would be a good idea.
"device_type" is what defines the (OF) programming interface. As not
all SoC busses are identical for this, they should not have the same
device_type.
If you do want all of those semi-transparent SoC busses to be found
by one wildcard, you can add it to the "compatible" property.
> Also, it might be useful to ass a "clock-frequency" to it for
> processors
> where it makes sense.
Certainly.
> One of the things we are passing from uboot
> currently is the list of clock frequencies for PLB/OPB/PCI/... we need
> to replace this with appropriate nodes and their respective
> "clock-frequency" properties
>
>> - It does not really belong into this document, but is related anyway:
>> how do you want to represent this in Linux? Currently, most of these
>> would be of_platform_device, but I think it would be good to have
>> a new bus_type for it. The advantage would be that you can see the
>> devices in /sys/devices/soc@xxx/ even if the driver is not loaded
>> and the driver can even be autoloaded by udev.
>> Also, which properties should show up in sysfs? All of them or just
>> those specified in this document or a subset of them?
All that make sense.
> If we go that way, we also need to have the SOC type take optionally
> part in the matching. That is, the driver matching infos should be
> based
> on model & compatible like OF does, thus we could recommend something
> like:
>
> - Define a unique SOC name per SOC bus type/family, for example,
> ppc4xxPLB, etc... This goes into /soc/model.
"model" should be a string that is the "official" vendor name for
the device.
> - Optionally, use compatible for similar busses. For example, if you
> have a new rev of that PLB that is similar but has extensions called
> PLB2, you can have model be ppc4xxPLB2 and compatible containing
> ppc4xxPLB.
"compatible" does not contain alternatives for "model"; it contains
alternatives for "name".
> - Define that the "model" property of a device under /soc is of the
> form "socname,devicename"... For example, EMAC would be
> ppc4xxPLB,emac",
> Same rule applies with compatible (this one could be compatible, among
> others, with "ppc4xxPLB,emac" and model "ppc4xxPLB2,emac".
>
>> - What do we do with pci root devices? They are often physically
>> connected
>> to the internal CPU bus, so it would make sense to represent them
>> this way in the device tree. Should we add them to the specification
>> here? Would it even work the expected way in Linux?
>
> They are generally below the root of the tree, they don't have to
> though. Linux shouldn't care as there is no generic code to instanciate
> them, it's platform specific. I may change that in the future though
> but
> this isn't the case yet. The only rule is their name should be "pci"
No. Their name can be whatever is required. The "device_type" should
be "pci", for conventional PCI busses; and it should be whatever is
defined by the appropriate OF binding for newer, mostly PCI-comnpatible,
busses (like HT, PCIe, PCI-X, etc.)
>> - For some devices, you mandate a model property, for others you
>> don't.
>> Is this intentional? It might be easier to find the right device
>> driver if the match string always contains a model name.
It is up to a device's parent bus to find the correct driver; for
the parent bus, device_type and/or compatible are normally enough
to do the matching. "model" is useful to disambiguate sometimes,
but it normally is _too_ exact to do useful driver matching.
>> - How would I represent nested interrupt controllers? E.g. suppose I
>> have a Cell internal interrupt controller on one SOC bus and
>> and an external interrupt controller on another SOC bus but have
>> that deliver interrupts to the first one.
>
> Read OF interrupt binding :) Typically, nodes contain either an
> interrupt-parent or a parent device with interrupt routing info (like a
> PCI bridge) which points to their actual parent controller. If it's a
> nested controller, it will itself have an interrupt parent and
> "interrupts" property to link it to its parent controller.
Interrupts are evil evil evil as always ;-)
>> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
>> PLB5 bus?
>>
> Do we have many of these horrors in real life ?
Yes, almost every SoC has at least two busses; e.g., you often see
a high-speed coherent "system" bus, and a lower-speed non-coherent
I/O bus connected to it. But there are lots of variations to this
theme.
>> - The title says 'without Open Firmware', but it should also be
>> allowed
>> to use the same SOC bus layout when using SLOF or some other OF
>> implementation, right?
>
> Yes, in fact, this document does cover open firmware as well. It
> defines
> the flattened tree format, but doesn't exclude open firmware, and then
> defines the subset of OF required by the kernel.
>
>> - Also not new in this version, but still: Should there be support for
>> specifying CPUs with multiple SMT threads?
>
> We need to think about this...
SMT threads should not be represented as separate CPUs. But some
CPU resources that are described in a CPU node are non-shared between
SMT threads; we need to find a way to describe those.
The biggest problem is interrupts (as always); the unit-id for a
"cpu" node in OF is the IPI number of that CPU, but on SMT, IPIs
are per thread.
Segher
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Benjamin Herrenschmidt @ 2005-12-18 7:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <3a8648f28b591dee596d6cb195f1cad1@kernel.crashing.org>
> No. Their name can be whatever is required. The "device_type" should
> be "pci", for conventional PCI busses; and it should be whatever is
> defined by the appropriate OF binding for newer, mostly PCI-comnpatible,
> busses (like HT, PCIe, PCI-X, etc.)
Yes, but the recommended practice is still to call them "pci" :) The
device_type of "pci" defines the fact that it's providing a PCI bus, but
is not unique to PCI hosts, p2p bridges share it. It's a convention for
a pci host bridge however to be named "pci" while a p2p bridge is named
"pci-bridge".
As for HT, PCI-X, PCI-E etc... I don't think there are much bindings
around, but I would recommend sticking strictly to the PCI one, only
adding something to either model or compatible. We may want to
standardize some additional things that aren't in the binding, like a
pci-family (pci, pci-e, pci-x, ht) property, or a extended-config-space
to advertise support for config space > 4096, etc.
At this point, I would really like to find out the remains of the OF
working group an kick that back into life to properly define those
things.
> It is up to a device's parent bus to find the correct driver; for
> the parent bus, device_type and/or compatible are normally enough
> to do the matching. "model" is useful to disambiguate sometimes,
> but it normally is _too_ exact to do useful driver matching.
Except that OF platform devices don't really have a parent bus, they
expose a bus_type structure that can be used to match any device node in
the OF tree. There is no and there will not be a 1:1 relationship
between the OF device-tree and the linux one, so we must do compromises.
> Interrupts are evil evil evil as always ;-)
Yah, and I need to design something smart on the linux side to backup my
promise of not requiring device-nodes per PCI devices, since that means
not requiring nodes for p2p bridges neither, and thus impementing a
generic interrupt mapping algorithm that works both with full of
parsing, but also with partial one, doing standard swizzling for bridges
without a node (and with a platform hook to override that optionally).
On my todo list but not done yet.
> Yes, almost every SoC has at least two busses; e.g., you often see
> a high-speed coherent "system" bus, and a lower-speed non-coherent
> I/O bus connected to it. But there are lots of variations to this
> theme.
That shouldn't be a problem anyway. Just cascade them and don't forget
the "ranges" property :)
> SMT threads should not be represented as separate CPUs. But some
> CPU resources that are described in a CPU node are non-shared between
> SMT threads; we need to find a way to describe those.
>
> The biggest problem is interrupts (as always); the unit-id for a
> "cpu" node in OF is the IPI number of that CPU, but on SMT, IPIs
> are per thread.
Yes, that's a problem
Ben.
^ permalink raw reply
* eldk bug?how to fix
From: zengshuai @ 2005-12-18 8:20 UTC (permalink / raw)
To: ppc
[root@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
/tmp/cciJlehe.s:917: Error: unsupported relocation against r3
/tmp/cciJlehe.s:917: Error: unsupported relocation against r3
/tmp/cciJlehe.s:918: Error: unsupported relocation against r3
/tmp/cciJlehe.s:918: Error: unsupported relocation against r3
/tmp/cciJlehe.s:919: Error: unsupported relocation against r3
/tmp/cciJlehe.s:3655: Error: unsupported relocation against r3
[root@localhost atmlz]# ppc_6xx-gcc -S -o temp.s atm_aalx.c
[root@localhost atmlz]# vi temp.s
...................
stw 0,4(9)
.L36:
#APP
mfmsr r3
ori r3,r3,0x8000
andi. r3,r3,0xffbf
mtmsr r3
#NO_APP
lwz 11,0(1)
..............................
I must change those "r3" to "3" manually.
How to fix?
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: eldk bug?how to fix
From: Wolfgang Denk @ 2005-12-18 14:44 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <4440987.1134894054475.JavaMail.postfix@mx3.mail.sohu.com>
In message <4440987.1134894054475.JavaMail.postfix@mx3.mail.sohu.com> you wrote:
> [root@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
> /tmp/cciJlehe.s:917: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:917: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:918: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:918: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:919: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:3655: Error: unsupported relocation against r3
Are you by any chance using inline assembler code in your source
file? This is the only explanation I have, since GCC does not
generate "r3" references in it's assembler code.
It would have been a good idea if you had included your source code
so we could see what you are doing...
> [root@localhost atmlz]# ppc_6xx-gcc -S -o temp.s atm_aalx.c
> [root@localhost atmlz]# vi temp.s
> ...................
> stw 0,4(9)
> .L36:
> #APP
> mfmsr r3
> ori r3,r3,0x8000
> andi. r3,r3,0xffbf
> mtmsr r3
> #NO_APP
> lwz 11,0(1)
> ..............................
I see. This is your own assembler code, not something generated from
C source code.
> I must change those "r3" to "3" manually.
> How to fix?
Don't write incorrect assembler code, or use the required header
files (like ppc_asm.tmpl).
And while we are at it: be careful not to try privileged instructions
in user space.
This is your own error, not a problem with ELDK.
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
If I had to live my life again, I'd make the same mistakes, only
sooner. -- Tallulah Bankhead
^ permalink raw reply
* x86 gdb with ppc8xx gdbserver
From: Robin Mathew @ 2005-12-18 15:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
Hi,
We are trying to setup gdbserver and gdb for target debugging. We were able
to connect and debug with eldk's ppc8xx/gdb and ppc8xx gdbserver without any
issues.
But I am not able to compile gdb in x86 for ppc8xx target. Can you please
point to some source tree of gdb that can be compiled for x86 platform for
ppc8xx target? I tried with gdb version 6.4 but it does not take
--target=ppc8xx option. I think the option that I am using to compile for
target is not right.
Any help in this regard is greatly appreciated.
Thanks,
Robin
[-- Attachment #2: Type: text/html, Size: 590 bytes --]
^ permalink raw reply
* Re: x86 gdb with ppc8xx gdbserver
From: Wolfgang Denk @ 2005-12-18 20:55 UTC (permalink / raw)
To: Robin Mathew; +Cc: linuxppc-embedded
In-Reply-To: <5b74ec4d0512180714r178223f6ub60df08a7ef78fc9@mail.gmail.com>
Dear Robin,
in message <5b74ec4d0512180714r178223f6ub60df08a7ef78fc9@mail.gmail.com> you wrote:
>
> But I am not able to compile gdb in x86 for ppc8xx target. Can you please
> point to some source tree of gdb that can be compiled for x86 platform for
> ppc8xx target? I tried with gdb version 6.4 but it does not take
Since you've been successful with the ELDK binaries, why not using
the ELDK sources? Either the SRPM from the ELDK source distribution
(which gives you 5.2.1), or from the CVS, which has the (not yet
released) ELDK 4.0 code (= 6.3.0)
> --target=ppc8xx option. I think the option that I am using to compile for
> target is not right.
Indeed, it is wrong. There is no such target architecture as "ppc8xx".
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
For every complex problem, there is a solution that is simple, neat,
and wrong. -- H. L. Mencken
^ permalink raw reply
* Re: x86 gdb with ppc8xx gdbserver
From: White @ 2005-12-18 20:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5b74ec4d0512180714r178223f6ub60df08a7ef78fc9@mail.gmail.com>
Am Sun, 18 Dec 2005 20:44:27 +0530 schrieb Robin Mathew
<robbinmathew@gmail.com> :
> Hi,
> We are trying to setup gdbserver and gdb for target debugging. We were able
> to connect and debug with eldk's ppc8xx/gdb and ppc8xx gdbserver without any
> issues.
>
> But I am not able to compile gdb in x86 for ppc8xx target. Can you please
> point to some source tree of gdb that can be compiled for x86 platform for
> ppc8xx target? I tried with gdb version 6.4 but it does not take
> --target=ppc8xx option. I think the option that I am using to compile for
> target is not right.
>
> Any help in this regard is greatly appreciated.
>
> Thanks,
> Robin
Please Look at the Docu, i get this work some month ago, but it was a
different host,build,target config....
i dont know anymore, but perhaps it helps to try to adjust this
settings.
(I can remember some options like "supported archs" or so...)
soory, that I can't provide exact infos, but I hope this helps a little
bit.
Good Luck,
Bye.
^ permalink raw reply
* MPC8272ADS stability issues
From: Laurie, Ian @ 2005-12-18 23:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Does anyone have any news regarding any resolution of this issue?
We have a board exhibiting crashes even at the U-boot level (memory
test for example).
Very interested in hearing if anyone has had some luck resolving
the problem.
Ian
ian at avnet dot com
^ permalink raw reply
* Re : SMP on MV64460
From: Sam Song @ 2005-12-19 2:51 UTC (permalink / raw)
To: Lance Ware; +Cc: linuxppc-embedded
In-Reply-To: <000601c6028c$85eaea80$2d01a8c0@jalexander>
Lance Ware <lware@datadesigncorp.net> wrote:
> I am currently working on a board which has
> MV64460 linked between two 7447a processors. I
> wanted to know if someone has been able to get
> the Linux 2.6 kernel working with any MV64xxx
> bridge.
I happen to have such a board, DB64460-BP, on
hand.
But even 2.4 kernel has some problems with
MV64460
PCI part. I wonder whether there is a 2.4 version
support that with PCI device like VGA card.
Thanks,
Sam
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
^ permalink raw reply
* RE: SMP on MV64460
From: wilhardt @ 2005-12-19 4:09 UTC (permalink / raw)
To: 'Sam Song', 'Lance Ware'; +Cc: linuxppc-embedded
In-Reply-To: <20051219025133.54341.qmail@web15807.mail.cnb.yahoo.com>
There are a few of examples of SMP using the MV64460 from Curtiss =
Wright,
but I don't know of a 7447A SMP (you really need a backside external =
cache
to take advantage of SMP). The CWCEC boards support 2.4 or 2.6.
http://www.cwembedded.com/products/0/2/151.html/
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Sam Song
Sent: Sunday, December 18, 2005 6:52 PM
To: Lance Ware
Cc: linuxppc-embedded@ozlabs.org
Subject: Re : SMP on MV64460
Lance Ware <lware@datadesigncorp.net> wrote:
> I am currently working on a board which has
> MV64460 linked between two 7447a processors. I
> wanted to know if someone has been able to get
> the Linux 2.6 kernel working with any MV64xxx
> bridge.
I happen to have such a board, DB64460-BP, on
hand.=20
But even 2.4 kernel has some problems with
MV64460
PCI part. I wonder whether there is a 2.4 version
support that with PCI device like VGA card.=20
Thanks,
Sam
__________________________________________________
=B8=CF=BF=EC=D7=A2=B2=E1=D1=C5=BB=A2=B3=AC=B4=F3=C8=DD=C1=BF=C3=E2=B7=D1=D3=
=CA=CF=E4?
http://cn.mail.yahoo.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Howto submit drivers/patches ?
From: David H. Lynch Jr. @ 2005-12-19 5:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF22452781.22D7B3D3-ON652570D9.0019E468-652570D9.001A1298@tcs.com>
I am just polishing off bringup a Xilinx Virtex IV/ppc405 system with
minimal hardware under 2.6.14.4.
I have a collection of patches that I can submit for the specific,
board, for the Virtex IV, for board specific hardware, ...
Additionally I have 2 complete boot loader through full serial driver
implementations of a pseudo serial console driver for this board when it
is in a HOST development system - it is a compact flash card normally
plugged into a PC during development and using the PC as the console,
and a complete serial driver chain for the Xilinx UartLite as a console
when not in a Host, or as a general serial driver. The Xilinx Driver is
based heavily on other 2.6 driver/serial drivers and not the 2.4
implementation from Xilinx.
Is this list the right place to submit this ?
Is there a HOWTO addressing the rules/procedures to do so.
I have not looked at the kernel style guides, but the style of this
code is pretty much identical to other Kernel code. The UartLite driver
is virtually indistinguishable from other driver/serial drivers except
the few places where hardware differences require changes, and that
there is a full tree of end-end support similar to what exists for the
8250's.
David H. Lynch Jr.
DLA Systems
354 Rudy Dam Rd.
Lititz, PA 17543
717.627.3770
^ permalink raw reply
* Mac OpenFirmware 3.x questions.
From: Andrei Warkentin @ 2005-12-19 7:11 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I was just wondering if I clearly understand the process of using the
client interface if I ever (in my kernel) decide to set up my own
virtual memory (or for that matter pretty much do anything that
involves modifying CPU state) -
1) Load saved OF-era SDR1, MSR, SPRGs, BATs, segment registers, SRR0,
SRR1, restore OF exception vectors.
2) Flush i/d caches.
3) Call client interface.
4) Load kernel SDR1, MSR, SPRGs, BATs, segment registers, SRR0, SRR1,
restore kernel exception vectors.
5) Flush i/d caches.
Does this seem reasonable? Do I need to save/restore anything else? I
understand that OF (3.x) lives in flash ROM, and only copies the
exception vectors from 0xfff----- down to 0x000----- - but where does
it store the page tables (as used by claim/release) and where is OF
physically/virtually? It would be pretty bad to wipe out OF's .bss or
whatever, or even worse... overwrite the flash itself. :)
Thanks and have a great day.
Andrei Warkentin
andrey.warkentin@gmail.com
Cell: (+1) (847) 321-15-55
Office: (+1) (312) 756-15-00 x614
^ permalink raw reply
* Ramdisk images for test
From: HappyPhot @ 2005-12-19 7:15 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying to use ramdisk for my board. (not success yet)
I followed setion 7.6 of DULG and found got two Ramdisk images
for test for ppc_82xx. One is pRamdisk, another is ramdisk_image.gz.
Who can tell what the difference is between them ?
thank you,
/HappyPhot
^ 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