* Re: [Fastboot] [PATCH] Reserve crashkernel memory region
From: Michael Neuling @ 2006-04-28 7:06 UTC (permalink / raw)
To: mohan; +Cc: fastboot, linuxppc-dev
In-Reply-To: <20060424061015.GA31320@in.ibm.com>
> Now kexec'ed kernel in a PPC64 machine does not reserve memory for
> crashkernel region. So kexec'ed kernel can not load kdump kernel
> reliably.
Owww 3 boots... scary :-)
> Attached kexec-tools patch reserves memory for kdump kernel by adding
> an entry in the reserve memory table. So while kexec'ed kernel is
> booting, it reserves memory for crashkernel region.
This logic is duplicated in prom_init.c.
It'd be cool if the kernel parsed the command line early on (after
prom_init.c) and did the memory reserves there. Then we wouldn't need
this logic in both the kexec tools and prom_init.c.
Mikey
^ permalink raw reply
* [PATCH] yaboot: enable boot from iscsi target via ethernet devices on js20.
From: Doug Maxey @ 2006-04-28 6:05 UTC (permalink / raw)
To: yaboot-devel; +Cc: Linux PowerPC List, Doug Maxey
Certain levels of JS20 firmware will allow the system to boot from an
iscsi target. System OFW accomplishes this by setting up a virtual
disk device with parameters. These parameters, when passed back to
OFW by yaboot, directs the FW to use virtual device over the ethernet
port that will then access iscsi target as a block device. This patch
extracts those parameters from the property of the virtual device and
passes them back to OFW to indicate the kernel is to be retrieved via
the iscsi protocol.
Signed-off-by: Doug Maxey <dwm@austin.ibm.com>
---
Makefile | 2 +-
include/errors.h | 1 +
include/prom.h | 1 +
second/file.c | 47 +++++++++++++++++++++++++++++++++++++++++------
second/prom.c | 3 +++
second/yaboot.c | 6 +++---
ybin/ybin | 2 +-
7 files changed, 51 insertions(+), 11 deletions(-)
5ad3702f0585f73834f8c66b78091184a125c2d2
diff --git a/Makefile b/Makefile
index 39f8633..72ec680 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@ ## Setup
include Config
-VERSION = 1.3.13
+VERSION = 1.3.14rc1-iscsi
# Debug mode (spam/verbose)
DEBUG = 0
# make install vars
diff --git a/include/errors.h b/include/errors.h
index dfe7e5f..e994dd5 100644
--- a/include/errors.h
+++ b/include/errors.h
@@ -38,3 +38,4 @@ #define FILE_ERR_BADDEV -12
/* Device kind */
#define FILE_DEVICE_BLOCK 1
#define FILE_DEVICE_NET 2
+#define FILE_DEVICE_ISCSI 3
diff --git a/include/prom.h b/include/prom.h
index 9700803..194b927 100644
--- a/include/prom.h
+++ b/include/prom.h
@@ -34,6 +34,7 @@ typedef void *ihandle;
typedef void *phandle;
#define PROM_INVALID_HANDLE ((prom_handle)-1UL)
+#define BOOTDEVSZ (2048) /* iscsi args can be in excess of 1040 bytes */
struct prom_args;
typedef int (*prom_entry)(struct prom_args *);
diff --git a/second/file.c b/second/file.c
index 0e58286..0ab3623 100644
--- a/second/file.c
+++ b/second/file.c
@@ -1,6 +1,9 @@
/*
* file.c - Filesystem related interfaces
*
+ * Copyright (C) IBM Corporation, 2006
+ * Doug Maxey <dwm@austin.ibm.com>
+ *
* Copyright (C) 2001, 2002 Ethan Benson
*
* parse_device_path()
@@ -36,7 +39,7 @@ #include "fs.h"
#include "errors.h"
#include "debug.h"
-extern char bootdevice[1024];
+extern char bootdevice[];
static char *netdev_path_to_filename(const char *path)
{
@@ -177,7 +180,7 @@ parse_device_path(char *imagepath, char
char *ptr;
char *ipath = NULL;
char *defdev = NULL;
- int device_kind;
+ int device_kind = -1;
result->dev = NULL;
result->part = -1;
@@ -185,16 +188,45 @@ parse_device_path(char *imagepath, char
if (!imagepath)
return 0;
+
+ /*
+ * Do preliminary checking for an iscsi device; it may appear as
+ * pure a network device (device_type == "network") if this is
+ * ISWI. This is the case on IBM systems doing an iscsi OFW
+ * boot.
+ */
+ if (strstr(imagepath, ",iscsi")) {
+ /*
+ * get the virtual device information from the
+ * "nas-bootdevice" property.
+ */
+ if (! prom_get_chosen("nas-bootdevice", bootdevice, BOOTDEVSZ)) {
+ DEBUG_F("reset boot-device to"
+ " /chosen/nas-bootdevice = %s\n", bootdevice);
+ device_kind = FILE_DEVICE_ISCSI;
+ ipath = strdup(bootdevice);
+ if (!ipath)
+ return 0;
+ }
+ else
+ return 0;
+ }
else if (!(ipath = strdup(imagepath)))
return 0;
if (defdevice) {
defdev = strdup(defdevice);
device_kind = prom_get_devtype(defdev);
- } else
+ } else if (device_kind == -1)
device_kind = prom_get_devtype(ipath);
- if (device_kind != FILE_DEVICE_NET && strchr(defdev, ':') != NULL) {
+ /*
+ * When an iscsi iqn is present, it may have embedded colons, so
+ * don't parse off anything.
+ */
+ if (device_kind != FILE_DEVICE_NET &&
+ device_kind != FILE_DEVICE_ISCSI &&
+ strchr(defdev, ':') != NULL) {
if ((ptr = strrchr(defdev, ':')) != NULL)
*ptr = 0; /* remove trailing : from defdevice if necessary */
}
@@ -202,7 +234,9 @@ parse_device_path(char *imagepath, char
/* This will not properly handle an obp-tftp argument list
* with elements after the filename; that is handled below.
*/
- if (device_kind != FILE_DEVICE_NET && strchr(ipath, ':') != NULL) {
+ if (device_kind != FILE_DEVICE_NET &&
+ device_kind != FILE_DEVICE_ISCSI &&
+ strchr(ipath, ':') != NULL) {
if ((ptr = strrchr(ipath, ',')) != NULL) {
char *colon = strrchr(ipath, ':');
/* If a ':' occurs *after* a ',', then we assume that there is
@@ -223,7 +257,8 @@ parse_device_path(char *imagepath, char
if (!defdev)
result->dev = netdev_path_to_dev(ipath);
- } else if ((ptr = strchr(ipath, ':')) != NULL) {
+ } else if (device_kind != FILE_DEVICE_ISCSI &&
+ (ptr = strrchr(ipath, ':')) != NULL) {
*ptr = 0;
result->dev = strdup(ipath);
if (*(ptr+1))
diff --git a/second/prom.c b/second/prom.c
index 5ec06b8..9bc5415 100644
--- a/second/prom.c
+++ b/second/prom.c
@@ -174,6 +174,9 @@ prom_get_devtype (char *device)
int result;
char tmp[64];
+ if (strstr(device, ",iscsi"))
+ device = strcpy(tmp, "/vdevice/gscsi/disk");
+
/* Find OF device phandle */
dev = prom_finddevice(device);
if (dev == PROM_INVALID_HANDLE) {
diff --git a/second/yaboot.c b/second/yaboot.c
index d7a3a20..bf10b01 100644
--- a/second/yaboot.c
+++ b/second/yaboot.c
@@ -111,7 +111,7 @@ static void setup_display(void);
/* Locals & globals */
int useconf = 0;
-char bootdevice[1024];
+char bootdevice[BOOTDEVSZ];
char *password = NULL;
struct boot_fspec_t boot;
int _machine = _MACH_Pmac;
@@ -1474,10 +1474,10 @@ yaboot_main(void)
if (_machine == _MACH_Pmac)
setup_display();
- prom_get_chosen("bootpath", bootdevice, sizeof(bootdevice));
+ prom_get_chosen("bootpath", bootdevice, BOOTDEVSZ);
DEBUG_F("/chosen/bootpath = %s\n", bootdevice);
if (bootdevice[0] == 0) {
- prom_get_options("boot-device", bootdevice, sizeof(bootdevice));
+ prom_get_options("boot-device", bootdevice, BOOTDEVSZ);
DEBUG_F("boot-device = %s\n", bootdevice);
}
if (bootdevice[0] == 0) {
diff --git a/ybin/ybin b/ybin/ybin
index 210711f..224b50e 100755
--- a/ybin/ybin
+++ b/ybin/ybin
@@ -29,7 +29,7 @@ fi
PRG="${0##*/}"
ABSPRG="$0"
SIGINT="$PRG: Interrupt caught ... exiting"
-VERSION=1.3.13
+VERSION=1.3.14rc1-iscsi
DEBUG=0
VERBOSE=0
TMP="${TMPDIR:-/tmp}"
--
1.3.0
^ permalink raw reply related
* Re: [openib-general] Re: [PATCH 04/16] ehca: userspace support
From: Pekka Enberg @ 2006-04-28 6:32 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, Jörn Engel
In-Reply-To: <6C4A3B96-4752-4FF9-8FBE-C383B00AE014@schihei.de>
Hi Heiko,
On 4/28/06, Heiko J Schick <info@schihei.de> wrote:
> The problem I see with pr_debug() is that it could only activated via
> a compile flag. To use the debug outputs you have to re-compile /
> compile your own kernel.
Do you really need this heavy debug logging in the first place? You
can use kprobes for arbitrary run-time inspection anyway, so logging
everything seems wasteful.
Pekka
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 04/16] ehca: userspace support
From: Heiko J Schick @ 2006-04-28 6:11 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, Jörn Engel
In-Reply-To: <1146177388.19236.1.camel@localhost.localdomain>
Hello Michael,
On 28.04.2006, at 00:36, Michael Ellerman wrote:
> Try pr_debug() in include/linux/kernel.h
The problem I see with pr_debug() is that it could only activated via
a compile flag. To use the debug outputs you have to re-compile /
compile
your own kernel.
Regards,
Heiko
^ permalink raw reply
* Re: [PATCH 06/16] ehca: common include files
From: Kyle Moffett @ 2006-04-28 5:11 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4450A183.6030405@de.ibm.com>
On Apr 27, 2006, at 06:48:35, Heiko J Schick wrote:
> +#define EHCA_EDEB_TRACE_MASK_SIZE 32
> +extern u8 ehca_edeb_mask[EHCA_EDEB_TRACE_MASK_SIZE];
> +#define EDEB_ID_TO_U32(str4) (str4[3] | (str4[2] << 8) | (str4[1]
> << 16) | \
> + (str4[0] << 24))
> +
> +inline static u64 ehca_edeb_filter(const u32 level,
> + const u32 id, const u32 line)
> +{
> + u64 ret = 0;
> + u32 filenr = 0;
> + u32 filter_level = 9;
> + u32 dynamic_level = 0;
> +
> + /* This is code written for the gcc -O2 optimizer which should
> colapse
> + * to two single ints filter_level is the first level kicked out by
> + * compiler means trace everythin below 6. */
> + if (id == EDEB_ID_TO_U32("ehav")) {
> + filenr = 0x01;
> + filter_level = 8;
> + }
> [...]
This whole mess should be a simpler with a table and a loop
struct edeb_filter_entry {
u32 filenr;
u32 filter_level;
};
# define EDEB_FILTER_ENTRY(name,nr,level) { .id = name, .filenr =
nr, .filter_level = level }
static const struct edeb_filter_entry edeb_filter_table[] = {
EDEB_FILTER_ENTRY("clas", 0x02, 8),
[...]
};
Then just iterate over that table in a loop. The end result is much
smaller code and data, and much clearer as to intent as well.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH 10/16] ehca: event queue
From: Segher Boessenkool @ 2006-04-27 22:55 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427114828.GC32127@wohnheim.fh-wedel.de>
>> + if (ret != H_SUCCESS) {
>
> Common convention is to return 0 on success and -ESOMETHING on eror.
> You might want to follow that and remove H_SUCCESS from the complete
> code.
This return code doesn't come from anywhere within the kernel, though.
If we change this, we should get rid of _every_ #define bladibla 0
Do we want that? (I do ;-) )
>> + if (!(vpage = ipz_qpageit_get_inc(&eq->ipz_queue))) {
>
> I personally despise assignments in conditionals. Not sure if this is
> documented in CodingStyle, but IME most kernel hackers tend to dislike
> it as well.
In this case it's obvious; put it on a separate line.
Segher
^ permalink raw reply
* Re: do_mmap_pgoff issue...
From: Paul Mackerras @ 2006-04-27 22:47 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: linuxppc-dev
In-Reply-To: <200604271559.19818.g.jaeger@sysgo.com>
Gerhard Jaeger writes:
> The facts:
> - mmap the last page @ 0xFFFFF000, len 4K
> - result: mmap says EOVERFLOW...
> - the function that failed was do_mmap_pgoff()
>
> Here's the pice of code
>
> /* offset overflow? */
> if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
> return -EOVERFLOW;
>
> It's quite clear why it fails in my case:
> pgoff + (len >> PAGE_SHIFT) will be 0
No, pgoff will be 0xfffff, len will be 1, the sum is 0x100000. You
need to look elsewhere for the problem.
Paul.
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Paul Mackerras @ 2006-04-27 22:42 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427123701.GG32127@wohnheim.fh-wedel.de>
J=F6rn Engel writes:
> 25 parameters=3F If you tell me which drugs were involved in this co=
de,
> I know what to stay away from.
You really need to ask the firmware architects that, since this is
basically a single firmware call.
Mind you, since a lot of the parameters are used to return individual
bytes or half-words, which are then put into structures, it might be
better to pass the pointers to the structures and let the wrapper put
the values straight into the structures.
Paul.
^ permalink raw reply
* Re: [PATCH 04/16] ehca: userspace support
From: Michael Ellerman @ 2006-04-27 22:36 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427114355.GB32127@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
On Thu, 2006-04-27 at 13:43 +0200, Jörn Engel wrote:
> More minors.
>
> On Thu, 27 April 2006 12:48:22 +0200, Heiko J Schick wrote:
> > +
> > + EDEB_EN(7,
> > + "vm_start=%lx vm_end=%lx vm_page_prot=%lx vm_fileoff=%lx "
> > + "address=%lx",
> > + vma->vm_start, vma->vm_end, vma->vm_page_prot, fileoffset,
> > + address);
>
> Gesundheit! Seriously, I suspect "EDEB_EN" is not the best possible
> name to pick.
Try pr_debug() in include/linux/kernel.h
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Tolunay Orkun @ 2006-04-27 21:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427194055.3EED1353A57@atlas.denx.de>
Wolfgang Denk wrote:
> In message <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>> The problem is that there are somethings that u-boot knows that needs
>> to go into the blob (memory size, boot args, initrd info,
>> frequencies, etc.)
>
> Yes. Can we append auch variable data to the fixed part of the dts?
>
>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD: bootm <kernel_addr>
> or bootm <kernel_addr> <ramdisk_addr>
>
> NEW: bootm <kernel_addr> - <dts_addr>
> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
How would you like to handle the case when dts is packed into
multi-image file? Is bootm going to assume that the 3rd Image is dts?
Since dts is tightly coupled to kernel I would prefer something like:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
Best regards,
Tolunay
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Mark A. Greer @ 2006-04-27 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1146174809.30710.14.camel@localhost.localdomain>
On Fri, Apr 28, 2006 at 07:53:29AM +1000, Benjamin Herrenschmidt wrote:
>
> > There are many mv64x60 based platforms working just fine today with
> > CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
> > is that there is a bug in the bridge requiring a hardware workaround.
> > Unfortunately, not all of the hardware vendors have implemented that
> > workaround and I know of one that considers it infeasible and will
> > not implement it.
>
> Define "working fine" ... With the current implementation, and according
> to the spec, it will randomly crap out or checkstop due to the same page
> beging accessed via the NCU and being in the L2 unless you disabled
> speculative loads and made sure it can't prefetch accross page
> boundaries maybe ? Or set the G bit all over the BAT mapping (ouch !).
"working fine" == running in a production environment for
weeks/months without crapping out.
> > If that hardware workaround is not implemented, the options are:
> > a) 100% chance of a system hang with coherency on
> > or
> > b) < 0.0..1% chance of a system hang with coherency off (at least in my
> > experience to far).
> >
> > The choice is simple.
>
> I disagree. A solution that is known to have a hole in it is no good
> even if you haven't managed to trigger it so far. Now it's Gerhard's
> choice.
TBH, I haven't really looked at what Gerhard is doing yet so I can't
comment. No matter what, though, its certainly his choice.
Mark
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-27 21:53 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060427213134.GA12572@mag.az.mvista.com>
> There are many mv64x60 based platforms working just fine today with
> CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
> is that there is a bug in the bridge requiring a hardware workaround.
> Unfortunately, not all of the hardware vendors have implemented that
> workaround and I know of one that considers it infeasible and will
> not implement it.
Define "working fine" ... With the current implementation, and according
to the spec, it will randomly crap out or checkstop due to the same page
beging accessed via the NCU and being in the L2 unless you disabled
speculative loads and made sure it can't prefetch accross page
boundaries maybe ? Or set the G bit all over the BAT mapping (ouch !).
> I expect that the pegasos has that hardware workaround implemented so
> the kernel maintainers for that platform have the good fortune of being
> able to run with coherency on.
I suppose so...
> What Ben says is correct, there is that issue. However, AFAIK, I have
> not yet to run into it.
Hrm... well, I wouldn't rely on that tho.
> If that hardware workaround is not implemented, the options are:
> a) 100% chance of a system hang with coherency on
> or
> b) < 0.0..1% chance of a system hang with coherency off (at least in my
> experience to far).
>
> The choice is simple.
I disagree. A solution that is known to have a hole in it is no good
even if you haven't managed to trigger it so far. Now it's Gerhard's
choice.
Ben.
^ permalink raw reply
* Re: [PATCH 06/16] ehca: common include files
From: Heiko J Schick @ 2006-04-27 21:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, openib-general
In-Reply-To: <200604271319.06844.arnd.bergmann@de.ibm.com>
On 2006-04-27 13:19:06 +0200, Arnd Bergmann <arnd.bergmann@de.ibm.com> said:
> Well, you should also remove this for submission, I guess ;-)
Yeah, I've planed to remove this lines when 2.6.17 official came out.
It is still included because we don't want to introduce unnecessary
dependencies.
I will remove it for the next patchset.
Regards,
Heiko
^ permalink raw reply
* Re: [PATCH 01/16] ehca: integration in Linux kernel build system
From: Heiko J Schick @ 2006-04-27 21:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, openib-general
In-Reply-To: <200604271307.36987.arnd.bergmann@de.ibm.com>
On 2006-04-27 13:07:36 +0200, Arnd Bergmann <arnd.bergmann@de.ibm.com> said:
> It would be more practical to put this patch last instead of
> first so you don't break the build system with partial applies.
I agree. I Will change set for the next patchset.
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org>
In message <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org> you wrote:
>
> > NEW: bootm <kernel_addr> - <dts_addr>
> > or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
>
> do you mean a literal '-' char for the no ramdisk, but dts case?
Yes. We could write "bootm <kernel_addr> NULL <dts_addr>" or "bootm
<kernel_addr> none <dts_addr>" or anythingl ike that as well, but I'm
a lazy typist :-)
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
"...this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head."
- Larry Wall in <1992Aug6.221512.5963@netlabs.com>
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 21:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, U-Boot Users
In-Reply-To: <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org>
In message <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org> you wrote:
>
> Hmm, I guess. There really isn't anything about the device tree that
> is Linux specific. Other OSes could choice to use it. But lets
I guess there are VxWorks BSP's for most of the boards we are talking
about, right? Do they use the device tree? I would be *very*
surprised.
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
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Mark A. Greer @ 2006-04-27 21:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1145594285.28014.12.camel@localhost.localdomain>
On Fri, Apr 21, 2006 at 02:38:05PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2006-04-20 at 14:55 -0700, Eugene Surovegin wrote:
> > On Thu, Apr 20, 2006 at 11:10:55PM +0200, Gerhard Pircher wrote:
> > > Well, Freescale's PPC programming environment manual clearly states that
> > > this will not work on G4 CPUs (74xx). Also Benjamin Herrenschmidt told me,
> > > that this implementation will not work for the reasons I mentioned before.
> > > The approach I'm trying to implement was his idea, so I have to trust in
> > > him.
> >
> > Well, you aren't the first person who tries to run G4 with
> > CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
> > that those people had to implement anything as complex as you are
> > trying to do.
> >
> > You can try asking on #mklinux. It always better to ask people who
> > actually _did_ this :).
> >
> > In fact, I just grepped 2.6 and found
> > #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> > systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
>
> I think some folks tried ... and failed.
Who has tried and failed?
There are many mv64x60 based platforms working just fine today with
CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
is that there is a bug in the bridge requiring a hardware workaround.
Unfortunately, not all of the hardware vendors have implemented that
workaround and I know of one that considers it infeasible and will
not implement it.
I expect that the pegasos has that hardware workaround implemented so
the kernel maintainers for that platform have the good fortune of being
able to run with coherency on.
What Ben says is correct, there is that issue. However, AFAIK, I have
not yet to run into it.
If that hardware workaround is not implemented, the options are:
a) 100% chance of a system hang with coherency on
or
b) < 0.0..1% chance of a system hang with coherency off (at least in my
experience to far).
The choice is simple.
Mark
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Pantelis Antoniou @ 2006-04-27 21:25 UTC (permalink / raw)
To: u-boot-users; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <44512C25.2080105@smiths-aerospace.com>
On Thursday 27 April 2006 23:40, Jerry Van Baren wrote:
> Wolfgang Denk wrote:
> > In message <44511C88.1010107@smiths-aerospace.com> you wrote:
> >> A thought that keeps recurring (but I've suppressed because I don't have
> >> time to play...) is that it would be Really Cool[tm] to store the u-boot
> >> env variables in a flat tree and then pass the env/tree to linux. It
> >
> > If somebody wants to read the environment variables, you don't need
> > to create a flat tree from it.
>
> Understood. That is why it is Really Cool[tm] rather than Really
> Useful[tm] ;-)
>
> > Also, it doesn't solve the original problem as most of the informa-
> > tion you need to pass is NOT part of the environment (and shall not
> > become such a part).
> >
> > Best regards,
> > Wolfgang Denk
>
> I agree and disagree with the parenthetical part of your statement.
> Agree because it _wouldn't_ be a part of u-boot (technically it would be
> if someone put it in their default env for their specific board, but why
> would denx.de care?).
>
> Disagree because, while u-boot needs/uses some env variables,
> engineers/companies/end users are free to add variables and, I dare say,
> most do. If a given board needs to pass certain non u-boot parameters
> to linux, it would simply add that to its env (which already happens).
>
> I'm not sure you (Wolfgang and Kumar) are following my thought fully (or
> my ignorance is showing to everybody but me). The thought is to change
> the native format of the u-boot environment storage from the
> key-string/value-string pairs to the flat tree (OpenFirmware) format
> which still supports the same key-string/value-string capability (but
> can do more than that).
>
> The advantage, as I see it, is that it would be unifying and thus easier
> to maintain the common variables (call it the GRand Unifying Flat Tree
> (GRAFT) ;-). One language (flat tree), no shims, equivalent key/value
> utility (but a different underlying storage format), no visible
> difference for the users (but potentially an upgrade challenge for
> existing boards and env variables).
>
> The disadvantage is that it would be disruptive to u-boot and may cause
> some bloating and discomfort.
>
> gvb
> (the naive)
>
> P.S. For the non-USA readers: "may cause some bloating and discomfort"
> is a standard disclaimer on medicines advertised on TV over here.
>
Since I'm the guy responsible let me weigh in a bit.
For starters, yes it's possible to pass the whole env using the FT tree.
Use CONFIG_OF_HAS_UBOOT_ENV to pass the u-boot env to the FT tree.
As for the rest of the cat-fight, I'm afraid I don't have the energy
to jump in at the moment.
Perhaps tomorrow :)
Regards
Pantelis
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
^ permalink raw reply
* TI1520 Cardbus with CF troubles
From: Travis B. Sawyer @ 2006-04-27 21:12 UTC (permalink / raw)
To: linuxppc-embedded
Greetings:
I'm working on getting some cardbus support into a 8540 based platform.
We're using a TI1520 cardbus controller (pci<->cardbus bridge) and
compact flash.
(Note: this is using 2.4.30 kernel.org kernel + some patches from the
vendor)
At first I was getting no interrupts when the yenta driver was starting
up, but
I back ported some stuff from 2.6 and now the ti1520 is routing the
interrupts
properly through pci:
[root@mbc80-4 01]$ cat /proc/interrupts
CPU0
8: 0 None Edge rtc
83: 12106 OpenPIC Edge enet_tx
84: 19011 OpenPIC Edge enet_rx
88: 0 OpenPIC Edge enet_error
90: 1805 OpenPIC Edge serial
91: 137 OpenPIC Level MPC I2C
98: 1 OpenPIC Level Texas Instruments PCI1250 PC card
Cardbus Controller
99: 1 OpenPIC Level Texas Instruments PCI1250 PC card
Cardbus Controller (#2)
101: 0 OpenPIC Level sb/ife0
102: 0 OpenPIC Level sbqe0
104: 0 OpenPIC Level phy_interrupt
BAD: 0
I have a cf card in the second controller socket. I've strewn printk's
all over and what I'm
finding is that pcmcia_request_io is called with base=0 numports=0x10,
ioAddrLines=4, and
returns with a base of 0x8100.
Here's the pci dump of both functions of the TI device (note, the card
is plugged into the
socket associated with func 1 not func 0):
[root@mbc80-4 01]$ lspci -v -s 01:01
01:01.0 CardBus bridge: Texas Instruments PCI1250 PC card Cardbus
Controller (rev 01)
Flags: bus master, medium devsel, latency 168, IRQ 98
Memory at eafff000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=01, secondary=02, subordinate=02, sec-latency=176
Memory window 0: ea600000-ea61f000 (prefetchable)
Memory window 1: ea700000-ea7ff000
I/O window 0: 00008000-000080ff
I/O window 1: 00008400-000084ff
16-bit legacy interface ports at 0001
01:01.1 CardBus bridge: Texas Instruments PCI1250 PC card Cardbus
Controller (rev 01)
Flags: bus master, medium devsel, latency 168, IRQ 99
Memory at eabfe000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=01, secondary=03, subordinate=03, sec-latency=176
Memory window 0: ea620000-ea63f000 (prefetchable)
Memory window 1: ea800000-ea8ff000
I/O window 0: 00008800-000088ff
I/O window 1: 00008c00-00008cff
16-bit legacy interface ports at 0001
I added printks to the ide do_probe, and all hwif->INB() calls return 0.
My /etc/pcmcia/config.opts adds the following lines:
include port 0x0000-0xffff
include memory 0xe0000000-0xeaffffff
Any ideas?
-travis
more dumps below:
[root@mbc80-4 01]$ cardctl status
Socket 0:
no card
Socket 1:
3.3V 16-bit PC Card
function 0: [ready]
[root@mbc80-4 01]$ cardctl config
Socket 0:
not configured
Socket 1:
Vcc 3.3V Vpp1 3.3V Vpp2 3.3V
ide_config linkio: nports: 0 baseport 0
pcmcia_request_io calling alloc io spaces BLP1 NP1 IOADDRLines: 0 10 4
alloc_io_space s->io BP NP Inuse: 8100 10 10
pcmcia_request_io called alloc io spaces BLP1 NP1 IOADDRLines: 8100 10 4
ide_config b4Config base 8100
ide_config AFConfig base 8100
SELECT_DRIVE sending a0 to 8106
SELECT_DRIVE sending b0 to 8106
SELECT_DRIVE sending a0 to 8106
probing for hda: present=0, media=32, probetype=ATA
[root@mbc80-4 01]$ SELECT_DRIVE sending a0 to 8106
do_probe after select inb= 0
do_probe error reg 0
do_probe nsect reg 0
do_probe sect reg 0
do_probe lcyl reg 0
do_probe hcyl reg 0
do_probe selct reg 0
do_probe stats reg 0
do_probe cntrl reg 0
[root@mbc80-4 ~]$ dump_cis
Socket 0:
no CIS present
Socket 1:
dev_info
fn_specific 120ns, 2kb
common_jedec 0xdf 0x01
manfid 0x0045, 0x0401
vers_1 4.1, "SanDisk", "SDP", "5/3 0.6"
funcid fixed_disk [post]
disk_interface [ide]
disk_features [silicon] [unique] [single]
[sleep] [standby] [idle] [low power]
config base 0x0200 mask 0x000f last_index 0x07
cftable_entry 0x00 [default]
[rdybsy] [mwait] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
memory 0x0000-0x07ff @ 0x0000
cftable_entry 0x00
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x01 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x0000-0x000f [lines=4] [8bit] [16bit]
irq mask 0xffff [level] [pulse] [shared]
cftable_entry 0x01
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x02 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
cftable_entry 0x02
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x03 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
cftable_entry 0x03
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x07
^ permalink raw reply
* Re: [PATCH 00/16] ehca: IBM eHCA InfiniBand Device Driver
From: Heiko Joerg Schick @ 2006-04-27 19:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, linux-kernel, openib-general
In-Reply-To: <20060427125726.GK32127@wohnheim.fh-wedel.de>
On 2006-04-27 14:57:26 +0200, Jörn Engel <joern@wohnheim.fh-wedel.de> said:
> Don't expect much cheer and rejoicing over this. I suspect that akpm
> or Linus will either want the 17 patches merged into one or have a
> patchset where every single patch leaves the kernel in a working
> state, including working eHCA driver.
I don't like the idea to put the whole driver in one patch file. I
would propose to put the patch "ehca: integration in Linux kernel" last
instead
of first, as Arnd mentioned. With that change we leave the kernel in a
working state when applying the patches.
Regards,
Heiko
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Jerry Van Baren @ 2006-04-27 20:40 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list; +Cc: U-Boot Users
In-Reply-To: <20060427194316.CBFBC353A57@atlas.denx.de>
Wolfgang Denk wrote:
> In message <44511C88.1010107@smiths-aerospace.com> you wrote:
>> A thought that keeps recurring (but I've suppressed because I don't have
>> time to play...) is that it would be Really Cool[tm] to store the u-boot
>> env variables in a flat tree and then pass the env/tree to linux. It
>
> If somebody wants to read the environment variables, you don't need
> to create a flat tree from it.
Understood. That is why it is Really Cool[tm] rather than Really
Useful[tm] ;-)
> Also, it doesn't solve the original problem as most of the informa-
> tion you need to pass is NOT part of the environment (and shall not
> become such a part).
>
> Best regards,
> Wolfgang Denk
I agree and disagree with the parenthetical part of your statement.
Agree because it _wouldn't_ be a part of u-boot (technically it would be
if someone put it in their default env for their specific board, but why
would denx.de care?).
Disagree because, while u-boot needs/uses some env variables,
engineers/companies/end users are free to add variables and, I dare say,
most do. If a given board needs to pass certain non u-boot parameters
to linux, it would simply add that to its env (which already happens).
I'm not sure you (Wolfgang and Kumar) are following my thought fully (or
my ignorance is showing to everybody but me). The thought is to change
the native format of the u-boot environment storage from the
key-string/value-string pairs to the flat tree (OpenFirmware) format
which still supports the same key-string/value-string capability (but
can do more than that).
The advantage, as I see it, is that it would be unifying and thus easier
to maintain the common variables (call it the GRand Unifying Flat Tree
(GRAFT) ;-). One language (flat tree), no shims, equivalent key/value
utility (but a different underlying storage format), no visible
difference for the users (but potentially an upgrade challenge for
existing boards and env variables).
The disadvantage is that it would be disruptive to u-boot and may cause
some bloating and discomfort.
gvb
(the naive)
P.S. For the non-USA readers: "may cause some bloating and discomfort"
is a standard disclaimer on medicines advertised on TV over here.
^ permalink raw reply
* Re: FT u-boot shim
From: Jerry Van Baren @ 2006-04-27 19:33 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list; +Cc: U-Boot Users
In-Reply-To: <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org>
Kumar Gala wrote:
>> Let's say we have to support such situations, too.
>>
>>> * dts owned by u-boot??
>> I'm not sure about this. I tend to believe the dts belongs to the
>> kernel.
>>
>>> Some questions/issues:
>>> * ownership of .dts is problematic. I hate having a file duplicated
>>> by both u-boot and kernel. However it also seems bad to make the
>>> build of either depend on the user grabbing a dts from some third
>>> party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS
>>> port. Boards ship with an "old" u-boot, thus we need a kernel
>>> wrapper with .dts. However, newer u-boot's can (hopefully will) have
>>> a dts in them
>> Can we provide the dts as a separate blob that gets built with the
>> kernel image? From U-Boot's point of view, this could be a multi-file
>> image which combines the dts and the kernel into a single file so
>> that users don't have to care much about this.
>
> The problem is that there are somethings that u-boot knows that needs
> to go into the blob (memory size, boot args, initrd info,
> frequencies, etc.)
[snip]
> - kumar
A thought that keeps recurring (but I've suppressed because I don't have
time to play...) is that it would be Really Cool[tm] to store the u-boot
env variables in a flat tree and then pass the env/tree to linux. It
also sounds like a major change & disruption to u-boot :-(. I haven't
looked at what it would do to code size either.
U-boot could then be a better OpenBoot than OpenBoot ;-)
gvb
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:59 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427194055.3EED1353A57@atlas.denx.de>
>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD: bootm <kernel_addr>
> or bootm <kernel_addr> <ramdisk_addr>
>
> NEW: bootm <kernel_addr> - <dts_addr>
> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
do you mean a literal '-' char for the no ramdisk, but dts case?
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:54 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, U-Boot Users
In-Reply-To: <20060427194522.6FA1B353A57@atlas.denx.de>
On Apr 27, 2006, at 2:45 PM, Wolfgang Denk wrote:
> In message <2CD98C5D-
> E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org> you wrote:
>>
>> We can do this w/o too much modification to what is happening in u-
>> boot today. I'd probably like to keep the ability to build a dev
>> tree into the u-boot binary, but make the preferred means to pass a
>
> I don't like this, as it's a very Linux-centric view, but U-Boot is
> supposed to be OS unaware and independent.
Hmm, I guess. There really isn't anything about the device tree that
is Linux specific. Other OSes could choice to use it. But lets
argue about that one once I've got the mechanism in which we pass the
blob in via the bootm command.
The only difference I see would be that the address of the blob would
be implicit if the blob was built into u-boot. We would still use a
passed in blob via the bootm command if given.
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-27 19:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427194055.3EED1353A57@atlas.denx.de>
On Apr 27, 2006, at 2:40 PM, Wolfgang Denk wrote:
> In message
> <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>>
>> The problem is that there are somethings that u-boot knows that needs
>> to go into the blob (memory size, boot args, initrd info,
>> frequencies, etc.)
>
> Yes. Can we append auch variable data to the fixed part of the dts?
appending is not really how it works, but the runtime fixup is doable.
>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD: bootm <kernel_addr>
> or bootm <kernel_addr> <ramdisk_addr>
>
> NEW: bootm <kernel_addr> - <dts_addr>
> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
>
>> As stated before, the main issue is doing some runtime fix ups to the
>> blob before its handed to the kernel.
>
> Let's do exactly this: runtime fix ups.
>
>> We could hand bootm a memory location with a blob and do the fix ups
>> at runtime, we would still have some coupling between the blob and u-
>> boot build. At least the blob wouldn't be built into u-boot.
>
> OK.
Let me play with this some now that I've got some direction.
- kumar
^ 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