* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: john stultz @ 2006-08-17 0:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, mingo, tglx
In-Reply-To: <1155774368.11312.135.camel@localhost.localdomain>
On Thu, 2006-08-17 at 02:26 +0200, Benjamin Herrenschmidt wrote:
> > Hey Ben,
> > I appreciate your looking over my patch. You are correct, the
> > conversion is a bit rough and I've not yet been able to work on the
> > powerpc vDSO, although I'd like to get it working so any help or
> > suggestions would be appreciated (is there a reason the vDSO is written
> > in ASM?).
> >
> > If you have any other concerns w/ that patch, or the generic timekeeping
> > code, please let me know and I'll do what I can to address them.
>
> Well, I've been wanting to look at your stuff and possibly do the
> conversion for some time, provided we don't lose performances ... Our
> current implementation is very optimized to avoid even memory barriers
> in most cases and I doubt we'll be able to be as fine tuned using your
> generic code, thus it's a tradeoff decision that we have to do. But
> then, I need to look into the details before doing any final
> statement :)
Ok, although do let me know if you see places where the generic code
could use any of the optimizations used in powerpc.
thanks
-john
^ permalink raw reply
* Re: Linux hanging on Xilinx SystemACE
From: Grant Likely @ 2006-08-17 1:40 UTC (permalink / raw)
To: Jeff Angielski; +Cc: linuxppc-embedded
In-Reply-To: <1155775917.10357.37.camel@sumo-jaa>
On 8/16/06, Jeff Angielski <jangiels@speakeasy.net> wrote:
> On Wed, 2006-08-16 at 15:48 -0600, Grant Likely wrote:
> > Checking partitions is a user-space activity (fsck). Remove it from
> > your init scripts. Besides, unless your using a microdrive, your ext2
> > rootfs should be mounted read-only which greatly reduces the need for
> > fsck. (because FLASH will wear out after too many writes)
>
> The partition check he is referring to is part of a block device driver
> initialization. It is not fsck. If he were only so luck to be that far
> in the startup sequence... :)
heh; I grepped the 2.6 kernel tree for "Partition check" and didn't
find anything, and I assumed that it wasn't in 2.4 either. Therefore
it must be a fsck message...
You know what they say about assuming.
oops
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Fix irq radix tree remapping typo
From: Benjamin Herrenschmidt @ 2006-08-17 1:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Manoj Iyer
The code for using the radix tree for reverse mapping of interrupts has
a typo that causes it to create incorrect mappings if the software and
hardware numbers happen to be different. This would, among others, cause
the IDE interrupt to fail on js20's. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Please apply to 2.6.18
Index: linux-work/arch/powerpc/kernel/irq.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/irq.c 2006-08-17 09:26:19.000000000 +1000
+++ linux-work/arch/powerpc/kernel/irq.c 2006-08-17 11:27:30.000000000 +1000
@@ -693,7 +693,7 @@ unsigned int irq_radix_revmap(struct irq
/* If not there, try to insert it */
virq = irq_find_mapping(host, hwirq);
if (virq != NO_IRQ)
- radix_tree_insert(tree, virq, &irq_map[virq]);
+ radix_tree_insert(tree, hwirq, &irq_map[virq]);
bail:
spin_unlock_irqrestore(&irq_big_lock, flags);
return virq;
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Ellerman @ 2006-08-17 2:04 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060816194225.C9F1F67B32@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Wed, 2006-08-16 at 14:42 -0500, Michael Neuling wrote:
> The rtas console doesn't have to be Cell specific. If we get both
> rtas tokens, we should just enabled the console then and there.
>
Seems to work fine on Cell.
> Updated Kconfig so we can enable it.
I enable it via the early debugging menu (under kernel hacking), is that
not good enough?
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/rtas.c | 5 +++++
> arch/powerpc/platforms/cell/setup.c | 4 ----
> 3 files changed, 6 insertions(+), 5 deletions(-)
>
> Index: linux-2.6-ozlabs/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/Kconfig
> +++ linux-2.6-ozlabs/arch/powerpc/Kconfig
> @@ -426,7 +426,7 @@ config PPC_IBM_CELL_BLADE
> select UDBG_RTAS_CONSOLE
>
> config UDBG_RTAS_CONSOLE
> - bool
> + bool "RTAS based debug console"
> default n
This should probably depend on RTAS?
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: [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-17 3:27 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1155780267.6910.3.camel@localhost.localdomain>
> Seems to work fine on Cell.
Kewl
> > Updated Kconfig so we can enable it.
>
> I enable it via the early debugging menu (under kernel hacking), is that
> not good enough?
Doesn't that enable CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE not
CONFIG_UDBG_RTAS_CONSOLE?
Without the Kconfig update you don't seem to get presented with an
option but I'm no kbuild expert.
> > config UDBG_RTAS_CONSOLE
> > - bool
> > + bool "RTAS based debug console"
> > default n
>
> This should probably depend on RTAS?
Yeap.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Ellerman @ 2006-08-17 3:45 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060817032723.25A2767B6D@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Wed, 2006-08-16 at 22:27 -0500, Michael Neuling wrote:
> > Seems to work fine on Cell.
>
> Kewl
>
> > > Updated Kconfig so we can enable it.
> >
> > I enable it via the early debugging menu (under kernel hacking), is that
> > not good enough?
>
> Doesn't that enable CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE not
> CONFIG_UDBG_RTAS_CONSOLE?
Yeah, but that then turns on CONFIG_UDBG_RTAS_CONSOLE also. I guess you
guys want to be able to turn on the later without the former, so fair
enough. We turn it on always on the Cell via the PPC_IBM_CELL_BLADE
entry.
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: [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-17 4:02 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1155786333.10665.3.camel@localhost.localdomain>
> Yeah, but that then turns on CONFIG_UDBG_RTAS_CONSOLE also. I guess
> you guys want to be able to turn on the later without the former, so
> fair enough.
Yeap.
Mikey
^ permalink raw reply
* [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-17 4:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, anton
The rtas console doesn't have to be Cell specific. If we get both
RTAS tokens, we should just enabled the console then and there.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Fixed RTAS dependency bug.
arch/powerpc/Kconfig | 3 ++-
arch/powerpc/kernel/rtas.c | 5 +++++
arch/powerpc/platforms/cell/setup.c | 4 ----
3 files changed, 7 insertions(+), 5 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/Kconfig
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/Kconfig
+++ linux-2.6-ozlabs/arch/powerpc/Kconfig
@@ -426,7 +426,8 @@ config PPC_IBM_CELL_BLADE
select UDBG_RTAS_CONSOLE
config UDBG_RTAS_CONSOLE
- bool
+ bool "RTAS based debug console"
+ depends on PPC_RTAS
default n
config XICS
Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
@@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
if (basep)
rtas_getchar_token = *basep;
+
+ if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
+ rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
+ udbg_init_rtas_console();
+
#endif
/* break now */
Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
@@ -150,10 +150,6 @@ static int __init cell_probe(void)
!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
return 0;
-#ifdef CONFIG_UDBG_RTAS_CONSOLE
- udbg_init_rtas_console();
-#endif
-
hpte_init_native();
return 1;
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: Benjamin Herrenschmidt @ 2006-08-17 4:43 UTC (permalink / raw)
To: john stultz; +Cc: linux-kernel, linuxppc-dev, Paul Mackerras, mingo, tglx
In-Reply-To: <1155776171.15360.22.camel@localhost.localdomain>
> > Well, I've been wanting to look at your stuff and possibly do the
> > conversion for some time, provided we don't lose performances ... Our
> > current implementation is very optimized to avoid even memory barriers
> > in most cases and I doubt we'll be able to be as fine tuned using your
> > generic code, thus it's a tradeoff decision that we have to do. But
> > then, I need to look into the details before doing any final
> > statement :)
>
> Ok, although do let me know if you see places where the generic code
> could use any of the optimizations used in powerpc.
Difficult... but maybe. One of the main idea is that the 3 values used
for "calibration" (pre-mult offset, multiplier and post-mult offset) are
in a structure. There is an array of 2 of these and a pointer to the
"current" one. When changing those values, we update the "other" one,
wmb, then flip the pointer. The readers can then mostly be barrier-less
since there is a natural data dependency on the pointer.
Ben.
^ permalink raw reply
* Re: [PATCH] Gunzip call fix for PPC kernel images >4MB
From: Tom Rini @ 2006-08-17 5:04 UTC (permalink / raw)
To: Benjamin Heyne; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <20060816113137.7a8e5608@bob.dt.e-technik.uni-dortmund.de>
On Wed, Aug 16, 2006 at 11:31:37AM +0200, Benjamin Heyne wrote:
> If Kernel images for PPC grow >4MB inflating of the kernel fails.
> Increasing the link/load address doesn't help. Problem is
> solved by replacing the fixed address of the gunzip() call in
> misc-embedded.c with CONFIG_BOOT_LOAD.
I've thought about this a bit and I think the general concept is OK, but
this works with a bit of luck I think.
The arch/ppc/boot code makes some assumptions such as that 4MB-8MB (except
on 40x which is end of the wrapper code to 8MB, and BOOT_LOAD defaults
to 4MB here) is free to use for malloc()'ing for the inflate routine.
It also assumes that the vmlinux.gz will live at BOOT_LOAD + a bit, when
the wrapper is set to kick off linux.
Finally, in arch/ppc/boot/ (for both OF and !OF cases) gunzip looks
like:
void gunzip(void *dst, int dstlen, unsigned char *src, int *lenp)
So I see 2 problems here.
First, there are other calls to gunzip with dstlen hard-coded to 4MB, so
the problem would still exist.
Second, and more complexly we want to make sure that we don't tell
gunzip that the destination size grows into the area it would also be
using to malloc buffers, unless someone can (and please do if possible)
explain that it's really OK to uncompress into our zalloc space (there
is no zfree so maybe it's going to be OK, but I don't know that the
algorithm wouldn't try and reuse buffers which would be bad).
Thanks!
--
Tom Rini
^ permalink raw reply
* [POWERPC] iseries: remove some gcc 4.1 warnings
From: Stephen Rothwell @ 2006-08-17 6:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <200608161515.26166.arnd.bergmann@de.ibm.com>
gcc 4.1 produces some warnings that say it is ignoring the packed
attribute on some structure elements, so, since all the elements of
these structs are packed, pack the structs instead.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/main_store.h | 126 ++++++++++++++-------------
1 files changed, 63 insertions(+), 63 deletions(-)
This version takes into account Arnds good suggestion.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/iseries/main_store.h b/arch/powerpc/platforms/iseries/main_store.h
index 74f6889..1a7a3f5 100644
--- a/arch/powerpc/platforms/iseries/main_store.h
+++ b/arch/powerpc/platforms/iseries/main_store.h
@@ -61,9 +61,9 @@ struct IoHriMainStoreSegment4 {
};
/* Main Store VPD for Power4 */
-struct IoHriMainStoreChipInfo1 {
- u32 chipMfgID __attribute((packed));
- char chipECLevel[4] __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreChipInfo1 {
+ u32 chipMfgID;
+ char chipECLevel[4];
};
struct IoHriMainStoreVpdIdData {
@@ -73,72 +73,72 @@ struct IoHriMainStoreVpdIdData {
char serialNumber[12];
};
-struct IoHriMainStoreVpdFruData {
- char fruLabel[8] __attribute((packed));
- u8 numberOfSlots __attribute((packed));
- u8 pluggingType __attribute((packed));
- u16 slotMapIndex __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreVpdFruData {
+ char fruLabel[8];
+ u8 numberOfSlots;
+ u8 pluggingType;
+ u16 slotMapIndex;
};
-struct IoHriMainStoreAdrRangeBlock {
- void *blockStart __attribute((packed));
- void *blockEnd __attribute((packed));
- u32 blockProcChipId __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreAdrRangeBlock {
+ void *blockStart;
+ void *blockEnd;
+ u32 blockProcChipId;
};
#define MaxAreaAdrRangeBlocks 4
-struct IoHriMainStoreArea4 {
- u32 msVpdFormat __attribute((packed));
- u8 containedVpdType __attribute((packed));
- u8 reserved1 __attribute((packed));
- u16 reserved2 __attribute((packed));
-
- u64 msExists __attribute((packed));
- u64 msFunctional __attribute((packed));
-
- u32 memorySize __attribute((packed));
- u32 procNodeId __attribute((packed));
-
- u32 numAdrRangeBlocks __attribute((packed));
- struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks] __attribute((packed));
-
- struct IoHriMainStoreChipInfo1 chipInfo0 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo1 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo2 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo3 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo4 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo5 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo6 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo7 __attribute((packed));
-
- void *msRamAreaArray __attribute((packed));
- u32 msRamAreaArrayNumEntries __attribute((packed));
- u32 msRamAreaArrayEntrySize __attribute((packed));
-
- u32 numaDimmExists __attribute((packed));
- u32 numaDimmFunctional __attribute((packed));
- void *numaDimmArray __attribute((packed));
- u32 numaDimmArrayNumEntries __attribute((packed));
- u32 numaDimmArrayEntrySize __attribute((packed));
-
- struct IoHriMainStoreVpdIdData idData __attribute((packed));
-
- u64 powerData __attribute((packed));
- u64 cardAssemblyPartNum __attribute((packed));
- u64 chipSerialNum __attribute((packed));
-
- u64 reserved3 __attribute((packed));
- char reserved4[16] __attribute((packed));
-
- struct IoHriMainStoreVpdFruData fruData __attribute((packed));
-
- u8 vpdPortNum __attribute((packed));
- u8 reserved5 __attribute((packed));
- u8 frameId __attribute((packed));
- u8 rackUnit __attribute((packed));
- char asciiKeywordVpd[256] __attribute((packed));
- u32 reserved6 __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreArea4 {
+ u32 msVpdFormat;
+ u8 containedVpdType;
+ u8 reserved1;
+ u16 reserved2;
+
+ u64 msExists;
+ u64 msFunctional;
+
+ u32 memorySize;
+ u32 procNodeId;
+
+ u32 numAdrRangeBlocks;
+ struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks];
+
+ struct IoHriMainStoreChipInfo1 chipInfo0;
+ struct IoHriMainStoreChipInfo1 chipInfo1;
+ struct IoHriMainStoreChipInfo1 chipInfo2;
+ struct IoHriMainStoreChipInfo1 chipInfo3;
+ struct IoHriMainStoreChipInfo1 chipInfo4;
+ struct IoHriMainStoreChipInfo1 chipInfo5;
+ struct IoHriMainStoreChipInfo1 chipInfo6;
+ struct IoHriMainStoreChipInfo1 chipInfo7;
+
+ void *msRamAreaArray;
+ u32 msRamAreaArrayNumEntries;
+ u32 msRamAreaArrayEntrySize;
+
+ u32 numaDimmExists;
+ u32 numaDimmFunctional;
+ void *numaDimmArray;
+ u32 numaDimmArrayNumEntries;
+ u32 numaDimmArrayEntrySize;
+
+ struct IoHriMainStoreVpdIdData idData;
+
+ u64 powerData;
+ u64 cardAssemblyPartNum;
+ u64 chipSerialNum;
+
+ u64 reserved3;
+ char reserved4[16];
+
+ struct IoHriMainStoreVpdFruData fruData;
+
+ u8 vpdPortNum;
+ u8 reserved5;
+ u8 frameId;
+ u8 rackUnit;
+ char asciiKeywordVpd[256];
+ u32 reserved6;
};
--
1.4.1.1
^ permalink raw reply related
* Re: Outstanding Patches Ping
From: Paul Mackerras @ 2006-08-17 6:31 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155679316.10054.129.camel@cashmere.sps.mot.com>
Jon Loeliger writes:
> - 08/03 Convert to mac-address for ethernet MAC data
I don't seem to have this one, could you resend?
> - 08/09 Offer PCI as a CONFIG choice for PPC_86xx
I'll push it to powerpc.git (to go in 2.6.19) shortly, unless you
particularly want it and your "Allow MPC8641 HPCN to build with
CONFIG_PCI disabled too" patches in 2.6.18.
Paul.
^ permalink raw reply
* Re: latest git: compile error: arch/powerpc/kernel/built-in.o
From: Paul Mackerras @ 2006-08-17 6:41 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linux-ppc, ellerman
In-Reply-To: <20060810232102.GB3668@localhost>
Wolfgang Pfeiffer writes:
> Strange tho' - for me at least - that these patches from about 5 weeks (!)
> ago still don't seem to have made it into the current git tree ...
5 weeks ago was a particularly bad time for patches trying to get into
the git tree, since I was on vacation and then travelling to OLS. :)
I've picked up these patches now and I'll send them on for inclusion
in 2.6.18.
Paul.
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Adrian Cox @ 2006-08-17 7:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1155769968.11312.110.camel@localhost.localdomain>
On Thu, 2006-08-17 at 01:12 +0200, Benjamin Herrenschmidt wrote:
> For completeness, there is a known bug with 32 bits and SMP regarding
> icache coherency.... If you have random SIGILL/SEGV under load, that's
> probably what you are hitting. The problem is due to the way we do the
> coherency and isn't trivial to fix unfortunately, though it's also
> fairly rare.
Could you give a few more details? I'd not heard of the problem before,
and I couldn't find any references with a few quick searches. I've not
seen the problem myself, but I've not run any heavy page fault loads,
only Altivec load.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Benjamin Herrenschmidt @ 2006-08-17 7:45 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1155799144.28319.7.camel@localhost.localdomain>
On Thu, 2006-08-17 at 08:19 +0100, Adrian Cox wrote:
> On Thu, 2006-08-17 at 01:12 +0200, Benjamin Herrenschmidt wrote:
> > For completeness, there is a known bug with 32 bits and SMP regarding
> > icache coherency.... If you have random SIGILL/SEGV under load, that's
> > probably what you are hitting. The problem is due to the way we do the
> > coherency and isn't trivial to fix unfortunately, though it's also
> > fairly rare.
>
> Could you give a few more details? I'd not heard of the problem before,
> and I couldn't find any references with a few quick searches. I've not
> seen the problem myself, but I've not run any heavy page fault loads,
> only Altivec load.
Currently, we do the sync in update_mmu_cache() which is called some
time after we instert a new PTE. Thus, there is the scenario where CPU A
gets in set_pte() to insert a new PTE for some code, and before it
reaches update_mmu_cache(), CPU B will hash in that PTE and try to
execute the code (typical case is swapping in code).
The "fix" would be to do the flush in hash_page but it's a bit
complicated since 32 bits hash_page is completely assembly, and going to
struct page PG_arch1 from there will require a few contorsions. We also
want to avoid 2 CPUs flushing at the same time. One thing I thought
about was to have set_pte "mirror" PG_arch1 into a PTE bit and have
hash_page fail with a minor fault whenever that bit isn't set,
effectively delaying until update_mmu_cache is called (you gotta hope
it's always called sometime after we do set_pte ... I'm not even sure we
can rely on that nowadays, I have to check)
Ben.
^ permalink raw reply
* RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
From: Prashant Yendigeri @ 2006-08-17 9:33 UTC (permalink / raw)
To: Ho Jeffrey-r26191; +Cc: linuxppc-embedded
In-Reply-To: <3140C9D90FB6D911ABD7000F206DC9260759B2E0@zhk08exm40.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 5892 bytes --]
Hi,
This is what i am getting from u-boot print messages :
U-Boot 1.1.0(pq3-20040423-r1) (May 5 2006 - 08:56:54)
Freescale PowerPC
Core: E500, Version: 2.0, (0x80200020)
System: 8540, Version: 2.0, (0x80300020)
Clocks: CPU: 660 MHz, CCB: 264 MHz, DDR: 132 MHz, LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
Board: Freescale EVAL8540 Board
CPU: 660 MHz
CCB: 264 MHz
DDR: 132 MHz
LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DRAM: 256 MB
FLASH: 8 MB
L2 cache enabled: 256KB
In: serial
Out: serial
Err: serial
Net: Freescale ENET0: PHY is Marvell 88E1011S (1410c62)
Freescale ENET1: PHY is Marvell 88E1011S (1410c62)
Freescale ENET2: PHY is Intel LXT971A (1378e2)
Freescale ENET0, Freescale ENET1, Freescale ENET2
Hit any key to stop autoboot: 0
MPC8540EVAL=>
MPC8540EVAL=>
This seems to me it is a old board from GDATECH . Data sheet not available
for this.
-prashant
Ho Jeffrey-r26191 <r26191@freescale.com>
08/12/2006 06:32 AM
To
"'Prashant Yendigeri'" <Prashant.Yendigeri@lntinfotech.com>, Kumar Gala
<galak@kernel.crashing.org>
cc
linuxppc-embedded@ozlabs.org
Subject
RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
Hi
>>>>[ 34.041809] 0:00 not found
SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to PHY
such device
SIOCSIFFLAGS: No such device
>>>>> eth0: PHY is Generic MII (ffffffff)
_______________________________________________________
Can you quickly check if you have the right phy id written in your
platform file for your board?
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
________________________________
From:
linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org] On
Behalf Of Prashant Yendigeri
Sent: Friday, August 11, 2006 7:21 PM
To: Kumar Gala
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Gianfar eth driver on 8540 ppc - for 2.4 and
2.6 : different outputs
Hi,
Downloaded 2.6.16.26 and booted up and got this :
/ # ifconfig eth0 172.28.8.254 up
[ 34.034596] 0:00 not found
[ 34.037330] eth0: Could not attach to PHY
[ 34.041809] 0:00 not found
SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to
PHY
such device
SIOCSIFFLAGS: No such device
I had enabled all the PHY devices in .config and also
tried only with Marvell phy enabled.
Kernel boot messages :
[ 2.296555] Gianfar MII Bus: probed
[ 2.301789] eth0: Gianfar Ethernet Controller Version
1.2, 00:01:af:07:9b:8a
[ 2.309039] eth0: Running with NAPI disabled
[ 2.313307] eth0: 64/64 RX/TX BD ring size
[ 2.318498] eth1: Gianfar Ethernet Controller Version
1.2, 00:00:00:00:72:6f
[ 2.325738] eth1: Running with NAPI disabled
[ 2.330006] eth1: 64/64 RX/TX BD ring size
[ 2.335198] eth2: Gianfar Ethernet Controller Version
1.2, 6f:74:3d:2f:64:65
[ 2.342377] eth2: Running with NAPI disabled
[ 2.346662] eth2: 64/64 RX/TX BD ring size
[ 2.351586] Marvell 88E1101: Registered new driver
[ 2.357010] Davicom DM9161E: Registered new driver
[ 2.362443] Davicom DM9131: Registered new driver
[ 2.367775] Cicada Cis8204: Registered new driver
[ 2.373136] LXT970: Registered new driver
[ 2.377794] LXT971: Registered new driver
[ 2.382461] QS6612: Registered new driver
Regards,
Prashant
Kumar Gala <galak@kernel.crashing.org>
08/11/2006 09:40 AM
To
Prashant Yendigeri
<Prashant.Yendigeri@lntinfotech.com>
cc
linuxppc-embedded@ozlabs.org
Subject
Re: Gianfar eth driver on 8540 ppc - for
2.4 and 2.6 : different outputs
On Aug 10, 2006, at 6:18 AM, Prashant Yendigeri wrote:
>
> Hi,
>
> The gianfar driver of 2.6.12 and 2.4.20 give different
outputs on
> the same PPC 8540 board.
>
> What could be the reason ?
>
> Output on 2.4.20 :
> /root # ifconfig eth0 172.28.8.254 up
> eth0: PHY is Marvell 88E1011S (1410c62)
> eth0: Auto-negotiation done
> eth0: Half Duplex
> eth0: Speed 10BT
> eth0: Link is up
>
> Output on 2.6.12
> / # ifconfig eth0 172.28.8.254 up
> eth0: PHY is Generic MII (ffffffff)
It looks like your 2.6.12 kernel isn't handling the PHY
correctly.
I'd recommend upgrading to something newer which has the
phylib
(can't remember which 2.6 that went into).
- kumar
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 13606 bytes --]
^ permalink raw reply
* Re: Problems dynamically linking busybox with ppc libs.
From: Wolfgang Denk @ 2006-08-17 9:48 UTC (permalink / raw)
To: Keith Redfern; +Cc: linuxppc-embedded
In-Reply-To: <367F3B3911959C4DA9991C00166F620C1DE208@EUDUCEX2.europe.ad.flextronics.com>
In message <367F3B3911959C4DA9991C00166F620C1DE208@EUDUCEX2.europe.ad.flextronics.com> you wrote:
>
> I am trying to dynamically link busybox with the correct libraries but>
> run into problems with directory paths and CC/LD flags.
Maybe you do too much?
> I am using the toolchain supplied with ELDK and my target board is
> ppc_8xx based. The busybox version that I am using is 1.1.3.
> I see the following in Rules.mak and have been trying different variable>
> options but with no success.
You are not supposed to meddle with Rules.mk. Also, this is not
necessary at all.
> Is this the correct place to make modifications?
No. No modifications are necessary.
Just run a standard configuration and make sure to select cross
compilation with "ppc_8xx-" as Cross Compiler prefix, i. e.:
-> cd /tmp
-> wget http://busybox.net/downloads/busybox-1.1.3.tar.bz2
-> tar jxf busybox-1.1.3.tar.bz2
-> cd busybox-1.1.3
-> export CROSS_COMPILE=ppc_8xx-
-> make config
...
*
* Build Options
*
...
Do you want to build BusyBox with a Cross Compiler?
(USING_CROSS_COMPILER) [N/y/?] (NEW) y
Cross Compiler prefix (CROSS_COMPILER_PREFIX) [/usr/i386-linux-uclibc/bin/i386-uclibc-] (NEW) ppc_8xx-
Any extra CFLAGS options for the compiler? (EXTRA_CFLAGS_OPTIONS) [] (NEW)
...
-> make
...
LINK busybox_unstripped
STRIP busybox
...
This is so straightforward that I wonder what you moight have done to
run into problems...
> Has anyone already figured the changes required to get this to work with
> ELDK toolchain?
Yes. And if had bothered to check how the busybox RPM was build which
comes included with the ELDK (for example by looking at it's spec
file), then you should have known, too.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Our business is run on trust. We trust you will pay in advance.
^ permalink raw reply
* RE: Problems dynamically linking busybox with ppc libs.
From: Keith Redfern @ 2006-08-17 11:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
I have just realised that I was barking up the wrong tree in regard to=0D=
=0A
this issue. =0D=0A
=0D=0A
My problem turned out not to be a issue with compiling/linking Busybox=0D=
=0A
but that my target was using different libraries to what was specified=0D=
=0A
in my ELDK. I am a newbie to embedded Linux and now understand that this=0D=
=0A
is a fundamental step in getting a working system. =0D=0A
=0D=0A
My confusion came about as my ELDK is not a standard ELDK but came as a=0D=
=0A
BSP from Embedded Planet 852T. Embedded Planet supply a pre-formed=0D=0A
ramdisk image with libraries, Busybox executable, initialisation scripts=0D=
=0A
etc. =0D=0A
=0D=0A
Any executables supplied in this pre-formed ram disk worked fine. An=0D=0A
initial test of the system showed that Busybox worked fine. =0D=0A
=0D=0A
They have scripts that reverse engineer this to a folder and suggest=0D=0A
just making additions/modifications to this folder and then run another=0D=
=0A
script to create a new RAM disk image.=0D=0A
=0D=0A
I didn't see Busybox packaged with the BSP so I downloaded v1.1.3 from=0D=
=0A
the web and started working with it, using the ELDK to build. After this=0D=
=0A
it didn't work. I have now figured out that any new executables built=0D=0A
using the ELDK don't work as they are referencing different versions of=0D=
=0A
the libraries. The pre-formed busybox worked fine as it was built=0D=0A
referencing the libraries in the also pre-formed library directory.=0D=0A
=0D=0A
I don't know why Embedded Planet would have different library versions=0D=
=0A
in the pre-formed library directory and the ELDK! Maybe there to trick=0D=
=0A
newbies!=0D=0A
=0D=0A
Doing a standard Busybox 'make' with no modifications to the make files=0D=
=0A
and aligning the target libraries with that provided as part of the ELDK=0D=
=0A
solved the problem.=0D=0A
=0D=0A
Thanks for help on this ......... Keith.=0D=0A
=0D=0A
-----Original Message-----=0D=0A
From: Wolfgang Denk [mailto:wd@denx.de] =0D=0A
Sent: 17 August 2006 10:48=0D=0A
To: Keith Redfern=0D=0A
Cc: linuxppc-embedded@ozlabs.org=0D=0A
Subject: Re: Problems dynamically linking busybox with ppc libs. =0D=0A
=0D=0A
In message=0D=0A
<367F3B3911959C4DA9991C00166F620C1DE208@EUDUCEX2.europe.ad.flextronics.c=0D=
=0A
om> you wrote:=0D=0A
> =0D=0A
> I am trying to dynamically link busybox with the correct libraries=0D=0A
but> =0D=0A
> run into problems with directory paths and CC/LD flags.=0D=0A
=0D=0A
Maybe you do too much?=0D=0A
=0D=0A
> I am using the toolchain supplied with ELDK and my target board is=0D=0A
> ppc_8xx based. The busybox version that I am using is 1.1.3.=0D=0A
=0D=0A
> I see the following in Rules.mak and have been trying different=0D=0A
variable> =0D=0A
> options but with no success.=0D=0A
=0D=0A
You are not supposed to meddle with Rules.mk. Also, this is not=0D=0A
necessary at all.=0D=0A
=0D=0A
> Is this the correct place to make modifications?=0D=0A
=0D=0A
No. No modifications are necessary.=0D=0A
=0D=0A
Just run a standard configuration and make sure to select cross=0D=0A
compilation with "ppc_8xx-" as Cross Compiler prefix, i. e.:=0D=0A
=0D=0A
-> cd /tmp=0D=0A
-> wget http://busybox.net/downloads/busybox-1.1.3.tar.bz2=0D=0A
-> tar jxf busybox-1.1.3.tar.bz2=0D=0A
-> cd busybox-1.1.3=0D=0A
-> export CROSS_COMPILE=3Dppc_8xx-=0D=0A
-> make config=0D=0A
...=0D=0A
*=0D=0A
* Build Options=0D=0A
*=0D=0A
...=0D=0A
Do you want to build BusyBox with a Cross Compiler?=0D=0A
(USING_CROSS_COMPILER) [N/y/?] (NEW) y=0D=0A
Cross Compiler prefix (CROSS_COMPILER_PREFIX)=0D=0A
[/usr/i386-linux-uclibc/bin/i386-uclibc-] (NEW) ppc_8xx-=0D=0A
Any extra CFLAGS options for the compiler? (EXTRA_CFLAGS_OPTIONS) []=0D=0A
(NEW)=0D=0A
...=0D=0A
-> make=0D=0A
...=0D=0A
LINK busybox_unstripped=0D=0A
STRIP busybox=0D=0A
...=0D=0A
=0D=0A
This is so straightforward that I wonder what you moight have done to=0D=0A
run into problems...=0D=0A
=0D=0A
=0D=0A
> Has anyone already figured the changes required to get this to work=0D=0A
with=0D=0A
> ELDK toolchain?=0D=0A
=0D=0A
Yes. And if had bothered to check how the busybox RPM was build which=0D=0A
comes included with the ELDK (for example by looking at it's spec=0D=0A
file), then you should have known, too.=0D=0A
=0D=0A
Best regards,=0D=0A
=0D=0A
Wolfgang Denk=0D=0A
=0D=0A
-- =0D=0A
Software Engineering: Embedded and Realtime Systems, Embedded Linux=0D=0A
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de=0D=0A
Our business is run on trust. We trust you will pay in advance.=0D=0A
=0D=0A
Legal Disclaimer:=0A
The information contained in this message may be privileged and confident=
ial. It is intended to be read only by the individual or entity to whom i=
t is addressed or by their designee. If the reader of this message is not=
the intended recipient, you are on notice that any distribution of this =
message, in any form, is strictly prohibited. If you have received this m=
essage in error, please immediately notify the sender and delete or destr=
oy any copy of this message=0D=0A
^ permalink raw reply
* Re: latest git: compile error: arch/powerpc/kernel/built-in.o
From: Wolfgang Pfeiffer @ 2006-08-17 12:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc, ellerman
In-Reply-To: <17636.4022.216093.611990@cargo.ozlabs.ibm.com>
On Thu, Aug 17, 2006 at 04:41:58PM +1000, Paul Mackerras wrote:
> Wolfgang Pfeiffer writes:
>
> > Strange tho' - for me at least - that these patches from about 5 weeks (!)
> > ago still don't seem to have made it into the current git tree ...
>
> 5 weeks ago was a particularly bad time for patches trying to get into
> the git tree, since I was on vacation and then travelling to OLS. :)
[ ... ]
Michael, Paul, and everyone else being involved:
My apologies for my perhaps too strong wording when I was complaining
about the delay ... I didn't mean the words as ugly as they actually
might read ...
And after all <wild guess following ... :) > if there were more folks
actually compiling these kernels on machines like the one mentioned,
*and* telling about the results, the delay perhaps would have been
much shorter .. :)
Thanks for your fine work for this software, to everyone out there in
Kernel City.
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: boot kernel 2.6.18 is hang???
From: Milton Miller @ 2006-08-17 13:02 UTC (permalink / raw)
To: jiehanca, linuxppc-embedded
In-Reply-To: <20060816091103.75046.qmail@web15105.mail.cnb.yahoo.com>
On Wed Aug 16 2006 04:11:03 AM CDT, jie han wrote:
> I am trying to take a working embedded linux system from kernel 2.4 to
> 2.6. The hardware is a custom board using a mpc8270vr processor.
> The working system uses u-boot 1.1.4 with linux kernel 2.4.24.
>
> I am using the same u-boot and I am trying to port linux kernel 2.6.18.
> I believe I have done everything required to get the kernel booting. However, the kernel
> seems to hang after being uncompressed. Here is what I see after running
> bootm from u-boot:
...
> log_buf context is
> OLT=> md 1b9d60 100
> 001b9d60: c020c0a4 00004000 00000000 ffffffff . ....@.........
> 001b9d70: 00000001 c01b9d74 c01b9d74 00000001 .......t...t....
> 001b9d80: c01b9d80 c01b9d80 ffffffff 61637175 ............acqu
> 001b9d90: 6972655f 636f6e73 6f6c655f 73656d00 ire_console_sem.
> 001b9da0: 63616c6c 5f636f6e 736f6c65 5f647269 call_console_dri
> 001b9db0: 76657273 00000000 ffffffff 00000001 vers............
>
> Any ideas would be appreciated.
On 2.6, log_buf is a pointer so that the kernel can switch to a different
sized dynamically allocated buffer on command line request. You
can just follow it to find out what to read, or just lookup __logbuf
which is the initial value and used when you don't specify a new size.
milton
^ permalink raw reply
* Re: Outstanding Patches Ping
From: Jon Loeliger @ 2006-08-17 13:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <17636.3393.801267.484874@cargo.ozlabs.ibm.com>
So, like, the other day Paul Mackerras mumbled:
> Jon Loeliger writes:
>
> > - 08/03 Convert to mac-address for ethernet MAC data
>
> I don't seem to have this one, could you resend?
Coming up....
> > - 08/09 Offer PCI as a CONFIG choice for PPC_86xx
>
> I'll push it to powerpc.git (to go in 2.6.19) shortly, unless you
> particularly want it and your "Allow MPC8641 HPCN to build with
> CONFIG_PCI disabled too" patches in 2.6.18.
My preference would be to have them both in 18 if possible.
Thanks,
jdl
^ permalink raw reply
* [PATCH resend] Convert to mac-address for ethernet MAC address data.
From: Jon Loeliger @ 2006-08-17 13:42 UTC (permalink / raw)
To: linuxppc-dev
Also accept "local-mac-address". However the old "address"
is now obsolete, but accepted for backwards compatibility.
It should be removed after all device trees have been
converted to use "mac-address".
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
This is a resend of
Submitter Jon Loeliger
Date 2006-08-04 07:25:38
Message ID <1154640338.26770.34.camel@cashmere.sps.mot.com>
Also found here:
http://ozlabs.org/pipermail/linuxppc-dev/2006-August/024851.html
http://patchwork.ozlabs.org/linuxppc/patch?id=6444
And ACK'ed by Kumar here:
http://ozlabs.org/pipermail/linuxppc-dev/2006-August/025169.html
Documentation/powerpc/booting-without-of.txt | 10 +++++-----
arch/powerpc/sysdev/fsl_soc.c | 12 ++++++++++--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 3c62e66..8c48b8a 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1196,7 +1196,7 @@ platforms are moved over to use the flat
- model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
- compatible : Should be "gianfar"
- reg : Offset and length of the register set for the device
- - address : List of bytes representing the ethernet address of
+ - mac-address : List of bytes representing the ethernet address of
this controller
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
@@ -1216,7 +1216,7 @@ platforms are moved over to use the flat
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
- address = [ 00 E0 0C 00 73 00 ];
+ mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <d 3 e 3 12 3>;
interrupt-parent = <40000>;
phy-handle = <2452000>
@@ -1498,7 +1498,7 @@ not necessary as they are usually the sa
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
- address = [ 00 E0 0C 00 73 00 ];
+ mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <d 3 e 3 12 3>;
interrupt-parent = <40000>;
phy-handle = <2452000>;
@@ -1511,7 +1511,7 @@ not necessary as they are usually the sa
model = "TSEC";
compatible = "gianfar";
reg = <25000 1000>;
- address = [ 00 E0 0C 00 73 01 ];
+ mac-address = [ 00 E0 0C 00 73 01 ];
interrupts = <13 3 14 3 18 3>;
interrupt-parent = <40000>;
phy-handle = <2452001>;
@@ -1524,7 +1524,7 @@ not necessary as they are usually the sa
model = "FEC";
compatible = "gianfar";
reg = <26000 1000>;
- address = [ 00 E0 0C 00 73 02 ];
+ mac-address = [ 00 E0 0C 00 73 02 ];
interrupts = <19 3>;
interrupt-parent = <40000>;
phy-handle = <2452002>;
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 4a6aa64..92ba378 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -166,8 +166,16 @@ static int __init gfar_of_init(void)
goto err;
}
- mac_addr = get_property(np, "address", NULL);
- memcpy(gfar_data.mac_addr, mac_addr, 6);
+ mac_addr = get_property(np, "local-mac-address", NULL);
+ if (mac_addr == NULL)
+ mac_addr = get_property(np, "mac-address", NULL);
+ if (mac_addr == NULL) {
+ /* Obsolete */
+ mac_addr = get_property(np, "address", NULL);
+ }
+
+ if (mac_addr)
+ memcpy(gfar_data.mac_addr, mac_addr, 6);
if (model && !strcasecmp(model, "TSEC"))
gfar_data.device_flags =
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* Power Management Support
From: Eran Ben-Avi @ 2006-08-17 13:37 UTC (permalink / raw)
To: linux-ppc
Hi Guys,
I'm trying to add the board a cpu power management
support.
I'm using IBM 750GX.
I red about the ACPI mechanism.Is this type of cpu
support it ? I want to add the kernel some mechanism
that enable to chose which state to put the cpu
(SLEEP,NAP,DOZE),is it possible(recommended) or should
the Linux do it differently ?
Thanks...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Power Management Support
From: Eran Ben-Avi @ 2006-08-17 15:22 UTC (permalink / raw)
To: linux-ppc-dev
Hi Guys,
I'm trying to add the board a cpu power management
support.
I'm using IBM 750GX.
I red about the ACPI mechanism.Is this type of cpu
support it ? I want to add the kernel some mechanism
that enable to chose which state to put the cpu
(SLEEP,NAP,DOZE),is it possible(recommended) or should
the Linux do it differently ?
Thanks...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Gunzip call fix for PPC kernel images >4MB
From: Dan Malek @ 2006-08-17 16:09 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <20060817050408.GJ3249@smtp.west.cox.net>
On Aug 17, 2006, at 1:04 AM, Tom Rini wrote:
> The arch/ppc/boot code makes some assumptions such as that 4MB-8MB
> (except
> on 40x which is end of the wrapper code to 8MB, and BOOT_LOAD defaults
> to 4MB here) is free to use for malloc()'ing for the inflate routine.
>
> It also assumes that the vmlinux.gz will live at BOOT_LOAD + a bit,
> when
> the wrapper is set to kick off linux.
First, why do you have a 4 MB kernel?
Second, another bit of luck is that most processors rely on
the boot information passed to be in the lower 8M of memory.
There are many comments about this in the initialization code,
I don't know how many processors actually rely on this. So,
if you allow large kernels to be loaded into memory, there should
be some test to ensure we still have space for these boot
parameters, however they are passed.
Thanks.
-- Dan
^ 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