* Re: About 2.6.14 on AMCC Yosemite board
From: Wolfgang Denk @ 2005-11-02 16:46 UTC (permalink / raw)
To: KylongMu; +Cc: Linuxppc-embedded
In-Reply-To: <20051102135009.27C46102A@smtp.263.net>
Dear Kylong Mu,
in message <20051102135009.27C46102A@smtp.263.net> you wrote:
>
> I've got my Yosemite board today, it's shows very good by default test.
> I downloaded the 2.6.14 according the repository from your website by cogito.
> with default configure, I boot with the uImage, but the system halt, attachment
> is the message.
> I don't know what happen with it, pls help me.
...
> DRAM: 256 MB
> FLASH: 32 MB
---------^^^^^
That's the problem. The board we got from AMCC for the port and for
testing all had 64 MB flash, and there was no information that other
configurations are available too. The MTD mapping driver ist a bit
braindead at the moment and assumes 64 MB. This fails on your board.
The quick and dirty fix is to edit "drivers/mtd/maps/yosemite.c" and
replace the lines:
...
31
32 #define WINDOW_ADDR 0xfc000000
33 #define WINDOW_SIZE 0x04000000
34
...
with:
#define WINDOW_ADDR 0xFE000000
#define WINDOW_SIZE 0x02000000
We will implement a better fix (automatically adjust values according
to the values pased by the boot loader) later today / early tomorrow.
Sorry for the inconvenience.
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 you want strict real-time behavior, run in the real time schedu-
ling class. But there are no seatbelts or airbags; main(){for(;;);}
can hard hang your system. -- Bart Smaalders
^ permalink raw reply
* [PATCH] ppc - fix build warnings in arch/ppc/kernel/traps.c
From: Becky Bruce @ 2005-11-02 16:52 UTC (permalink / raw)
To: linuxppc-dev
ppc: Fix build warnings in traps.c
The latest updates to bug.h generate build warnings in traps.c in
arch/ppc. Fix print format specifiers to account for change of line type
to long from int.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
commit fdbe8ff0c9719da6bcbe6fedf10fb3d32c09ec92
tree 6330b8c00cd62dab8b58cd8808619cf3a1d44f69
parent 211317f02e1d2ac3ebd5bf139889160c834573da
author Becky Bruce <becky.bruce@freescale.com> Wed, 02 Nov 2005 10:47:59 -0600
committer Becky Bruce <becky.bruce@freescale.com> Wed, 02 Nov 2005 10:47:59 -0600
arch/ppc/kernel/traps.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
index f265b81..16adde6 100644
--- a/arch/ppc/kernel/traps.c
+++ b/arch/ppc/kernel/traps.c
@@ -606,22 +606,22 @@ int check_bug_trap(struct pt_regs *regs)
if (bug->line & BUG_WARNING_TRAP) {
/* this is a WARN_ON rather than BUG/BUG_ON */
#ifdef CONFIG_XMON
- xmon_printf(KERN_ERR "Badness in %s at %s:%d\n",
+ xmon_printf(KERN_ERR "Badness in %s at %s:%ld\n",
bug->function, bug->file,
bug->line & ~BUG_WARNING_TRAP);
#endif /* CONFIG_XMON */
- printk(KERN_ERR "Badness in %s at %s:%d\n",
+ printk(KERN_ERR "Badness in %s at %s:%ld\n",
bug->function, bug->file,
bug->line & ~BUG_WARNING_TRAP);
dump_stack();
return 1;
}
#ifdef CONFIG_XMON
- xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%d!\n",
+ xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
bug->function, bug->file, bug->line);
xmon(regs);
#endif /* CONFIG_XMON */
- printk(KERN_CRIT "kernel BUG in %s at %s:%d!\n",
+ printk(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
bug->function, bug->file, bug->line);
return 0;
^ permalink raw reply related
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-02 16:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17256.17408.247708.622755@cargo.ozlabs.ibm.com>
On Wed, 2005-11-02 at 15:43 +1100, Paul Mackerras wrote:
> Those errors were all due to getting powerbook sleep code included
> because you have CONFIG_PM=y. I have changed things so that that code
> doesn't get included on a 64-bit build (at least until BenH gets sleep
> going on the G5 :).
OK, now the Fedora rawhide kernel builds for ppc64 with arch/powerpc and
runs on both my POWER5 and G5 test boxes. I need this if I want nvram
support on the G5 though.
Should we be using CONFIG_GENERIC_NVRAM on ppc64, and actually allowing
the nvram support to be optional?
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -351,7 +350,7 @@ void __init pmac_setup_arch(void)
find_via_pmu();
smu_init();
-#ifdef CONFIG_NVRAM
+#if defined(CONFIG_NVRAM) || defined(CONFIG_PPC64)
pmac_nvram_init();
#endif
--
dwmw2
^ permalink raw reply
* [PATCH] ppc32 8xx: export symbols required for modular IDE
From: Marcelo Tosatti @ 2005-11-02 14:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
diff-tree 6ace3f3688d39df333975c0a1257f6364975b75f (from eea4169e9343e5e464355a442eca5c5cd6f3485e)
Author: Marcelo Tosatti <marcelo@pegasos.cnet>
Date: Tue Oct 25 17:12:43 2005 -0500
ppc32 8xx: export symbols required for modular IDE
Building modules, stage 2.
MODPOST
*** Warning: "__ide_mm_insl" [drivers/ide/ide-core.ko] undefined!
*** Warning: "__ide_mm_outsw" [drivers/ide/ide-core.ko] undefined!
*** Warning: "__ide_mm_insw" [drivers/ide/ide-core.ko] undefined!
*** Warning: "__ide_mm_outsl" [drivers/ide/ide-core.ko] undefined!
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index 2ccb58f..5152db8 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -136,6 +136,11 @@ EXPORT_SYMBOL(outw);
EXPORT_SYMBOL(outl);
EXPORT_SYMBOL(outsl);*/
+EXPORT_SYMBOL(__ide_mm_insl);
+EXPORT_SYMBOL(__ide_mm_outsw);
+EXPORT_SYMBOL(__ide_mm_insw);
+EXPORT_SYMBOL(__ide_mm_outsl);
+
EXPORT_SYMBOL(_insb);
EXPORT_SYMBOL(_outsb);
EXPORT_SYMBOL(_insw);
^ permalink raw reply related
* [PATCH] ppc32 8xx: Fix harmless warning in 8xx_io/commproc.c
From: Marcelo Tosatti @ 2005-11-02 14:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
diff-tree eea4169e9343e5e464355a442eca5c5cd6f3485e (from 3fff5da0af579a9cfadedca55dff888cde61b954)
Author: Marcelo Tosatti <marcelo@pegasos.cnet>
Date: Tue Oct 25 17:10:10 2005 -0500
Fix harmless warning in 8xx_io/commproc.c
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
index 5bbb8e2..973e609 100644
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -83,6 +83,8 @@ extern uint m8xx_cpm_hostalloc(uint size
extern int m8xx_cpm_hostfree(uint start);
extern void m8xx_cpm_hostdump(void);
+extern void cpm_load_patch(volatile immap_t *immr);
+
/* Buffer descriptors used by many of the CPM protocols.
*/
typedef struct cpm_buf_desc {
^ permalink raw reply related
* [PATCH] ppc32 8xx: fix cpm_dpalloc() comment
From: Marcelo Tosatti @ 2005-11-02 14:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
Current comment on top of m8xx_cpm_dpinit is wrong.
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 18fa51c..4306deb 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -390,9 +390,8 @@ void m8xx_cpm_dpinit(void)
/*
* Allocate the requested size worth of DP memory.
- * This function used to return an index into the DPRAM area.
- * Now it returns the actuall physical address of that area.
- * use m8xx_cpm_dpram_offset() to get the index
+ * This function returns an offset into the DPRAM area.
+ * Use cpm_dpram_addr() to get the virtual address of the area.
*/
uint cpm_dpalloc(uint size, uint align)
{
^ permalink raw reply related
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-02 9:50 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <200511020055.58010.pantelis.antoniou@gmail.com>
On Wed, Nov 02, 2005 at 12:55:57AM +0200, Pantelis Antoniou wrote:
> On Tuesday 01 November 2005 19:25, Marcelo Tosatti wrote:
> > On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> > > Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> > > address fixes the problem.
> >
> > Hi Panto,
> >
> > Its working fine around here. How much of a vanilla 2.6.14 your is?
> >
> > [root@CAS root]# cat /proc/cpuinfo
> > processor : 0
> > cpu : 8xx
> > clock : 48MHz
> > bus clock : 48MHz
> > revision : 0.0 (pvr 0050 0000)
> > bogomips : 47.82
> > [root@CAS root]# uname -a
> > Linux CAS 2.6.14 #2 Tue Nov 1 16:20:28 CST 2005 ppc unknown
> >
> >
>
> Vanila 2.6.14 worked fine too.
>
> It's the mm patches that started coming in later.
> Unfortunately the version did not change, so I can't provide it.
> Did you used a current git tree?
No I did not - will do and chase the bug.
Thanks.
^ permalink raw reply
* [PATCH] ppc32: Fixed warning
From: Vitaly Bordug @ 2005-11-02 19:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 153 bytes --]
This adds missing header and thus fix the warning issued by ming prototype.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: 8xx_setup.patch --]
[-- Type: text/x-patch, Size: 289 bytes --]
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -45,6 +45,7 @@
#include <asm/bootinfo.h>
#include <asm/time.h>
#include <asm/xmon.h>
+#include <asm/ppc_sys.h>
#include "ppc8xx_pic.h"
^ permalink raw reply
* SM501 Frame Buffer driver on PPC
From: Absolut Hunter @ 2005-11-03 1:40 UTC (permalink / raw)
To: linuxppc-embedded
All,
I am attempting to bring up a SM501 frame buffer driver on our PPC MPC8280
board. Using the Denx Kernel 2.4.25 I see that most of this is already
included in the kernel.
However a few questions:
The TQM5200 Board uses this driver, but I am gathering this is a PCI based
video setup?; Our board uses a local bus memory interface. I.e. we have
setup the SM501 to be in the SH-3/4 Slave mode.
We have dedicated 32Megs of Video memory to be local only to the SM501, and
mapped it to 0xF8000000 on /CS6, placing the registers at 0xFBE00000
Anyway, I have the UPMA machine setup to communicate with the SM501 and have
verified basic communication with registers, etc.. When using Linux the
kernel Oops's when register_framebuffer is called. I have setup the
voyager.h file to use the correct addresses.
Has anyone used the SM501 driver with this type of NON-Unified memory
architecture? I am guessing this can be confusing to the driver since the
frame buffer registers inside the SM501 need to be using offset ZERO instead
of the 0xF8000000 like the MPC8280 sees.
Thanks,
-Russell McGuire
^ permalink raw reply
* Re: SM501 Frame Buffer driver on PPC
From: Dan Malek @ 2005-11-03 4:30 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <000901c5e017$91aef880$6405a8c0@absolut>
On Nov 2, 2005, at 8:40 PM, Absolut Hunter wrote:
> Has anyone used the SM501 driver with this type of NON-Unified memory
> architecture?
What do you mean, non-unified?
> I am guessing this can be confusing to the driver since the
> frame buffer registers inside the SM501 need to be using offset ZERO
> instead
> of the 0xF8000000 like the MPC8280 sees.
The SM501 PCI driver assumes the addresses are from the PCI
base address, not from zero. Properly using the local bus address
in a similar way should work just fine.
Thanks.
-- Dan
^ permalink raw reply
* 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-03 6:33 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org; +Cc: linuxppc-dev list
For those who experience crashes on sleep and/or wakeup (typically due
to USB) with 2.6.14, I made a test patch that might help. Please let me
know if it makes things more reliable.
http://gate.crashing.org/~benh/fix-ohci-sleep.diff
Note that the patch is totally untested here so it may be just plain
bogus :)
Ben.
^ permalink raw reply
* RE: SM501 Frame Buffer driver on PPC
From: Martin Krause @ 2005-11-03 8:19 UTC (permalink / raw)
To: Absolut Hunter, linuxppc-embedded
Hi Russell,
Absolut Hunter wrote on Thursday, November 03, 2005 2:40 AM:=20
> The TQM5200 Board uses this driver, but I am gathering this is a PCI
> based=20
> video setup?; Our board uses a local bus memory interface. I.e. we
> have=20
> setup the SM501 to be in the SH-3/4 Slave mode.
On the TQM5200 the SM501 is connected over the local bus, not over
PCI. The SH-4 Interface is used.
> We have dedicated 32Megs of Video memory to be local only to the
> SM501, and mapped it to 0xF8000000 on /CS6, placing the registers at
> 0xFBE00000=20
>=20
> Anyway, I have the UPMA machine setup to communicate with the SM501
> and have verified basic communication with registers, etc.. When
> using Linux the=20
> kernel Oops's when register_framebuffer is called. I have setup the
> voyager.h file to use the correct addresses.
Yes,
#define FB_PHYSICAL_ADDR 0xF8000000
#define REG_PHYSICAL_ADDR 0xFBE00000=20
should do the job (if the addresses are correct).
> Has anyone used the SM501 driver with this type of NON-Unified memory
> architecture? I am guessing this can be confusing to the driver since
> the=20
> frame buffer registers inside the SM501 need to be using offset ZERO
> instead=20
> of the 0xF8000000 like the MPC8280 sees.
I'm not sure, what you mean with NON-Unified memory. Note that the
TQM5200 uses the memory integrated in the SM501 as framebuffer. So
the SM501 is configured to use internal memory. If you want to use=20
external memory, you have to change the SM501 initialisation. Take
a look at the DRAM Control register of the SM501. Pin GPIO12 is
used during reset to enable or disable "Embedded Memory Control".
Please note, that the framebuffer driver does all register accesses
32-bit wide. Make sure your hardware supports this.
Maybe you have to change endianness (little/big).
Regards,
Martin
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Eddy Petrişor @ 2005-11-03 9:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1130999620.4680.28.camel@gaston>
On 11/3/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> For those who experience crashes on sleep and/or wakeup (typically due
> to USB) with 2.6.14, I made a test patch that might help. Please let me
> know if it makes things more reliable.
>
> http://gate.crashing.org/~benh/fix-ohci-sleep.diff
So this supposed to work with the USB sleep support enabled, right?
If this works then I will be very thankful!
I hope I have the time to test this patch this evening.
> Note that the patch is totally untested here so it may be just plain
> bogus :)
No problem.
AIUI, this should allow me to put my PB 5,2 to sleep while a usb stick
is mounted and come back from sleep with no problem and the stick to
be still mounted, right?
--
Regards,
EddyP
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
"Imagination is more important than knowledge" A.Einstein
^ permalink raw reply
* Re: SM501 Frame Buffer driver on PPC
From: Clemens Koller @ 2005-11-03 11:00 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <000901c5e017$91aef880$6405a8c0@absolut>
Hello, Russell,
> I am attempting to bring up a SM501 frame buffer driver on our PPC MPC8280
> board. Using the Denx Kernel 2.4.25 I see that most of this is already
> included in the kernel.
I am using the SM501 on PCI on Kernel 2.6 and updated several things in the
driver - not really the same contstruction area as you are working on.
But if you need some code, please let me know (off-list). I posted some things
in the past in this list and on fb-devel, too - just have a look.
The endianess on PCI on ppc is still an issue (I haven't investigated this
problem further during the last month).
I hope that I'll find some time to setup a webpage to publish that
stuff, soon...
Best regards,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: SM501 Frame Buffer driver on PPC
From: Mark Chambers @ 2005-11-03 14:05 UTC (permalink / raw)
To: Clemens Koller, Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <4369EDD3.1010309@anagramm.de>
> The endianess on PCI on ppc is still an issue (I haven't investigated this
> problem further during the last month).
>
There really shouldn't be an endian issue on SM501 since registers are
32 bit. What we do have is the 5200 that does byte swapping on PCI
for no good reason (IMHO)
--Mark Chambers
^ permalink raw reply
* RE: SM501 Frame Buffer driver on PPC
From: Martin Krause @ 2005-11-03 14:16 UTC (permalink / raw)
To: Mark Chambers, Clemens Koller, Absolut Hunter; +Cc: linuxppc-embedded
Mark Chambers wrote on Thursday, November 03, 2005 3:06 PM:=20
> > The endianess on PCI on ppc is still an issue (I haven't
> > investigated this problem further during the last month).
> >=20
>=20
> There really shouldn't be an endian issue on SM501 since registers are
> 32 bit. What we do have is the 5200 that does byte swapping on PCI
> for no good reason (IMHO)
We experienced a byte swapping issue on the SM501, too, although it
is connected via the local plus bus with the MPC5200 and not via PCI
bus.
In 16 bpp mode bytes appear to be swapped in a very ugly way.
Unfortunately we have no explanation for this, nor a real
workaround.
-- Martin Krause
^ permalink raw reply
* [PATCH] fs_enet build fix
From: Vitaly Bordug @ 2005-11-03 14:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
Due to the recent update of the platform code, some platform device
drivers fail to compile. This fix is for fs_enet, adding #include of a
new header, to which a number of platform stuff has been relocated.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: fs_enet_fix.patch --]
[-- Type: text/x-patch, Size: 1349 bytes --]
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -37,6 +37,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <linux/vmalloc.h>
#include <asm/pgtable.h>
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -34,6 +34,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <asm/immap_cpm2.h>
#include <asm/mpc8260.h>
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -34,6 +34,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -34,6 +34,7 @@
#include <linux/ethtool.h>
#include <linux/bitops.h>
#include <linux/fs.h>
+#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
^ permalink raw reply
* Re: Board Bringup problem with 2.6.13.4
From: Andrei Konovalov @ 2005-11-02 14:07 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: linuxppc-embedded
In-Reply-To: <43688AAD.5050208@comcast.net>
Your problem seems to be due to the CPU_213 errata:
ftp://ftp.xilinx.com/pub/documentation/misc/ppc405f6v5_2_0.pdf, page 22
Best regards,
Andrei
David H. Lynch Jr wrote:
> I am working through bringing up Linux 2.6.13.4 on a Xilinx V4 based
> ppc405.
> with memory from 0x0 through 0x7fffffff
>
>
>
> Right now I get:
>
> >Starting MonitorX.elf: V3.3.2.0.
> >
> >loaded at: 00400000 0047F13C
> >board data at: 0047D128 0047D13C
> >relocated to: 00405300 00405314
> >zimage at: 00405A95 0047CE71
> >avail ram: 00480000 08000000
> >
> >Linux/PPC load: console=ttyS0,9600 console=tty0 init=/linuxrc
> looptype=squashfs cdroot splash=silentttttt
> >Uncompressing Linux......done.
> >Now booting the kernel
>
> I have been able to trace execution into head_4xx.S to immediately
> before turn_on_mmu:
> But immediately after this I lose the ability to trace.
>
> I have been tracing things with a status port at 0x70000000 I can write
> to and read from the host side with code like
>
> lis r14,0x7000 /* debugging port */
> li r15,0x2305 /* value to output */
> stw r15,4(r14) eieio
>
> after turn_on_mmu executes this does not seem to work.
> looking at other code it appeared that I needed to add
> tophy(r14,r14) prior to the stw
> but that does not seem to help.
>
> What do I need to do to be able to continue to use my debug port ?
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH 2.6.14] ppc32: Allow for bigger compressed kernels
From: Tom Rini @ 2005-11-03 18:32 UTC (permalink / raw)
To: linuxppc-dev, Andrew Morton
The ppc (not ppc64) boot loader (zimage wrapper) has a hard coded limit of
4 MB on the size of an uncompressed kernel it can boot. The boot loader has
been changed to dynamically determine the largest possible kernel and
support it. Relocating the boot loader to a higher address (currently
located at 8 MB) will provide additional room.
Signed-off-by: Mark Bellon <mbellon@mvista.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
diff --git a/arch/ppc/boot/simple/misc.c b/arch/ppc/boot/simple/misc.c
--- a/arch/ppc/boot/simple/misc.c
+++ b/arch/ppc/boot/simple/misc.c
@@ -7,10 +7,10 @@
* your serial console. If a machine meets these requirements, it can quite
* likely use this code during boot.
*
- * Author: Matt Porter <mporter@mvista.com>
+ * Author: Tom Rini <trini@mvista.com>
* Derived from arch/ppc/boot/prep/misc.c
*
- * 2001 (c) MontaVista, Software, Inc. This file is licensed under
+ * 2001-2005 (c) MontaVista, Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
@@ -56,6 +56,11 @@
#define INTERACTIVE_CONSOLE 1
#endif
+#define ONE_MB (1 << 20)
+#define MAX_BI_RECS (8 * 1024)
+#define MAX_AVAIL_MEM (4 * ONE_MB)
+#define RAM_RESERVE (4 * ONE_MB)
+
char *avail_ram;
char *end_avail;
char *zimage_start;
@@ -97,7 +102,8 @@ decompress_kernel(unsigned long load_add
#endif
char *cp;
struct bi_record *rec;
- unsigned long initrd_loc = 0, TotalMemory = 0;
+ unsigned long initrd_loc, TotalMemory;
+ unsigned long max_kernel, top_free;
#if defined(CONFIG_SERIAL_8250_CONSOLE) || defined(CONFIG_SERIAL_MPSC_CONSOLE)
com_port = serial_init(0, NULL);
@@ -119,9 +125,6 @@ decompress_kernel(unsigned long load_add
*/
TotalMemory = get_mem_size();
- /* assume the chunk below 8M is free */
- end_avail = (char *)0x00800000;
-
/*
* Reveal where we were loaded at and where we
* were relocated to.
@@ -153,7 +156,6 @@ decompress_kernel(unsigned long load_add
* The zImage and initrd will be between start and _end, so they've
* already been moved once. We're good to go now. -- Tom
*/
- avail_ram = (char *)PAGE_ALIGN((unsigned long)_end);
puts("zimage at: "); puthex((unsigned long)zimage_start);
puts(" "); puthex((unsigned long)(zimage_size+zimage_start));
puts("\n");
@@ -164,11 +166,51 @@ decompress_kernel(unsigned long load_add
puts(" "); puthex((unsigned long)(&__ramdisk_end));puts("\n");
}
- avail_ram = (char *)0x00400000;
- end_avail = (char *)0x00800000;
+ /*
+ * If there is sufficent memory move the available RAM area after
+ * the zImage (but stay away from the top of RAM). Otherwise fudge
+ * it to fit in below the zImage as it did in the past.
+ */
+
+ top_free = _ALIGN((unsigned long)(_end) + ONE_MB - 1, ONE_MB);
+
+ if ((TotalMemory != 0) &&
+ ((top_free + MAX_AVAIL_MEM + RAM_RESERVE) < TotalMemory)) {
+ avail_ram = (char *) top_free;
+
+ /*
+ * We're linked in the middle of RAM and the kernel starts
+ * at zero. This means that the kernel must fit between
+ * zero and our starting address. Figure out the highest
+ * address below this that will allow a complete
+ * uncompressed kernel and bi_recs to fit - the maximum
+ * kernel size.
+ */
+
+ max_kernel = (unsigned long) &start;
+
+ while (1) {
+ avail_ram = (char *) bootinfo_addr(max_kernel);
+
+ if ((avail_ram + MAX_BI_RECS) < ((char *) &start))
+ break;
+
+ max_kernel -= MAX_BI_RECS;
+ }
+ }
+ else {
+ max_kernel = ((unsigned long) &start) - MAX_AVAIL_MEM;
+ avail_ram = max_kernel;
+ }
+
+ end_avail = avail_ram + MAX_AVAIL_MEM;
+
puts("avail ram: "); puthex((unsigned long)avail_ram); puts(" ");
puthex((unsigned long)end_avail); puts("\n");
+ /* Document the limitation */
+ puts("max kernel: "); puthex(max_kernel); puts("\n");
+
if (keyb_present)
CRT_tstc(); /* Forces keyboard to be initialized */
#ifdef CONFIG_GEMINI
@@ -222,32 +264,12 @@ decompress_kernel(unsigned long load_add
puts("\n");
puts("Uncompressing Linux...");
- gunzip(NULL, 0x400000, zimage_start, &zimage_size);
+ gunzip(NULL, max_kernel, zimage_start, &zimage_size);
puts("done.\n");
/* get the bi_rec address */
rec = bootinfo_addr(zimage_size);
- /* We need to make sure that the initrd and bi_recs do not
- * overlap. */
- if ( initrd_size ) {
- unsigned long rec_loc = (unsigned long) rec;
- initrd_loc = (unsigned long)(&__ramdisk_begin);
- /* If the bi_recs are in the middle of the current
- * initrd, move the initrd to the next MB
- * boundary. */
- if ((rec_loc > initrd_loc) &&
- ((initrd_loc + initrd_size) > rec_loc)) {
- initrd_loc = _ALIGN((unsigned long)(zimage_size)
- + (2 << 20) - 1, (2 << 20));
- memmove((void *)initrd_loc, &__ramdisk_begin,
- initrd_size);
- puts("initrd moved: "); puthex(initrd_loc);
- puts(" "); puthex(initrd_loc + initrd_size);
- puts("\n");
- }
- }
-
bootinfo_init(rec);
if ( TotalMemory )
bootinfo_append(BI_MEMSIZE, sizeof(int), (void*)&TotalMemory);
@@ -258,7 +280,7 @@ decompress_kernel(unsigned long load_add
if (initrd_size) {
unsigned long initrd[2];
- initrd[0] = initrd_loc;
+ initrd[0] = (unsigned long)(&__ramdisk_begin);
initrd[1] = initrd_size;
bootinfo_append(BI_INITRD, sizeof(initrd), &initrd);
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH] ppc32: Put CPM1 config option
From: Pantelis Antoniou @ 2005-11-03 18:39 UTC (permalink / raw)
To: akpm; +Cc: Kumar, Dan Malek, Gala, linuxppc-embedded, Jeff Garzik
Kconfig patch needed by fs_enet to work.
Works like CONFIG_CPM2.
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -746,7 +746,17 @@ config MPC834x
bool
default y if MPC834x_SYS
+config CPM1
+ bool
+ depends on 8xx
+ default y
+ help
+ The CPM1 (Communications Processor Module) is a coprocessor on
+ embedded CPUs made by Motorola. Selecting this option means that
+ you wish to build a kernel for a machine with a CPM1 coprocessor
+ on it (8xx, 827x, 8560).
+
config CPM2
bool
depends on 8260 || MPC8560 || MPC8555
config PPC_GEN550
^ permalink raw reply
* Re: [PATCH] ppc32: Fix SCC Uart write problem after 2. open()
From: Heiko Schocher @ 2005-11-03 18:37 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <e192e9e7fa764d69dc8e4f4d4391a447@embeddededge.com>
Hello,
On Wed Nov 2 03:08:30 EST 2005 Dan Malek wrote:
>> The following Patch will fix this problem.
> This patch just covers up a driver bug, find and fix the real bug.
i think i found it.
Please have a look at the following patch against current Linux 2.6
tree.
thanks
Heiko Schocher
[PATCH] ppc32: update fix: SCC write after 2nd open().
we never reinitialize the buffer descriptor or the
SCC.
Signed-off-by: Heiko Schocher <hs@denx.de>
---
drivers/serial/cpm_uart/cpm_uart_core.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 25825f2..e03369c 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -163,7 +163,6 @@ static void cpm_uart_start_tx(struct uar
smcp->smc_smcmr |= SMCMR_TEN;
} else {
sccp->scc_sccm |= UART_SCCM_TX;
- pinfo->sccp->scc_gsmrl |= SCC_GSMRL_ENT;
}
}
}
@@ -397,7 +396,7 @@ static int cpm_uart_startup(struct uart_
}
if (!(pinfo->flags & FLAG_CONSOLE))
- cpm_line_cr_cmd(line,CPM_CR_INIT_TRX);
+ cpm_line_cr_cmd(line,CPM_CR_RESTART_TX);
return 0;
}
@@ -442,9 +441,8 @@ static void cpm_uart_shutdown(struct uar
sccp->scc_sccm &= ~(UART_SCCM_TX | UART_SCCM_RX);
}
- /* Shut them really down and reinit buffer descriptors */
+ /* Shut them really down */
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
- cpm_uart_initbd(pinfo);
}
}
^ permalink raw reply related
* [PATCH] POWERPC/PPC64: Fix CONFIG_SMP=n build for ppc64
From: Olof Johansson @ 2005-11-03 19:49 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev; +Cc: akpm
Hi,
Below is against 2.6.14-git5:
---
Two CONFIG_SMP=n build fixes due to missing <asm/smp.h> includes.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6/arch/ppc64/kernel/sysfs.c
===================================================================
--- 2.6.orig/arch/ppc64/kernel/sysfs.c 2005-11-03 10:33:42.000000000 -0800
+++ 2.6/arch/ppc64/kernel/sysfs.c 2005-11-03 10:33:51.000000000 -0800
@@ -20,6 +20,7 @@
#include <asm/paca.h>
#include <asm/lppaca.h>
#include <asm/machdep.h>
+#include <asm/smp.h>
static DEFINE_PER_CPU(struct cpu, cpu_devices);
Index: 2.6/arch/powerpc/kernel/time.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/time.c 2005-11-03 10:45:43.000000000 -0800
+++ 2.6/arch/powerpc/kernel/time.c 2005-11-03 10:49:52.000000000 -0800
@@ -69,6 +69,7 @@
#include <asm/iSeries/ItLpQueue.h>
#include <asm/iSeries/HvCallXm.h>
#endif
+#include <asm/smp.h>
/* keep track of when we need to update the rtc */
time_t last_rtc_update;
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-03 21:21 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <60381eeb0511030103w551fad25h3d9d7fa258764d5e@mail.gmail.com>
> So this supposed to work with the USB sleep support enabled, right?
> If this works then I will be very thankful!
> I hope I have the time to test this patch this evening.
>
> > Note that the patch is totally untested here so it may be just plain
> > bogus :)
>
> No problem.
>
> AIUI, this should allow me to put my PB 5,2 to sleep while a usb stick
> is mounted and come back from sleep with no problem and the stick to
> be still mounted, right?
Heh, in _theory_ :) The first aim of the patch is to remove the crash on
sleep/wakeup in 2.6.14. If it doesn't blow up, that's already a good
first step :) Wether suspend with your USB stick works is a different
matter, mostly due to the USB stack itself.
Ben.
^ permalink raw reply
* problem with mpc823e i2c!!!!
From: x65485830 @ 2005-11-04 0:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]
Hi,
Sorry for bothering you again - I will appreciate your opinion advise guidance.
I'm trying to use the MPC I2C controller to generate I2C transactions,I use linux kernel,which config is CONFIG_UCODE_PATCH=y,CONFIG_I2C=y,CONFIG_I2C_ALGO8XX=y,CONFIG_I2C_CHARDEV=y,CONFIG_I2C_PROC=y.
I use XPC823EZT75B2 cpu,but when I start up the board,I found I2c driver huang the cpu.
What is your interpretation of entries I found in the log buf with regards to I2C driver ?
which is sleep,I2c can't tranimit,which can not interrupte.That is why?
Best thanks to you!
## Booting image at 00200000 ...
Image Name: Linux-2.4.18_tx200-1.0-SIDTEC
Created: 2005-10-31 2:57:21 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 707422 Bytes = 690.8 kB
Load Address: 00000000
Entry Point: 00000000
Uncompressing Kernel Image ... OK
Linux version 2.4.18_tx200-1.0-SIDTEC (root@freepass) (gcc version 3.2.1 2002095I2C/SPI uCode patch installed
rpxfb: allocated 118 pages for frame buffer
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=tty0 console=ttyS0,9600 root=/dev/nfs rw nfsroot=11
Decrementer Frequency = 240000000/60
Console: colour dummy device 80x25
Calibrating delay loop... 63.69 BogoMIPS
Memory: 126816k available (1236k kernel code, 400k data, 76k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Disabling the Out Of Memory Killer
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communication.
i2c-core.o: i2c core module version 2.6.2 (20011118)
i2c-dev.o: i2c /dev entries driver module version 2.6.2 (20011118)
i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.2 (20011118)
i2c-rpx.o: i2c MPC8xx module version 2.6.2 (20011118)
i2c-algo-8xx.o: hw routines for m8xx registered.
cpm_iic_init() - iip=fa202400
cpm_iic_init[125] Install ISR for IRQ 16
i2c-algo-8xx.o: scanning bus m8xx...
iip fa202400, dp_addr 0x810
iic_tbase 2064, r_tbase 2064
[-- Attachment #2: Type: text/html, Size: 2995 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.14] ppc32: Allow for bigger compressed kernels
From: Olof Johansson @ 2005-11-04 4:25 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20051103183256.GJ3839@smtp.west.cox.net>
On Thu, Nov 03, 2005 at 11:32:56AM -0700, Tom Rini wrote:
> --- a/arch/ppc/boot/simple/misc.c
> +++ b/arch/ppc/boot/simple/misc.c
> @@ -7,10 +7,10 @@
> * your serial console. If a machine meets these requirements, it can quite
> * likely use this code during boot.
> *
> - * Author: Matt Porter <mporter@mvista.com>
> + * Author: Tom Rini <trini@mvista.com>
> * Derived from arch/ppc/boot/prep/misc.c
I understand adding authors to a file when code is added, but why should
author credit be removed?
-Olof
^ 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