* Re: [PATCH dtc] Add -o <output file> to the usage message.
From: Jon Loeliger @ 2007-04-19 22:28 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev
In-Reply-To: <20070414221647.GB23870@dellserver.lan>
So, like, the other day Jerry Van Baren mumbled:
>
> Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
> ---
>
> It turns out -o <file> was there all along, just not in the usage. :-)
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: Kernel crash on mem= argument
From: Frank D Lombardo @ 2007-04-19 22:23 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA2409529328770@bluefin.Soneticom.local>
Clint Thomas wrote:
> My u-boot config does not currently have a CONFIG_PRAM variable defined.
> Is doing this as easy as dropping in a #define in my board config? Or do
> I need to address this in another part of the code? Up until now, I just
> assumed that if I passed mem=200M to the kernel, it would allocate as
> necessary, then I could use the remaining RAM as I saw fit, but since
> this is not working I need to deal with it appropriately.
>
> Clint
>
> -----Original Message-----
> From: Frank D Lombardo [mailto:lombardo@mdivac.com]
> Sent: Thursday, April 19, 2007 2:39 PM
> To: Clint Thomas
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Kernel crash on mem= argument
>
> Clint Thomas wrote:
>
Clint,
I believe whats happening is that u-boot is loading the initrd in the
region of RAM above 200M. Then you pass mem=200M to the kernel, and it
can't access the initrd. By adding the appropriate CONFIG_PRAM define
to your board config file, you let u-boot know not to use the memory
above 200M either. That way u-boot will load the initrd in memory that
is usable by the kernel.
Frank
^ permalink raw reply
* ramdisk - how does the initial programs execute
From: Siva Prasad @ 2007-04-19 21:58 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
Hi,
I am interested in knowing how the initial programs like "/init" works
when using the ramdisk (or any other file system for that matter).
Especially, when it starts do execve for an init program, I am more
interested in how the bss_start and bss_end is identified, and more
importantly how __clear_user with addresses in range of 0x0FFXXXXX work,
even when all the memory is mapped at 0xC0000000. Shouldn't __clear_user
throw an exception, as there is no BAT that can identify the effective
address it is trying to clear?
* How does stwu instruction (of __clear_user) successfully stores 0x0
into that address.
* Since it is a user level program, how come its address falls into
0x0FFXXXXX?. Should it be loaded dynamically at any address that is
given by kernel (> 0xC0000000)?
Thanks
Siva
^ permalink raw reply
* Re: [RFC/PATCH] Change 440GP platform to ppc440
From: Josh Boyer @ 2007-04-19 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0704191615040.25069@localhost.localdomain>
On Thu, 2007-04-19 at 16:16 -0500, Kumar Gala wrote:
> I don't see any reason the 440GP should its own platform. Posting this to
> see if anyone thinks otherwise.
Seems fine to me.
josh
^ permalink raw reply
* [RFC/PATCH] Change 440GP platform to ppc440
From: Kumar Gala @ 2007-04-19 21:16 UTC (permalink / raw)
To: linuxppc-dev
I don't see any reason the 440GP should its own platform. Posting this to
see if anyone thinks otherwise.
- k
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 6b59e40..4237aea 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1119,7 +1119,7 @@ static struct cpu_spec cpu_specs[] = {
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
- .platform = "ppc440gp",
+ .platform = "ppc440",
},
{ /* 440GP Rev. C */
.pvr_mask = 0xf0000fff,
@@ -1129,7 +1129,7 @@ static struct cpu_spec cpu_specs[] = {
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
- .platform = "ppc440gp",
+ .platform = "ppc440",
},
{ /* 440GX Rev. A */
.pvr_mask = 0xf0000fff,
^ permalink raw reply related
* RE: Kernel crash on mem= argument
From: Clint Thomas @ 2007-04-19 20:06 UTC (permalink / raw)
To: Frank D Lombardo; +Cc: linuxppc-embedded
In-Reply-To: <4627B757.4030905@mdivac.com>
My u-boot config does not currently have a CONFIG_PRAM variable defined.
Is doing this as easy as dropping in a #define in my board config? Or do
I need to address this in another part of the code? Up until now, I just
assumed that if I passed mem=3D200M to the kernel, it would allocate as
necessary, then I could use the remaining RAM as I saw fit, but since
this is not working I need to deal with it appropriately.
Clint
-----Original Message-----
From: Frank D Lombardo [mailto:lombardo@mdivac.com]=20
Sent: Thursday, April 19, 2007 2:39 PM
To: Clint Thomas
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Kernel crash on mem=3D argument
Clint Thomas wrote:
> So, I am able to get my system to autoboot with a ramdisk out of flash
> if I leave the mem=3D argument out of my u-boot bootargs, however =
since=20
> I need to define the range of real memory for my kernel to address,=20
> leaving that argument out is not an option for me.
>
> When I add it in, this is the error I get.
>
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 3938k freed
> Oops: kernel access of bad area, sig: 11
> NIP: C002EB90 XER: 20000000 LR: C0030120 SP: C0419DB0 REGS: c0419d00
> TRAP: 0800 Not tainted
> MSR: 00009000 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
> DEAR: 8048486C, ESR: 00800000
> TASK =3D c0418000[1] 'swapper' Last syscall: 6 last math 00000000 last =
> altivec 00000000 last spe 00000000
> GPR00: 00000000 C0419DB0 C0418000 C0584820 FFFFFFFF 00000001 C058483C=20
> 00000080
> GPR08: C0584838 80484868 C0291000 C0584808 00000000 00000000 10001000=20
> 00000000
> GPR16: 00000001 00000001 FFFFFFFF 007FFF00 00009002 C0419EA0 00000000=20
> C0003DEC
> GPR24: C0003B40 007FFEB0 00000000 C0240000 C0240000 CFFAEB6B C0584820=20
> CFBD7000 Call backtrace:
> 00000000 C0030120 C000D94C C00F86E0 C003A388 C0038D24 C0003B9C=20
> C020019C C0001E98 C0001ACC C00064B8 Kernel panic: Attempted to kill=20
> init!
> <0>Rebooting in 180 seconds..
> =20
> Suddenly, the kernel goes from finding, mounting and loading it's=20
> ramdisk RFS, to not being able to find it at all. I have not moved the
> ramdisk in flash, so i'm unsure why adding a mem=3D argument on the=20
> kernel bootargs would do this. Any ideas?
>
>
> Clinton Thomas
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> =20
Make sure that u-boot does not load the initrd in the space above the
limit set with the mem variable. See the u-boot README description of
CONFIG_PRAM. That should help.
Frank
^ permalink raw reply
* Re: [PATCH 10/10] zImage wrapper for Ebony
From: Mark A. Greer @ 2007-04-19 20:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070418063626.E6AADDDE3B@ozlabs.org>
On Wed, Apr 18, 2007 at 04:36:26PM +1000, David Gibson wrote:
> This patch adds support for building a zImage wrapper suitable for the
> Ebony (440GP) evaluation board. This supports booting both from uboot
> (old versions which don't supply a flattened device tree) and IBM
> Openbios (aka "treeboot").
<snip>
> Index: working-2.6/arch/powerpc/boot/Makefile
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/Makefile 2007-04-18 14:42:52.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/Makefile 2007-04-18 14:43:14.000000000 +1000
<snip>
> @@ -159,6 +168,21 @@ $(obj)/zImage.ps3: vmlinux
> $(obj)/zImage.initrd.ps3: vmlinux
> @echo " WARNING zImage.initrd.ps3 not supported (yet)"
>
> +$(obj)/zImage.ebony-elf: vmlinux $(wrapperbits) $(obj)/ebony.dtb
> + $(call if_changed,wrap,ebony,,$(obj)/ebony.dtb)
> +
> +$(obj)/zImage.initrd.ebony-elf: vmlinux $(wrapperbits) $(obj)/ebony.dtb $(obj)/ramdisk.image.gz
> + $(call if_changed,wrap,ebony,,$(obj)/ebony.dtb,$(obj)/ramdisk.img.gz)
> +
> +$(obj)/zImage.ebony: vmlinux $(wrapperbits) $(obj)/ebony.dtb $(obj)/mktree
> + $(call if_changed,wrap,ebony-tree,,$(obj)/ebony.dtb)
> +
> +$(obj)/zImage.initrd.ebony: vmlinux $(wrapperbits) $(obj)/ebony.dtb $(obj)/mktree
> + $(call if_changed,wrap,ebony-tree,,$(obj)/ebony.dtb,$(obj)/ramdisk.img.gz)
> +
> +$(obj)/uImage.ebony: vmlinux $(wrapperbits) $(obj)/ebony.dtb
> + $(call if_changed,wrap,ebony-uboot,,$(obj)/ebony.dtb)
> +
> $(obj)/uImage: vmlinux $(wrapperbits)
> $(call if_changed,wrap,uboot)
Hi David,
It would be better to write generic rules for dtb sort of thing like
what Milton did (and what I did in "[PATCH] powerpc: Add Makefile rule
to wrap dts file in zImage")? It'll keep our Makefile much cleaner
over the long run.
Mark
^ permalink raw reply
* [PATCH] Don't shutdown TX on mpc5200 serial port if it is a console
From: Grant Likely @ 2007-04-19 19:42 UTC (permalink / raw)
To: linuxppc-dev, linux-serial, Sylvain Munaut, Wolfgang Denk,
Bartlomiej Sieka
If the serial port gets shut down, then console output stalls. 9 out
of 10 kernel hackers agree, this is a bad thing.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Wolfgang, please verify this new patch. Sylvain rightly pointed out that
RX and interrupts should be turned off regardless. If it works for you,
please reply with a Signed-of-by line.
Thanks,
g.
drivers/serial/mpc52xx_uart.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index f8c1761..35f8b86 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -257,9 +257,10 @@ mpc52xx_uart_shutdown(struct uart_port *port)
{
struct mpc52xx_psc __iomem *psc = PSC(port);
- /* Shut down the port, interrupt and all */
+ /* Shut down the port. Leave TX active if on a console port */
out_8(&psc->command,MPC52xx_PSC_RST_RX);
- out_8(&psc->command,MPC52xx_PSC_RST_TX);
+ if (!uart_console(port))
+ out_8(&psc->command,MPC52xx_PSC_RST_TX);
port->read_status_mask = 0;
out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
--
1.5.1
^ permalink raw reply related
* Re: [U-Boot-Users] [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
From: Jon Loeliger @ 2007-04-19 19:03 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger, u-boot-users
In-Reply-To: <4627B9C7.8010800@smiths-aerospace.com>
On Thu, 2007-04-19 at 13:49, Jerry Van Baren wrote:
> >
> > Sorry. I've been out sick for a couple days here and am
> > just now catching up. I've read through the last week's
> > worth of mail here now, so let me see if I have properly
> > summarized where things stand and what's needed for the DTC:
> >
> > These patches need to be applied:
> >
> > [PATCH dtc] Add -o <output file> to the usage message.
> > Sat, 14 Apr 2007 18:16:47 -0400
> >
> > [PATCH dtc take 3] Fix reserve map output for asm format.
> > Tue, 17 Apr 2007 18:14:41 -0400
> >
> > [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
> > Wed, 18 Apr 2007 21:59:51 -0400
> >
> > The last patch there replaces the "Improve -S handling" patches.
> > But does the last patch replace or depend on the second one?
> >
> > And I agree with David that last patch is a better approach.
> >
> > Thanks,
> > jdl
>
> Yes, you have that right.
Good. The drugs aren't too strong yet. :-)
> Patch #1 is good to go
> [PATCH dtc] Add -o <output file> to the usage message.
> Sat, 14 Apr 2007 18:16:47 -0400
>
> Patch #2 and #3...
> [PATCH dtc take 3] Fix reserve map output for asm format.
> Tue, 17 Apr 2007 18:14:41 -0400
> [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
> Wed, 18 Apr 2007 21:59:51 -0400
>
> ...you force me to make a confession.
It's good for the soul. :-)
> Your option:
> 1) Take the last two patches as is and remove the fprintf yourself
> 2) I'll fix it tonight and provide a New Improved patch
I'll go with Door Number 1! No problem.
Thanks,
jdl
^ permalink raw reply
* Re: Kernel crash on mem= argument
From: Frank D Lombardo @ 2007-04-19 18:39 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA2409529328755@bluefin.Soneticom.local>
Clint Thomas wrote:
> So, I am able to get my system to autoboot with a ramdisk out of flash
> if I leave the mem= argument out of my u-boot bootargs, however since I
> need to define the range of real memory for my kernel to address,
> leaving that argument out is not an option for me.
>
> When I add it in, this is the error I get.
>
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 3938k freed
> Oops: kernel access of bad area, sig: 11
> NIP: C002EB90 XER: 20000000 LR: C0030120 SP: C0419DB0 REGS: c0419d00
> TRAP: 0800 Not tainted
> MSR: 00009000 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
> DEAR: 8048486C, ESR: 00800000
> TASK = c0418000[1] 'swapper' Last syscall: 6
> last math 00000000 last altivec 00000000 last spe 00000000
> GPR00: 00000000 C0419DB0 C0418000 C0584820 FFFFFFFF 00000001 C058483C
> 00000080
> GPR08: C0584838 80484868 C0291000 C0584808 00000000 00000000 10001000
> 00000000
> GPR16: 00000001 00000001 FFFFFFFF 007FFF00 00009002 C0419EA0 00000000
> C0003DEC
> GPR24: C0003B40 007FFEB0 00000000 C0240000 C0240000 CFFAEB6B C0584820
> CFBD7000
> Call backtrace:
> 00000000 C0030120 C000D94C C00F86E0 C003A388 C0038D24 C0003B9C
> C020019C C0001E98 C0001ACC C00064B8
> Kernel panic: Attempted to kill init!
> <0>Rebooting in 180 seconds..
>
> Suddenly, the kernel goes from finding, mounting and loading it's
> ramdisk RFS, to not being able to find it at all. I have not moved the
> ramdisk in flash, so i'm unsure why adding a mem= argument on the kernel
> bootargs would do this. Any ideas?
>
>
> Clinton Thomas
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Make sure that u-boot does not load the initrd in the space above the
limit set with the mem variable. See the u-boot README description of
CONFIG_PRAM. That should help.
Frank
^ permalink raw reply
* Re: [U-Boot-Users] [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
From: Jerry Van Baren @ 2007-04-19 18:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger, u-boot-users
In-Reply-To: <1177007241.14328.21.camel@ld0161-tx32>
Jon Loeliger wrote:
> On Wed, 2007-04-18 at 20:59, Jerry Van Baren wrote:
>> This makes padding out the blob if the user requested extra size much
>> easer. The assembly and writing to the file is more straight forward too.
>>
>> Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
>> ---
>>
>> Hi David, Jon,
>>
>> I wasn't happy with David's suggestion on the -S handling. I also wasn't
>> all that wild about how the blob was assembled and then written to the
>> file piecemeal with "ad-hoc" alignment padding. I realized I could fix
>> both by assembling the blob in memory as a "struct data" and then write
>> the whole thing out in one fell swoop.
>>
>> Makes it a lot simpler and cleaner to my eyes.
>>
>> Hope y'all agree,
>> gvb
>
> Jerry and David,
>
> Sorry. I've been out sick for a couple days here and am
> just now catching up. I've read through the last week's
> worth of mail here now, so let me see if I have properly
> summarized where things stand and what's needed for the DTC:
>
> These patches need to be applied:
>
> [PATCH dtc] Add -o <output file> to the usage message.
> Sat, 14 Apr 2007 18:16:47 -0400
>
> [PATCH dtc take 3] Fix reserve map output for asm format.
> Tue, 17 Apr 2007 18:14:41 -0400
>
> [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
> Wed, 18 Apr 2007 21:59:51 -0400
>
> The last patch there replaces the "Improve -S handling" patches.
> But does the last patch replace or depend on the second one?
>
> And I agree with David that last patch is a better approach.
>
> Thanks,
> jdl
Yes, you have that right.
Patch #1 is good to go
[PATCH dtc] Add -o <output file> to the usage message.
Sat, 14 Apr 2007 18:16:47 -0400
Patch #2 and #3...
[PATCH dtc take 3] Fix reserve map output for asm format.
Tue, 17 Apr 2007 18:14:41 -0400
[PATCH: dtc take 2] Assemble the blob in memory before writing it out.
Wed, 18 Apr 2007 21:59:51 -0400
...you force me to make a confession. The third patch depends on the
second patch because I snuck in a fix to the ASM output into the third
patch: the last two chunks fix the ASM header output - I padded the blob
out but didn't change the size properly in the header. In the third
patch above, I added a label "%s_blob_abs_end" and used that to
calculate the total blob size (including the padding) in the header:
- fprintf(f, "\t.long\t_%s_blob_end - _%s_blob_start /* totalsize */\n",
+ fprintf(f, "\t.long\t_%s_blob_abs_end - _%s_blob_start /* totalsize */\n",
--------
AAAARGH! Sorry, I see I left a debug statement in flattree.c around
line 390:
@@ -383,28 +370,46 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int
version,
:
:
+fprintf(stderr, "minsize = %d, totalsize = %d, padlen = %d\n", minsize,
be32_to_cpu(bph.totalsize), padlen);
Your option:
1) Take the last two patches as is and remove the fprintf yourself
2) I'll fix it tonight and provide a New Improved patch
Thanks,
gvb
^ permalink raw reply
* Re: [PATCH] Don't shutdown mpc5200 serial port if it is a console
From: Sylvain Munaut @ 2007-04-19 18:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <11770061133776-git-send-email-grant.likely@secretlab.ca>
The idea is OK,
but only TX should be left active and the interrupts should still be
disabled (imr set to 0), so we don't generate unhandled interrupts ...
Sylvain
Grant Likely wrote:
> If the serial port gets shut down, then console output stalls. 9 out
> of 10 kernel hackers agree, this is a bad thing.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Bartlomiej Sieka <tur@semihalf.com>
> ---
>
> This is a simple bug fix, but it's not a critical one. It would be really
> nice to get this merged for 2.6.21
> drivers/serial/mpc52xx_uart.c | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index f8c1761..35669f8 100644
> --- a/drivers/serial/mpc52xx_uart.c
> +++ b/drivers/serial/mpc52xx_uart.c
> @@ -257,14 +257,16 @@ mpc52xx_uart_shutdown(struct uart_port *port)
> {
> struct mpc52xx_psc __iomem *psc = PSC(port);
>
> - /* Shut down the port, interrupt and all */
> - out_8(&psc->command,MPC52xx_PSC_RST_RX);
> - out_8(&psc->command,MPC52xx_PSC_RST_TX);
> + /* We don't want to shut down a port that is used as a console */
> + if (!uart_console(port)) {
> + out_8(&psc->command,MPC52xx_PSC_RST_RX);
> + out_8(&psc->command,MPC52xx_PSC_RST_TX);
>
> - port->read_status_mask = 0;
> - out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
> + port->read_status_mask = 0;
> + out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
> + }
>
> - /* Release interrupt */
> + /* Release interrupt (OK for console port b/c console uses polling) */
> free_irq(port->irq, port);
> }
>
>
^ permalink raw reply
* [PATCH] Don't shutdown mpc5200 serial port if it is a console
From: Grant Likely @ 2007-04-19 18:08 UTC (permalink / raw)
To: linuxppc-dev, linux-serial, Sylvain Munaut, Wolfgang Denk
If the serial port gets shut down, then console output stalls. 9 out
of 10 kernel hackers agree, this is a bad thing.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Bartlomiej Sieka <tur@semihalf.com>
---
This is a simple bug fix, but it's not a critical one. It would be really
nice to get this merged for 2.6.21
drivers/serial/mpc52xx_uart.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index f8c1761..35669f8 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -257,14 +257,16 @@ mpc52xx_uart_shutdown(struct uart_port *port)
{
struct mpc52xx_psc __iomem *psc = PSC(port);
- /* Shut down the port, interrupt and all */
- out_8(&psc->command,MPC52xx_PSC_RST_RX);
- out_8(&psc->command,MPC52xx_PSC_RST_TX);
+ /* We don't want to shut down a port that is used as a console */
+ if (!uart_console(port)) {
+ out_8(&psc->command,MPC52xx_PSC_RST_RX);
+ out_8(&psc->command,MPC52xx_PSC_RST_TX);
- port->read_status_mask = 0;
- out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
+ port->read_status_mask = 0;
+ out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
+ }
- /* Release interrupt */
+ /* Release interrupt (OK for console port b/c console uses polling) */
free_irq(port->irq, port);
}
--
1.5.1
^ permalink raw reply related
* Kernel crash on mem= argument
From: Clint Thomas @ 2007-04-19 18:29 UTC (permalink / raw)
To: linuxppc-embedded
So, I am able to get my system to autoboot with a ramdisk out of flash
if I leave the mem=3D argument out of my u-boot bootargs, however since =
I
need to define the range of real memory for my kernel to address,
leaving that argument out is not an option for me.=20
When I add it in, this is the error I get.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 3938k freed
Oops: kernel access of bad area, sig: 11
NIP: C002EB90 XER: 20000000 LR: C0030120 SP: C0419DB0 REGS: c0419d00
TRAP: 0800 Not tainted
MSR: 00009000 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
DEAR: 8048486C, ESR: 00800000
TASK =3D c0418000[1] 'swapper' Last syscall: 6
last math 00000000 last altivec 00000000 last spe 00000000
GPR00: 00000000 C0419DB0 C0418000 C0584820 FFFFFFFF 00000001 C058483C
00000080
GPR08: C0584838 80484868 C0291000 C0584808 00000000 00000000 10001000
00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 00009002 C0419EA0 00000000
C0003DEC
GPR24: C0003B40 007FFEB0 00000000 C0240000 C0240000 CFFAEB6B C0584820
CFBD7000
Call backtrace:
00000000 C0030120 C000D94C C00F86E0 C003A388 C0038D24 C0003B9C
C020019C C0001E98 C0001ACC C00064B8
Kernel panic: Attempted to kill init!
<0>Rebooting in 180 seconds..
=20
Suddenly, the kernel goes from finding, mounting and loading it's
ramdisk RFS, to not being able to find it at all. I have not moved the
ramdisk in flash, so i'm unsure why adding a mem=3D argument on the =
kernel
bootargs would do this. Any ideas?
Clinton Thomas
^ permalink raw reply
* Re: [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
From: Jon Loeliger @ 2007-04-19 18:27 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger, u-boot-users
In-Reply-To: <20070419015951.GA9339@dellserver.lan>
On Wed, 2007-04-18 at 20:59, Jerry Van Baren wrote:
> This makes padding out the blob if the user requested extra size much
> easer. The assembly and writing to the file is more straight forward too.
>
> Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
> ---
>
> Hi David, Jon,
>
> I wasn't happy with David's suggestion on the -S handling. I also wasn't
> all that wild about how the blob was assembled and then written to the
> file piecemeal with "ad-hoc" alignment padding. I realized I could fix
> both by assembling the blob in memory as a "struct data" and then write
> the whole thing out in one fell swoop.
>
> Makes it a lot simpler and cleaner to my eyes.
>
> Hope y'all agree,
> gvb
Jerry and David,
Sorry. I've been out sick for a couple days here and am
just now catching up. I've read through the last week's
worth of mail here now, so let me see if I have properly
summarized where things stand and what's needed for the DTC:
These patches need to be applied:
[PATCH dtc] Add -o <output file> to the usage message.
Sat, 14 Apr 2007 18:16:47 -0400
[PATCH dtc take 3] Fix reserve map output for asm format.
Tue, 17 Apr 2007 18:14:41 -0400
[PATCH: dtc take 2] Assemble the blob in memory before writing it out.
Wed, 18 Apr 2007 21:59:51 -0400
The last patch there replaces the "Improve -S handling" patches.
But does the last patch replace or depend on the second one?
And I agree with David that last patch is a better approach.
Thanks,
jdl
^ permalink raw reply
* [RFC] add 8-bit bus support to the Xilinx SystemACE device driver + minor clean-ups
From: Andrei Konovalov @ 2007-04-19 18:32 UTC (permalink / raw)
To: Grant Likely
Cc: Peter Korsgaard, Andrei Konovalov, Stefan Roese, Rick Moleres,
linuxppc-embedded
In-Reply-To: <1176600194262-git-send-email-grant.likely@secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]
Hello,
The attached patch should be applied on top of the SystemACE device
driver patch by Grant.
Here is the list of changes:
1) 8-bit bus support added to the driver.
SystemACE chip could be connected to the FPGA by 8-bit or
16-bit data bus.
ML403 uses the 16-bit connection, while ML300 - the 8-bit one.
2) In the original driver the data bus width and endiannes has
been hard-coded with "#if 1" etc statements.
I've tried to bind this selection to the board the kernel is built
for: the bus width is defined by the board design, am I right?
Please let me know if this concept is correct.
3) Added "do {" "} while(0)" brackets to the macros that need them.
Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
I've done some testing for the Grant's driver with this patch applied.
Both ML403 and ML300 booted OK with rootfs on CF card and the microdrive
respectively. ML403 survived "bonnie++ -f -u root -x 5 -r 8 -s 16" test
(it took 15 minutes to complete), and I wouldn't like to repeat this
test because of the risk to kill the CF card. ML300 oopsed during
the 3d pass of "bonnie++ -f -u root -x 5 -r 10 -s 20"
(kernel access of bad area, sig: 11). Haven't dig into this yet.
Thanks,
Andrei
Grant Likely wrote:
> Add support for block device access to the Xilinx SystemACE Compact
> flash interface
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> I think this driver is in pretty good shape. I've got a few things to
> clean up a bit. Specifically, I'm still working on error handling and
> making sure that the state machine is sane at all times.
>
> I would appreciate any review/comments. One area where I am undecided is
> the format of the state machine. The current code uses one big function
> with a large switch() statment for each state. I'm considering breaking
> this up into a seperate function for each state, and adding a static
> state table with pointers to each state function.
>
> I feel this driver is pretty close to done, and I'd like to get it into
> mainline for the 2.6.22 timeframe.
>
> Cheers,
> g.
>
> drivers/block/Kconfig | 6 +
> drivers/block/Makefile | 1 +
> drivers/block/xsysace.c | 1070 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1077 insertions(+), 0 deletions(-)
[-- Attachment #2: add-8bit-support-for-systemace.patch --]
[-- Type: text/x-patch, Size: 4155 bytes --]
Index: linux-2.6.20/arch/ppc/platforms/4xx/Kconfig
===================================================================
--- linux-2.6.20.orig/arch/ppc/platforms/4xx/Kconfig
+++ linux-2.6.20/arch/ppc/platforms/4xx/Kconfig
@@ -55,12 +55,14 @@ config WALNUT
config XILINX_ML300
bool "Xilinx-ML300"
select XILINX_VIRTEX_II_PRO
+ select XSYSACE_8BIT
help
This option enables support for the Xilinx ML300 evaluation board.
config XILINX_ML403
bool "Xilinx-ML403"
select XILINX_VIRTEX_4_FX
+ select XSYSACE_16BIT_LE
help
This option enables support for the Xilinx ML403 evaluation board.
endchoice
Index: linux-2.6.20/drivers/block/Kconfig
===================================================================
--- linux-2.6.20.orig/drivers/block/Kconfig
+++ linux-2.6.20/drivers/block/Kconfig
@@ -459,6 +459,16 @@ config XILINX_SYSACE
help
Include support for the Xilinx SystemACE CompactFlash interface
+config XSYSACE_8BIT
+ bool
+ depends on XILINX_SYSACE
+ default n
+
+config XSYSACE_16BIT_LE
+ bool
+ depends on XILINX_SYSACE
+ default n
+
endmenu
endif
Index: linux-2.6.20/drivers/block/xsysace.c
===================================================================
--- linux-2.6.20.orig/drivers/block/xsysace.c
+++ linux-2.6.20/drivers/block/xsysace.c
@@ -163,7 +163,39 @@ MODULE_LICENSE("GPL");
*/
/* register access macros */
-#if 1 /* Little endian 16-bit regs */
+
+#if defined CONFIG_XSYSACE_8BIT
+/* Little endian 8-bit regs */
+#define ace_reg_read8(ace, reg) \
+ in_8(ace->baseaddr + reg)
+#define ace_reg_read16(ace, reg) \
+ (in_8(ace->baseaddr + reg) | (in_8(ace->baseaddr + reg+1) << 8))
+#define ace_reg_readdata(ace, reg) \
+ ((in_8(ace->baseaddr + reg) << 8) | (in_8(ace->baseaddr + reg+1)))
+#define ace_reg_read32(ace, reg) \
+ ( in_8(ace->baseaddr + reg) | \
+ (in_8(ace->baseaddr + reg+1) << 8) | \
+ (in_8(ace->baseaddr + reg+2) << 16) | \
+ (in_8(ace->baseaddr + reg+3) << 24))
+#define ace_reg_write16(ace, reg, val) \
+ do { \
+ out_8(ace->baseaddr + reg, val); \
+ out_8(ace->baseaddr + reg+1, (val) >> 8); \
+ } while (0)
+#define ace_reg_writedata(ace, reg, val) \
+ do { \
+ out_8(ace->baseaddr + reg, (val)>>8); \
+ out_8(ace->baseaddr + reg+1, val); \
+ } while (0)
+#define ace_reg_write32(ace, reg, val) \
+ do { \
+ out_8(ace->baseaddr + reg, val); \
+ out_8(ace->baseaddr + reg+1, (val) >> 8); \
+ out_8(ace->baseaddr + reg+2, (val) >> 16); \
+ out_8(ace->baseaddr + reg+3, (val) >> 24); \
+ } while (0)
+#elif defined CONFIG_XSYSACE_16BIT_LE
+/* Little endian 16-bit regs */
#define ace_reg_read8(ace, reg) in_8(ace->baseaddr + reg)
#define ace_reg_read16(ace, reg) in_le16(ace->baseaddr + reg)
#define ace_reg_readdata(ace, reg) in_be16(ace->baseaddr + reg)
@@ -171,11 +203,12 @@ MODULE_LICENSE("GPL");
(in_le16(ace->baseaddr + reg)))
#define ace_reg_write16(ace, reg, val) out_le16(ace->baseaddr + reg, val)
#define ace_reg_writedata(ace, reg, val) out_be16(ace->baseaddr + reg, val)
-#define ace_reg_write32(ace, reg, val) { \
+#define ace_reg_write32(ace, reg, val) do { \
out_le16(ace->baseaddr + reg+2, (val) >> 16); \
out_le16(ace->baseaddr + reg, val); \
- }
-#else /* Big endian 16-bit regs */
+ } while (0)
+#else
+/* Big endian 16-bit regs */
#define ace_reg_read8(ace, reg) in_8(ace->baseaddr + reg)
#define ace_reg_read16(ace, reg) in_be16(ace->baseaddr + reg)
#define ace_reg_readdata(ace, reg) in_le16(ace->baseaddr + reg)
@@ -183,10 +216,10 @@ MODULE_LICENSE("GPL");
(in_be16(ace->baseaddr + reg)))
#define ace_reg_write16(ace, reg, val) out_be16(ace->baseaddr + reg, val)
#define ace_reg_writedata(ace, reg, val) out_le16(ace->baseaddr + reg, val)
-#define ace_reg_write32(ace, reg, val) { \
+#define ace_reg_write32(ace, reg, val) do { \
out_be16(ace->baseaddr + reg+2, (val) >> 16); \
out_be16(ace->baseaddr + reg, val); \
- }
+ } while (0)
#endif
struct ace_device {
^ permalink raw reply
* Maxim USB chips support.
From: Leonid @ 2007-04-19 18:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0704190717o14da4b58r5ef69a8e77ade198@mail.gmail.com>
Does anybody know whether Linux drivers exist for Maxim's MAX3421E USB
chips or even have such drivers? Same question regarding u-boot.
Thanks,
Leonid.
^ permalink raw reply
* Re: [PATCH 9/10] Add device tree for Ebony
From: Jon Loeliger @ 2007-04-19 18:09 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070418063626.D5DCCDDEBA@ozlabs.org>
On Wed, 2007-04-18 at 01:36, David Gibson wrote:
> Add a device tree for the Ebony evaluation board (440GP based). This
> tree is not complete or finalized. This tree needs a very recent
> version of dtc to process.
"recent" will get stale without absolute reference here.
In fact, -V 16 is "old" now even. :-)
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-03-21 13:23:48.000000000 +1100
> @@ -0,0 +1,295 @@
> +/*
> + * Device Tree Source for IBM Ebony
> + *
> + * Copyright (c) 2006, 2007 IBM Corp.
> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>, David Gibson <dwg@au1.ibm.com>
> + *
> + * FIXME: Draft only!
Hrm.
> + * 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.
> + *
> + * To build:
> + * dtc -I dts -O asm -o ebony.S -b 0 -V 16 ebony.dts
> + * dtc -I dts -O dtb -o ebony.dtb -b 0 -V 16 ebony.dts
Really Version 16? Can we just default to latest version
by not specifying the -V arg at all?
Thanks,
jdl
^ permalink raw reply
* Re: Tri-mode auto-negotiation on ML405
From: Peter Mendham @ 2007-04-19 15:48 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <461FAF0D.3070803@ru.mvista.com>
Andrei Konovalov wrote:
> And I've tried the PHY library (drivers/net/phy/*) introduced by Andy
> Fleming.
> Kinda works. [...]
> Attached is the incomplete adapter.c (with FIFO mode support only) which
> uses the PHY lib to handle the PHY. Just to illustrate the idea (will
> post the
> patch later when it is completed).
Hi Andrei,
I've now had a chance to have a go at the adapter.c you sent properly
(sorry about the delay). I'm afraid I can't get it to work. I was
wondering if you could tell me what I'm doing wrong. When I try and
bring the interface up I get:
SIOCSIFADDR: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
SIOCGIFFLAGS: No such device
route: SIOC[ADD|DEL]RT: No such device
I have included PHYLIB and even tried including support for the Marvell
PHY. I still get the same. I'm sure I've made a stupid mistake, any ideas?
Thanks,
-- Peter
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
^ permalink raw reply
* zImage.elf loads but not starts
From: Mirek23 @ 2007-04-19 15:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am just trying to build, load and run the kernel 2.6 on ppc405 of the
Avnet evaluation board which uses Xilinx Virtex 4 FX-12 chip (ml403 like).
I have downloaded the kernel 2.6 from Grant using git. I have downloaded
ELDK 4.1 to my PC.
I have compiled successfully the kernel with the crosscompiler from ELDK
4.1.
So far so good.
The kernel configuration was done according to the spec on the page:
http://www.linux.get2knowmore.com/2006/06/30/quick-guide-linux-26-on-xilinx-virtex-ii-pro-boards-part-i/
I have set during configuration phase additional parameters:
Default bootloader kernel arguments:
console=ttyS0
* 8250/16550 and compatible serial support
* Console on 8250/16550 and compatible serial support
* Initial RAM filesystem and RAM disk (initramfs/initrd) suppor
*RAM disk support
16 Default number of RAM disks
8192 Default RAM disk size (kbytes)
(1024) Default RAM disk block size (bytes)
---------------------------------------------------------------------------
when I use objdump -h zImage.elf I get:
arch/ppc/boot/images/zImage.elf: file format elf32-big
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00003848 00400000 00400000 00010000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 000f5000 00404000 00404000 00014000 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0000213c 004f9000 004f9000 00109000 2**2
ALLOC
3 .debug_abbrev 00000c3a 00000000 00000000 00109000 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_info 0000267d 00000000 00000000 00109c3a 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_line 00000bc8 00000000 00000000 0010c2b7 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_frame 000004c0 00000000 00000000 0010ce80 2**2
CONTENTS, READONLY, DEBUGGING
7 .debug_loc 00002c7c 00000000 00000000 0010d340 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_pubnames 000003c5 00000000 00000000 0010ffbc 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_aranges 00000120 00000000 00000000 00110381 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_ranges 00000078 00000000 00000000 001104a1 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_str 00000ae0 00000000 00000000 00110519 2**0
CONTENTS, READONLY, DEBUGGING
12 .note.GNU-stack 00000000 00000000 00000000 00110ff9 2**0
CONTENTS, READONLY
To load the zImage.elf to the SDRAM of my Avent evaluation board I use JTAG
and Xilinx XMD program:
XMD% dow zImage.elf
section, .text: 0x00400000-0x00403848
section, .data: 0x00404000-0x004f0000
section, .bss: 0x004f0000-0x004f21a0
Downloaded Program zImage.elf
Setting PC with program start addr = 0x00400000
PC reset to 0x00400000, Clearing MSR Register
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
I do not see any output in the XMD session nor in the minicom window
connected to the Xilinx serial port.
It seems to be that the kernel did not start.
The Avent board has 32 MB of SD RAM. Before loading the zImage.elf I have
loaded the bitstream to setup the Xillinx FPGA.
Do you have an idea what could be wrong.
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10079346
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Using Cypress EZ-Host on ML403/5
From: Grant Likely @ 2007-04-19 14:17 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <87zm54mt3j.fsf@sleipner.barco.com>
On 4/19/07, Peter Korsgaard <peter.korsgaard@barco.com> wrote:
> >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
> Grant> It's on my task list to get working. I could certainly use
> Grant> some help.
>
> I have written a 2.6 USB host driver for the Cypress
> EZ-Host/EZ-Otg. It's basically working, but needs a bit more
> cleanup. I hope to be able to submit it next week.
Very cool; any chance I could get a pre-release copy. :-)
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Using Cypress EZ-Host on ML403/5
From: Peter Korsgaard @ 2007-04-19 12:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0704160932k2038090al8c0b8e5420422545@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
>> Has anyone had the Cypress EZ-Host chip working as a USB host under
>> Linux? It's the one that comes fitted as standard to ML403 and
>> ML405 boards (probably other Xilinx boards too). If not, can
>> anyone tell me where I should start? Any advice at all? Our own
>> embedded device needs to have USB host support and we are using an
>> ML40x for development so the EZ-Host is the preferred solution as
>> we can prototype it.
Grant> It's on my task list to get working. I could certainly use
Grant> some help.
I have written a 2.6 USB host driver for the Cypress
EZ-Host/EZ-Otg. It's basically working, but needs a bit more
cleanup. I hope to be able to submit it next week.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: PREEMPT_RT patch on 85xx
From: Josh Boyer @ 2007-04-19 12:26 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: Linuxppc-embedded
In-Reply-To: <46275C7A.4030903@dutchspace.nl>
On Thu, 2007-04-19 at 14:11 +0200, Johan Borkhuis wrote:
> Hello,
>
> I am trying to run Ingo's PREEMPT_RT patch on an MVME3100 (PPC 8540).
> But when I try to compile the kernel (version 2.6.20 with Motorola
> MVME3100 patch and patch-2.6.20-rt8) I get compile errors. I did find an
> extra patch-set for use with the powerpc architecture, but this set does
> not fix the ppc-architecture.
>
> Is there another patch available, or did I miss some configuration
> option? Or is the PREEMPT_RT patch not (yet) available for the ppc
> architecture?
arch/ppc is dying a slow death and is being replaced by arch/powerpc.
This is likely why there is no ppc "backport".
josh
^ permalink raw reply
* PREEMPT_RT patch on 85xx
From: Johan Borkhuis @ 2007-04-19 12:11 UTC (permalink / raw)
To: Linuxppc-embedded
Hello,
I am trying to run Ingo's PREEMPT_RT patch on an MVME3100 (PPC 8540).
But when I try to compile the kernel (version 2.6.20 with Motorola
MVME3100 patch and patch-2.6.20-rt8) I get compile errors. I did find an
extra patch-set for use with the powerpc architecture, but this set does
not fix the ppc-architecture.
Is there another patch available, or did I miss some configuration
option? Or is the PREEMPT_RT patch not (yet) available for the ppc
architecture?
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Re: RFC: powerpc: Start splitting up mmu.h by MMU type
From: Kumar Gala @ 2007-04-19 12:11 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070419065430.GA5862@localhost.localdomain>
On Apr 19, 2007, at 1:54 AM, David Gibson wrote:
> This patch makes a start to sorting out the tangled mess of MMU
> related header files in asm-powerpc, and weaning arch/powerpc off the
> remaining asm-ppc headers it uses.
>
> Specifically it splits the ppc64 specific (or more strictly, the
> 64-bit hash table specific) parts of asm-powerpc/mmu.h into its own
> file, asm-powerpc/mmu-hash64/mmu.h. Similarly, PowerPC 44x
> definitions are taken from asm-ppc/mmu.h, trimmed down for use in
> arch/powerpc and place in their own file, asm-powerpc/mmu-44x/mmu.h.
>
> mmu.h definitions for other 32-bit MMU types remain in asm-ppc/mmu.h
> for now, but should be likewise split into their own files.
I asked this before, but why the need for a separate directory per
mmu type? why not just include/asm-powerpc/mmu-44x.h?
- k
^ 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