* Re: Stupid Telnet Question
From: Ben Warren @ 2006-09-11 4:49 UTC (permalink / raw)
To: Martin, Tim, linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE4871064A53C4@VCAEXCH01.hq.corp.viasat.com>
Tim,
--- "Martin, Tim" <tim.martin@viasat.com> wrote:
<snip>
> When I just telnet
> locally from the serial console to the board (using
> the loopback IP
> 127.0.0.1) the telnet daemon connects, but the login
> program doesn't
> give me a chance to type a username or login.
>
> Question: What stupid thing have I done to cause
> this and how can I fix
> it?
>
> -------------------------------------------------
> This is what my console session looks like:
>
> # telnet 127.0.0.1
>
> Entering character mode
> Escape character is '^]'.
>
>
> Linux 2.6.14 (172.16.5.11) (17:13 on Tuesday, 22
> November 2011)
>
> Login incorrect
>
> Login incorrect
>
> Login incorrect
>
>
> Login incorrect
> Connection closed by foreign host.
>
> -------------------------------------------------
> And here's what syslog is saying:
>
> Nov 22 17:15:08 172 authpriv.info xinetd[1025]:
> START: telnet pid=1037
> from=172.16.1.199
> Nov 22 17:15:08 172 authpriv.notice login: FAILED
> LOGIN 1 FROM
> 172.16.1.199 FOR (null), Authentication failure
For security reasons, Telnet is typically set up so
that you can't log in using 'root'. This is because
the data channel isn't encrypted so passwords are
easily compromised. If you don't have any other users
set up, it will give the behaviour that you're seeing.
It's been a while since I've done this, but I think
you need to edit /etc/xinetd.d/telnet to allow root
use. Or add a user. Or install SSH.
cheers,
Ben
^ permalink raw reply
* Re: Perhaps git-update-server-info needs to be run on .../paulus/powerpc.git?
From: Paul Mackerras @ 2006-09-11 8:25 UTC (permalink / raw)
To: Kim Phillips, linuxppc-dev
In-Reply-To: <17625.18896.977702.640753@cargo.ozlabs.ibm.com>
Paul Mackerras writes:
> Kim Phillips writes:
>
> > Linus' tree clones fine, paulus' doesn't:
>
> Try now...
>
> Paul.
Oops, mail system error, ignore me...
Paul.
^ permalink raw reply
* Re: MPC8360E USB Host Controller Driver
From: Alex Zeffertt @ 2006-09-11 9:08 UTC (permalink / raw)
To: Dan Gora; +Cc: linuxppc-embedded
In-Reply-To: <4779de450609081809g33187e96vf2754af95c7e8514@mail.gmail.com>
Dan Gora wrote:
>>> Could you give a direct link ? I've been browsing around the
>>> Freescale website for an hour, downloaded hundreds of
>>> megabytes of archives but haven't been able to find the
>>> MPC8360E USB Linux driver.
>>>
>>> Laurent Pinchart
>
> Hi Laurent,
>
> I believe that I recall seeing the USB drivers in the "MPC8360E Device
> Drivers - Release 1.1 GPL ", accessible from the main 8360 page.
>
> http://www.freescale.com/files/netcomm/software/device_drivers/MPC8360EGPLDRV.zip
>
These don't look like Linux drivers to me. (Although they are GPL so you could
port them to Linux if you have the inclination.)
Alex
^ permalink raw reply
* missing release_region in i8042_exit
From: Olaf Hering @ 2006-09-11 9:30 UTC (permalink / raw)
To: linuxppc-dev
Does anyone know why 64bit kernels do not call release_region in
i8042_platform_exit? Why is it allowed on 32bit kernels?
drivers/input/serio/i8042-io.h
83 static inline void i8042_platform_exit(void)
84 {
85 #if !defined(__sh__) && !defined(__alpha__) && !defined(CONFIG_PPC64)
86 release_region(I8042_DATA_REG, 16);
87 #endif
88 }
^ permalink raw reply
* upgrade cramfs rootfs while running
From: ganesh subramonian @ 2006-09-11 9:39 UTC (permalink / raw)
To: linuxppc-embedded
i have a cramfs image, which is my rootfs(/ partition)
on flash. in an earlier thread i found some replies
saying that upgrading it while mounted was prone to
errors. however if i am doing the upgrade only in my
shutdown scripts (so that most applications are killed
by this time) like this:
mount -o loop -t cramfs rootfs.img /tmp/somedir
eraseall /dev/mtd2
cp rootfs.img /dev/mtd2
export PATH=/tmp/somedir/bin:/tmp/somedir/sbin...
export LD_LIBRARY_PATH=/tmp/somedir/lib
reboot
is there anything that could go wrong? All further
programs(with their libs) should be executed from the
loop mounted rootfs.
or else can i do something like
mount -o loop ...
cd /tmp/somedir
pivot_root . tmp
eraseall, copy
reboot
Since i am upgrading just before reboot only these
scripts would be running. Is there a risk in
either/both of these methods.
Thanks
Ganesh
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [PATCH] Prevent legacy io access on pmac
From: Olaf Hering @ 2006-09-11 11:53 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
The ppc32 common config runs also on PReP/CHRP, which uses PC style IO
devices. The probing is bogus, it crashes or floods dmesg.
ppc can boot one single binary on prep, chrp and pmac boards.
ppc64 can boot one single binary on pseries and G5 boards.
pmac has no legacy io, probing for PC style legacy hardware leads to a
hard crash:
* add check for parport_pc, exit on pmac.
32bit chrp has no ->check_legacy_ioport, the probe is always called.
64bit chrp has check_legacy_ioport, check for a "parallel" node
* add check for isapnp, only PReP boards may have real ISA slots.
32bit PReP will have no ->check_legacy_ioport, the probe is always called.
* update code in i8042_platform_init. Run ->check_legacy_ioport first, always
call request_region. No functional change. Remove whitespace before i8042_reset init.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/powerpc/platforms/pseries/setup.c | 6 ++++++
drivers/input/serio/i8042-io.h | 13 +++++--------
drivers/parport/parport_pc.c | 4 ++++
drivers/pnp/pnpbios/core.c | 8 ++++++++
include/asm-powerpc/io.h | 2 ++
5 files changed, 25 insertions(+), 8 deletions(-)
Index: linux-2.6.18-rc6/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6.18-rc6.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6.18-rc6/arch/powerpc/platforms/pseries/setup.c
@@ -401,6 +401,12 @@ static int pSeries_check_legacy_ioport(u
return -ENODEV;
of_node_put(np);
break;
+ case PARALLEL_BASE:
+ np = of_find_node_by_type(NULL, "parallel");
+ if (np == NULL)
+ return -ENODEV;
+ of_node_put(np);
+ break;
}
return 0;
}
Index: linux-2.6.18-rc6/drivers/input/serio/i8042-io.h
===================================================================
--- linux-2.6.18-rc6.orig/drivers/input/serio/i8042-io.h
+++ linux-2.6.18-rc6/drivers/input/serio/i8042-io.h
@@ -67,25 +67,22 @@ static inline int i8042_platform_init(vo
* On some platforms touching the i8042 data register region can do really
* bad things. Because of this the region is always reserved on such boxes.
*/
-#if !defined(__sh__) && !defined(__alpha__) && !defined(__mips__) && !defined(CONFIG_PPC_MERGE)
- if (!request_region(I8042_DATA_REG, 16, "i8042"))
- return -EBUSY;
-#endif
-
- i8042_reset = 1;
-
#if defined(CONFIG_PPC_MERGE)
if (check_legacy_ioport(I8042_DATA_REG))
return -EBUSY;
+#endif
+#if !defined(__sh__) && !defined(__alpha__) && !defined(__mips__)
if (!request_region(I8042_DATA_REG, 16, "i8042"))
return -EBUSY;
#endif
+
+ i8042_reset = 1;
return 0;
}
static inline void i8042_platform_exit(void)
{
-#if !defined(__sh__) && !defined(__alpha__) && !defined(CONFIG_PPC64)
+#if !defined(__sh__) && !defined(__alpha__)
release_region(I8042_DATA_REG, 16);
#endif
}
Index: linux-2.6.18-rc6/drivers/parport/parport_pc.c
===================================================================
--- linux-2.6.18-rc6.orig/drivers/parport/parport_pc.c
+++ linux-2.6.18-rc6/drivers/parport/parport_pc.c
@@ -3374,6 +3374,10 @@ __setup("parport_init_mode=",parport_ini
static int __init parport_pc_init(void)
{
+#if defined(CONFIG_PPC_MERGE)
+ if (check_legacy_ioport(PARALLEL_BASE))
+ return -EBUSY;
+#endif
if (parse_parport_params())
return -EINVAL;
Index: linux-2.6.18-rc6/include/asm-powerpc/io.h
===================================================================
--- linux-2.6.18-rc6.orig/include/asm-powerpc/io.h
+++ linux-2.6.18-rc6/include/asm-powerpc/io.h
@@ -11,6 +11,8 @@
/* Check of existence of legacy devices */
extern int check_legacy_ioport(unsigned long base_port);
+#define PARALLEL_BASE 0x378
+#define PNPBIOS_BASE 0xf000 /* only relevant for PReP */
#ifndef CONFIG_PPC64
#include <asm-ppc/io.h>
Index: linux-2.6.18-rc6/drivers/pnp/pnpbios/core.c
===================================================================
--- linux-2.6.18-rc6.orig/drivers/pnp/pnpbios/core.c
+++ linux-2.6.18-rc6/drivers/pnp/pnpbios/core.c
@@ -526,6 +526,10 @@ static int __init pnpbios_init(void)
{
int ret;
+#if defined(CONFIG_PPC_MERGE)
+ if (check_legacy_ioport(PNPBIOS_BASE))
+ return -ENODEV;
+#endif
if (pnpbios_disabled || dmi_check_system(pnpbios_dmi_table)) {
printk(KERN_INFO "PnPBIOS: Disabled\n");
return -ENODEV;
@@ -575,6 +579,10 @@ subsys_initcall(pnpbios_init);
static int __init pnpbios_thread_init(void)
{
+#if defined(CONFIG_PPC_MERGE)
+ if (check_legacy_ioport(PNPBIOS_BASE))
+ return 0;
+#endif
if (pnpbios_disabled)
return 0;
#ifdef CONFIG_HOTPLUG
^ permalink raw reply
* Re: I2C on MPC8272...
From: Vitaly Bordug @ 2006-09-11 11:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BE8B3EECA608414FB163FBA4576FCEBD432009@EXNY.us.corp.aacisd.com>
On Fri, 8 Sep 2006 13:00:58 -0400
"Kuffner Cory" <CKuffner@LIO.AACISD.com> wrote:
> Hello all,
>
> Does anyone know how to use the I2C module for the MPC8272?? We are attempting to enable it by following code written for a bareboard system and converting it into a kernel module (2.6.11 Kernel), but nothing happens on our SDA and SCL data lines. The parameter ram is kind of tricky to set up, but I beleive we have everything pointing where it should. To write to the IMM we are using the ioremap function with ioread and iowrite, we can write to the ports so I don't think there is an issue writing to memory, but I'm new to embedded linux. Has anyone ever used the I2C controller in one of freescale's chips or just a good understanding of I2C modules in embedded linux?? I think all the chips have the same I2C interface....so it should be the same set up for MPC8250, 8255, 8260, etc.
>
I am recalling i2c functional on 8272, but no other details unfortunately. IIRC, i2c-mpc.c did the magic with some minor intervention.
Barely, to access immr it is ioremapped early, and cpm2_immr-> holds i2c controller, pram and other pleasant stuff. And, I am recalling i2c on 8540 working fine right out of the box...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [2.6.19 PATCH 0/7] ehea: IBM eHEA Ethernet Device Driver
From: Jeff Garzik @ 2006-09-11 13:12 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
In-Reply-To: <200609041236.32279.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> Hi,
>
> this is our current version of the IBM eHEA Ethernet Device Driver. We added
> minor bug fixes and changes to the last version.
>
> Jeff, this driver has been discussed on the netdev, linux-ppc and
> kernel mailing list. We didn't receive any further comments since our previous
> patch set from August 23. Please consider our driver for
> upstream inclusion.
>
> Thanks,
>
> Jan-Bernd Themann & Christoph Raisch
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
> Changelog-by: Jan-Bernd Themann <themann@de.ibm.com>
Email me an all-in-one-email patch, please.
Jeff
^ permalink raw reply
* Reminder: [PATCH] Add new, missing argument to of_irq_map_raw().
From: Jon Loeliger @ 2006-09-11 13:29 UTC (permalink / raw)
To: linuxppc-dev
Paul,
I just wanted to check with you that this patch isn't
slipping through the cracks as we close out 2.6.18.
Without this, the 86xx build is broken, of course.
Thanks!
jdl
------- Forwarded Message
From: Jon Loeliger <jdl@freescale.com>
To: linuxppc-dev@ozlabs.org
Subject: [PATCH] Add new, missing argument to of_irq_map_raw().
Date: Fri, 01 Sep 2006 10:17:20 -0500
Message-Id: <E1GJAlk-00053S-3U@jdl.com>
Ben speaks; we follow.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
- ---
Paul,
This patch is needed in the 2.6.18 release for 86xx.
Ben's recent changes to of_irq_map_raw() missed one caller.
This patch cleans that up.
Thanks,
jdl
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 4a33d95..cdaf668 100644
- --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -154,7 +154,7 @@ get_pci_irq_from_of(struct pci_controlle
laddr[0] = (hose->first_busno << 16) | (PCI_DEVFN(slot, 0) << 8);
laddr[1] = laddr[2] = 0;
- - of_irq_map_raw(hosenode, &pin, laddr, &oirq);
+ of_irq_map_raw(hosenode, &pin, 1, laddr, &oirq);
DBG("mpc86xx_hpcn: pci irq addr %x, slot %d, pin %d, irq %d\n",
laddr[0], slot, pin, oirq.specifier[0]);
return oirq.specifier[0];
- --
1.4.2.rc2.g85d6c-dirty
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
------- End of Forwarded Message
^ permalink raw reply
* Re: [PATCH] Prevent legacy io access on pmac
From: Olaf Hering @ 2006-09-11 15:17 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
In-Reply-To: <20060911115354.GA23884@aepfle.de>
On Mon, Sep 11, Olaf Hering wrote:
> * add check for parport_pc, exit on pmac.
How do I allow parport on PCI cards?
^ permalink raw reply
* Re: [PATCH] Prevent legacy io access on pmac
From: Segher Boessenkool @ 2006-09-11 15:30 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060911151730.GA25244@aepfle.de>
>> * add check for parport_pc, exit on pmac.
>
> How do I allow parport on PCI cards?
Use the parport_serial driver... cards that are fixed at the
legacy address probably won't work at all on a PowerMac, the PCI
bridges would have to be set up specially and you'll run into all
kinds of problems.
Cards that have a parport with a configurable base address work
fine in a PowerMac.
Segher
^ permalink raw reply
* Re: Kernel panic: kernel access of bad area pc
From: Will Schmidt @ 2006-09-11 15:37 UTC (permalink / raw)
To: ppc64; +Cc: linuxppc-dev
In-Reply-To: <200609081532.59764.ppc64@storix.com>
On Fri, 2006-08-09 at 15:32 -0700, ppc64@storix.com wrote:
> I have a process to create tape boot images by combining the kernel and initrd
> into a zImage. The process works for 2.4 (RHEL 3.3) & 2.6 kernels (SLES9 &
> RHEL4). However on SLES8 ppc64 the kernel panics with "error kernel access of
> bad area pc".
> Anyone have an idea what is causing the failure? The error message appears to
> be pretty generic.
The exception is a "TRAP: 0600" which is an alignment interrupt.
the trap occurred at NIP: C000000000085874
Get an objdump of your kernel, (or drop into xmon/kdb and use the
disassembler commands) and see what instruction lives at that NIP
address, and which registers it is referencing. (Then its a matter of
finding out why the registers have bad data in them).
(You probally have already done this, but if not... ) If you're booting
off of tape in this instance, may want to try booting off of disk, and
doing some tape operations after successful boot, to ensure the driver
is all OK.
-Will
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Any PPC system with working USB 2.0 host
From: Jamie Guinan @ 2006-09-11 15:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm trying to get ahold of a low-power, small form factor system with
support for USB 2.0 hi-speed host. PPC would appear to be a good
solution for this.
I've tried 2 well-known embedded board vendors, and despite having USB
2.0 capable hardware, neither could provide a working solution. The
"BSPs" from both vendors depend on out-of-tree patches, so I won't
bother this list with details.
Does USB 2.0 host on the KuroBox in fact work, with hi-speed devices?
Any other boards that are known to work?
-Jamie
^ permalink raw reply
* Re: Kernel panic: kernel access of bad area pc
From: Olaf Hering @ 2006-09-11 16:01 UTC (permalink / raw)
To: ppc64; +Cc: linuxppc-dev
In-Reply-To: <200609081532.59764.ppc64@storix.com>
On Fri, Sep 08, ppc64@storix.com wrote:
> I have a process to create tape boot images by combining the kernel and initrd
> into a zImage. The process works for 2.4 (RHEL 3.3) & 2.6 kernels (SLES9 &
> RHEL4). However on SLES8 ppc64 the kernel panics with "error kernel access of
> bad area pc".
What do you use to create the zImage header?
Also, does the SP3 kernel work any better? The reiserfs mem corruption
has likely has likely the same cause as the ramdisk corruption.
^ permalink raw reply
* Re: [PATCH] Prevent legacy io access on pmac
From: Olaf Hering @ 2006-09-11 15:52 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, Daniel Quinlan, Vojtech Pavlik
In-Reply-To: <20060911115354.GA23884@aepfle.de>
On Mon, Sep 11, Olaf Hering wrote:
>
> The ppc32 common config runs also on PReP/CHRP, which uses PC style IO
> devices. The probing is bogus, it crashes or floods dmesg.
>
> ppc can boot one single binary on prep, chrp and pmac boards.
> ppc64 can boot one single binary on pseries and G5 boards.
> pmac has no legacy io, probing for PC style legacy hardware leads to a
> hard crash:
drivers/input/touchscreen/mk712.c pokes at 0x262 and other IO ports.
A comment in the driver suggests that it is only used on Gateway
computers. Should the driver be X86 only?
^ permalink raw reply
* RE: Any PPC system with working USB 2.0 host
From: Steven Blakeslee @ 2006-09-11 15:54 UTC (permalink / raw)
To: Jamie Guinan, linuxppc-embedded
> Any other boards that are known to work?
>=20
AMCC 440EPx. Freescale 8343. Both have Linux support with USB 2.0
host.
^ permalink raw reply
* Re: [PATCH 1/1] bootwrapper: add flat device tree support code
From: Jon Loeliger @ 2006-09-11 17:27 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1157726787.26967.7.camel@basalt.austin.ibm.com>
On Fri, 2006-09-08 at 09:46, Hollis Blanchard wrote:
> On Thu, 2006-09-07 at 20:46 -0700, Mark A. Greer wrote:
> > --- /dev/null
> > +++ b/arch/powerpc/boot/flatdevtree.c
> > @@ -0,0 +1,628 @@
> > +/*
> > + * DO NOT EDIT THIS FILE!!
> > + *
> > + * The master copy is kept in a mercurial repository that you can clone:
> > + * "hg clone http://unsanctioned.org/flatdevtree/hgweb.py flatdevtree"
> > + * Please send patches to Hollis Blanchard <hollisb@us.ibm.com> and
> > + * CC: <Linuxppc-dev@ozlabs.org>
> > + *
>
> Actually I'm not intending for that to be a long-term URL. If we need
> something permanent for this file, I can set something up on
> penguinppc.org...
>
> (NAK)
>
> -Hollis
Wasn't there a notion of even combining this with
the DTC code base directly? I haven't seen any
patches or motion down this line, though...?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 1/1] bootwrapper: add flat device tree support code
From: Jon Loeliger @ 2006-09-11 18:39 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1158000245.24546.24.camel@basalt.austin.ibm.com>
On Mon, 2006-09-11 at 13:44, Hollis Blanchard wrote:
> That's certainly a good place the new code could be applied. Of course,
> I haven't sent patches to uboot, iseries boot code, kexec, or any other
> number of places either, and don't really plan to. If those areas have
> problems, they can switch to the consolidated codebase then (rather than
> bugfixing the non-consolidated code).
I'm worried about the code-duplication factor here...
> Why, are you going to convert DTC?
I'm not opposed to accepting patches. :-)
jdl
^ permalink raw reply
* Re: [PATCH 1/1] bootwrapper: add flat device tree support code
From: Hollis Blanchard @ 2006-09-11 18:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1157995667.27129.148.camel@cashmere.sps.mot.com>
On Mon, 2006-09-11 at 12:27 -0500, Jon Loeliger wrote:
>
> Wasn't there a notion of even combining this with
> the DTC code base directly? I haven't seen any
> patches or motion down this line, though...?
That's certainly a good place the new code could be applied. Of course,
I haven't sent patches to uboot, iseries boot code, kexec, or any other
number of places either, and don't really plan to. If those areas have
problems, they can switch to the consolidated codebase then (rather than
bugfixing the non-consolidated code).
Why, are you going to convert DTC?
-Hollis
^ permalink raw reply
* Re: [PATCH 1/1] bootwrapper: add flat device tree support code
From: Hollis Blanchard @ 2006-09-11 19:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1157999955.27129.168.camel@cashmere.sps.mot.com>
On Mon, 2006-09-11 at 13:39 -0500, Jon Loeliger wrote:
> On Mon, 2006-09-11 at 13:44, Hollis Blanchard wrote:
>
> > That's certainly a good place the new code could be applied. Of course,
> > I haven't sent patches to uboot, iseries boot code, kexec, or any other
> > number of places either, and don't really plan to. If those areas have
> > problems, they can switch to the consolidated codebase then (rather than
> > bugfixing the non-consolidated code).
>
> I'm worried about the code-duplication factor here...
The functionality has already been duplicated, and more was on the way.
The consolidated code prevents that from spreading, but by itself
doesn't replace any of the existing duplication.
> > Why, are you going to convert DTC?
>
> I'm not opposed to accepting patches. :-)
Have fun.
-Hollis
^ permalink raw reply
* Re: [PATCH] powerpc: Quiet hvc_console console output on failed opens
From: Ryan Arnold @ 2006-09-11 19:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17664.43318.370252.157724@cargo.ozlabs.ibm.com>
On Fri, 2006-09-08 at 09:20 +1000, Paul Mackerras wrote:
> Ryan Arnold writes:
>
> > This seems like a good fix to me. I think it is a debug artifact
> > anyway.
>
> So, does that amount to an Acked-by?
>
> Paul.
Yes, take that as an:
Acked-by: Ryan S. Arnold <rsa@us.ibm.com>
--
Ryan S. Arnold <rsa@us.ibm.com>
IBM Linux Technology Center
Linux on Power Toolchain
^ permalink raw reply
* Re: Perhaps git-update-server-info needs to be run on .../paulus/powerpc.git?
From: Kim Phillips @ 2006-09-11 20:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17669.7544.599959.442534@cargo.ozlabs.ibm.com>
On Mon, 11 Sep 2006 18:25:28 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Paul Mackerras writes:
>
> > Kim Phillips writes:
> >
> > > Linus' tree clones fine, paulus' doesn't:
> >
> > Try now...
> >
> > Paul.
>
> Oops, mail system error, ignore me...
>
> Paul.
funnily enough, I can't seem to clone your tree again today; I'm using the http: protocol.
hopefully, the fix should only be a matter of:
chmod +x hooks/post-update
Thanks,
Kim
^ permalink raw reply
* Re: Any PPC system with working USB 2.0 host
From: Guennadi Liakhovetski @ 2006-09-11 20:13 UTC (permalink / raw)
To: Jamie Guinan; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0609111140260.6892@gemini.home.net>
On Mon, 11 Sep 2006, Jamie Guinan wrote:
> Does USB 2.0 host on the KuroBox in fact work, with hi-speed devices?
Yes, it does. Never had problems with it, using it with a high-speed
wireless dongle, didn't test too intensively with storage though.
Regards
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* simple ELF bootloader for embedded xilinx linux ?
From: rimas @ 2006-09-11 19:44 UTC (permalink / raw)
To: linuxppc-embedded
Greetings,
i have been prototyping a design using the avnet V4FX12 mini module
board running linux
i have been NFS mounting my root partition for the time being but now
i want to use initrd and have a ramdisk with my root partition
i have built a zImage.initrd.elf which i can download with xmd and
run and it works fine
up until now i've been using the simple bootloader application that
comes with the Xilinx EDK to boot linux off the flash memory that is
included on the board
however the EDK bootloader needs the file its booting to be in SREC
format which takes up close to 3x the space of the ELF file. when i
create an SREC file of the image containing the linux kernel and the
root filesystem, its too big to fit in the flash (4M). however the
zImage.initrd.elf file is less than 3 megs in size.
whats the best/easiest way for me to boot from an ELF file in the
flash ? i'm aware of u-boot but it seems like overkill for this
application. however if it would work and the footprint is
relatively small i could give it a try. i imagine i could write my
own bootloader, i just thought i'd ask first to avoid reinventing the
wheel.
another somewhat related question is whether i can use a portion of
the flash (the part thats left over after the kernel/root fs image is
programmed) as nonvolatile storage using the JFFS2 filesystem ?
anyone have any pointers to information on how to set this up ?
thanks for any and all advice,
-rimas
^ permalink raw reply
* Re: simple ELF bootloader for embedded xilinx linux ?
From: Michael Galassi @ 2006-09-11 21:20 UTC (permalink / raw)
To: rimas; +Cc: linuxppc-embedded
In-Reply-To: <1354DD02-657B-4777-8378-BC408DA3D800@cnmat.berkeley.edu>
>whats the best/easiest way for me to boot from an ELF file in the
>flash ? i'm aware of u-boot but it seems like overkill for this
>application. however if it would work and the footprint is
>relatively small i could give it a try. i imagine i could write my
>own bootloader, i just thought i'd ask first to avoid reinventing the
>wheel.
If you're using the zImage file the only bootloader you need is an
unconditional, unlinked branch to the first instruction you want to
execute in the zImage located at -4 (0xfffffffc). To save a few extra
bytes you can strip the ELF header from the zImage, then you flash it
at the same address you jump to. I do that with objcopy:
make zImage && \
ppc_405-objcopy -O binary arch/ppc/boot/images/zImage.elf zImage.bin
Remember that the first instruction of the kernel must reside within
your relative jump limit if you take this approach. If you place your 3
meg kernel right below the branch instruction you'll have no problems
with this at all. If you prefer mapping your flash lower down and use a
blockram (or whatever) for your boot-code you can branch a dozen bytes
backward in the instruction at -4 and have an absolute branch there
which could reach anyplace in your address space.
>another somewhat related question is whether i can use a portion of
>the flash (the part thats left over after the kernel/root fs image is
>programmed) as nonvolatile storage using the JFFS2 filesystem ?
>anyone have any pointers to information on how to set this up ?
Most flash must be erased in 128K blocks, once two are paired to yield
a 32bit wide data bus you'll find yourself segmenting your space into
256K blocks. I use an integral number of these blocks for a cramfs
image, I see no reason you shouldn't do the same for a jffs2. Just be
careful not to accidentally write past the space you allocate to your
filesystem and onto your boot-code, kernel, and what ever else you place
in flash. Since bricking(*) a system is viewed as a bad thing we don't
allow writes to the filesystem in flash, we instead write entire images
at once in carefully controlled conditions.
An over-simplified flash map ends up looking something like:
"size-4bytes" branch instruction to "top-4meg"
"size-4meg" kernel stripped of elf header
"size-20meg" filesystem image
"0" bitstream loaded into FPGA at power-up
Adjust the sizes to fit your kernel size, filesystem size, bistream
size, and to accommodate the flash size you're using and other data
you might with to store in flash.
(*) brick (verb) to render functionally brick-like
-michael
^ 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