* [PATCH 2/3] Export of_bus_pci_get_flags().
From: Jon Loeliger @ 2007-05-29 18:23 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/kernel/prom_parse.c | 2 +-
include/asm-powerpc/prom.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..754926f 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -153,7 +153,7 @@ static int of_bus_pci_translate(u32 *addr, u64 offset, int na)
return of_bus_default_translate(addr + 1, offset, na - 1);
}
-static unsigned int of_bus_pci_get_flags(const u32 *addr)
+unsigned int of_bus_pci_get_flags(const u32 *addr)
{
unsigned int flags = 0;
u32 w = addr[0];
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 6845af9..0168373 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -185,6 +185,7 @@ extern int pci_device_from_OF_node(struct device_node *node,
extern struct device_node* pci_busdev_to_OF_node(struct pci_bus *, int);
extern struct device_node* pci_device_to_OF_node(struct pci_dev *);
extern void pci_create_OF_bus_map(void);
+extern unsigned int of_bus_pci_get_flags(const u32 *addr);
#endif
extern struct resource *request_OF_resource(struct device_node* node,
^ permalink raw reply related
* [PATCH 1/3] Let subordinate transparent bridges be transparent.
From: Jon Loeliger @ 2007-05-29 18:22 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: York Sun <yorksun@freescale.com>
In pcibios_fixup_bus(), bridges that are subordinate
to transparent bridges were still relocating their
IORESOURCE_IO start and end values.
Fix this by preventing the transparent bridge from
relocating the start and end values, thus allowing the
subordinate non-transparent bridge full molestation rights.
Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/kernel/pci_32.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index e66064b..102264c 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -1372,7 +1372,9 @@ void __init pcibios_fixup_bus(struct pci_bus *bus)
continue;
if (!res->flags)
continue;
- if (io_offset && (res->flags & IORESOURCE_IO)) {
+ if (!bus->self->transparent
+ && io_offset
+ && (res->flags & IORESOURCE_IO)) {
res->start += io_offset;
res->end += io_offset;
} else if (hose->pci_mem_offset
^ permalink raw reply related
* [PATCH 0/3] Fix PCI-E Resource allocation problems on 8641.
From: Jon Loeliger @ 2007-05-29 18:22 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Paul,
These three patches fix some PCI resource allocation problems
that we saw on 8641 boards. These patches are on top of
Zhang Wei's earlier 5 patches, and should apply to your
current master branch.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 5/5] Set IDE in ULI1575 to not native mode.
From: Jon Loeliger @ 2007-05-29 18:15 UTC (permalink / raw)
To: Wei Zhang; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <1179805110284-git-send-email-wei.zhang@freescale.com>
On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Set IDE in ULI1575 to not 100% native mode, which forces
> the IDE driver to probe the irq itself.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>
^ permalink raw reply
* Re: [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
From: Jon Loeliger @ 2007-05-29 18:15 UTC (permalink / raw)
To: Wei Zhang; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <11798051102051-git-send-email-wei.zhang@freescale.com>
On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
> Now, the children bus could use the I/O resource of the host bridge.
>
> Note: The 0x7010 is the device ID of host bridge for MPC8641 and
> 0x7011 is the device ID of host bridge fro MPC8641D.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Jon Loeliger @ 2007-05-29 18:14 UTC (permalink / raw)
To: Wei Zhang; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <1179805110278-git-send-email-wei.zhang@freescale.com>
On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Float the pci bus number on MPC8641HPCN board.
> For example, PCI hose 1 bus range is from 0 to 2, the PCI hose 2 bus
> range will start from 3.
> Add the pci-express link training stats check. It avoid the system halt
> while the link training is fault.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Acked-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>
^ permalink raw reply
* Re: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Jon Loeliger @ 2007-05-29 18:14 UTC (permalink / raw)
To: Wei Zhang; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <1179805110272-git-send-email-wei.zhang@freescale.com>
On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Add uli1575 pci-bridge sector. It fixes the issue of ULI1575 not found on rev.2 board.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>
^ permalink raw reply
* Re: [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.
From: Jon Loeliger @ 2007-05-29 18:13 UTC (permalink / raw)
To: Wei Zhang; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <11798051101543-git-send-email-wei.zhang@freescale.com>
On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Remove the errata fix codes for MPC8641 silicon ver 1.0 which
> is end of life.
>
> The MPC8641 silicon ver 1.0 is not fully support PCI/PCI Express
> specifications. The revision 2.0 fixes all of these errata
> and the rev 1.0 silicon is end of life. So errata codes are removed.
>
> Now, The chip is full compatible with PCI/PCI Express
> specifications. The generic PCI code is used.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>
^ permalink raw reply
* Re: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 and MPC8641HPCN board 2.0
From: Jon Loeliger @ 2007-05-29 18:12 UTC (permalink / raw)
To: Wei Zhang; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <11798051102658-git-send-email-wei.zhang@freescale.com>
On Mon, 2007-05-21 at 22:38, Zhang Wei wrote:
> Hi, Paul,
>
> The below 5 patches add the support for MPC8641 rev 2.0 silicon and MPC8641HPCN board 2.0.
>
> [PATCH 1/5] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.
> [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
> [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
> [PATCH 4/5] Set RC of mpc8641 to transparent bridge for transfer legacy I/O access.
> [PATCH 5/5] Set IDE in ULI1575 to not native mode.
>
> The MPC8641 rev 2.0 silicon fix the PCI/PCI-Express errata in rev 1.0. And the rev 1.0 silicon is end of life. So the dts tree and codes should be changes. Codes which are not compatible with PCI/PCI-Express specifications are removed. Some minor issues are fixed.
>
> Thanks!
>
> Best Regards,
> Zhang Wei
Paul,
I had earlier requested a "Hold" on this series of patches
until I was able to see it work on my system too.
I have now been able to get working code here, but it
required a follow up set of 3 patches that I wrote.
So: I will ACK these 5 from Zhang Wei, and then post
my 3 more patches. If you would, please pick these up!
Thanks,
jdl
^ permalink raw reply
* Re: pcimsg patch from eons ago
From: David Hawkins @ 2007-05-29 17:40 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux PPC
In-Reply-To: <fa686aa40705282240p936fda6wdd838b8e33977ab3@mail.gmail.com>
Grant Likely wrote:
> Adrian,
>
> Way back in the 2.2 timeframe, you had modified the ARM pcimsg patch
> to port it to PPC and add features.
>
> http://www.cs.helsinki.fi/linux/linux-kernel/2001-07/0572.html
>
> I'd really like to take a look at it. I've been unable to find the
> patch archived anywhere online in my searching. Do you still have a
> copy of it tucked away anywhere?
>
Hey Grant,
TCP/IP over PCI is also something I want to look into.
I'll have about 8 compact PCI crates, with 15 MPC8349E boards
in each that I will boot with U-Boot, and then TFTP a kernel,
and then NFS mounted filesystem on. I'll put ethernet on
the front-panels for the prototype boards, but ideally
I want TCP/IP over PCI for the final system.
The board support package for the Freescale MPC8349E-MDS-PB
has some sort of support for this, but I haven't had a look
at the code yet.
I'm pretty sure Dan Malek had written something similar for
TCP/IP over RapidIO. Take a look in the kernel source,
I forget the name ... I have some notes around here somewhere ...
I'm working on hardware at the moment, so my software
brain cells are lying dormant. Let me know if you want
me to dig up the Freescale stuff and I'll send it to you,
or send you a link to a copy of the ISO. Downloading the
BSP from Freescale's site is a nightmare. I can also
plug the MDS board in as a peripheral and fire up their
TCP/IP over PCI and see what works.
It really shouldn't be too much trouble to get working.
I started by looking at the PLIP code just to see what
that took, and its pretty short. The most work would
be in defining infrastructure to make adding DMA of
data between the host CPU and the peripherals flexible.
Most (all?) x86 hosts don't have DMA, so both write and
read would be handled by the peripheral board. However,
for PPC hosts with DMA, then writes should be handled
by the respective boards ... I'm not sure what the
easiest way to deal with that would be.
Feel free to start a discussion on this :)
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH v2]: Fix e500 v2 core reboot bug
From: Andy Fleming @ 2007-05-29 17:38 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1180406209.8139.13.camel@localhost.localdomain>
On May 28, 2007, at 21:36, Zang Roy-r61911 wrote:
> Fix the e500 v2 core reset bug.
> For e500 v2 core, a new reset control register is added to
> reset the core.
> On 85xx CDS board with e500 v2 core, normal reboot code will
> induce DDR block in u-boot. This patch fixes this bug. It is
> also tested on legacy e500 v1 core.
>
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
^ permalink raw reply
* jffs2 boot errors
From: Ganesh Ragavan @ 2007-05-29 17:16 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]
Hi,
We have been using PPC with a AMD flash (Spansion S29GL128M) on it for our
applications. We are running Montavista linux on it. Recently we replaced
the AMD flash with ST flash (M29W128FH). The u-boot boots up and during the
kernel boot, I am getting the following error messages and the system
doesn't boot after this:
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000:
0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c:
0x2212 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020:
0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000003c:
0x2212 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000040:
0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000005c:
0x2212 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000060:
0x0020 instead
It would be really great if someone could let me know what is going wrong in
this.
Thanks,
Ganesh
[-- Attachment #2: Type: text/html, Size: 1359 bytes --]
^ permalink raw reply
* AMD to ST migration issues
From: Narayanan, Ganesh @ 2007-05-29 16:35 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Hi,
We have been using PPC with a AMD flash (Spansion S29GL128M) on it for
our applications. We are running Montavista linux on it. Recently we
replaced the AMD flash with ST flash (M29W128FH). The u-boot boots up
and during the kernel boot, I am getting the following error messages
and the system doesn't boot after this:
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000:
0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c:
0x2212 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020:
0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000003c:
0x2212 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000040:
0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000005c:
0x2212 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000060:
0x0020 instead
It would be really great if someone could let me know what is going
wrong in this.
Thanks,
Ganesh
[-- Attachment #2: Type: text/html, Size: 1655 bytes --]
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Geert Uytterhoeven @ 2007-05-29 16:21 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, linux-kernel, linux-scsi
In-Reply-To: <20070529104948.GC29351@lst.de>
On Tue, 29 May 2007, Christoph Hellwig wrote:
> > +/*
> > + * copy data from device into scatter/gather buffer
> > + */
> > +static int fill_from_dev_buffer(struct scsi_cmnd *cmd, const void *buf,
> > + int buflen)
> > +{
> > + int k, req_len, act_len, len, active;
> > + void *kaddr;
> > + struct scatterlist *sgpnt;
> > +
> > + if (!cmd->request_bufflen)
> > + return 0;
> > +
> > + if (!cmd->request_buffer)
> > + return DID_ERROR << 16;
> > +
> > + if (cmd->sc_data_direction != DMA_BIDIRECTIONAL &&
> > + cmd->sc_data_direction != DMA_FROM_DEVICE)
> > + return DID_ERROR << 16;
> > +
> > + if (!cmd->use_sg) {
> > + req_len = cmd->request_bufflen;
> > + act_len = min(req_len, buflen);
> > + memcpy(cmd->request_buffer, buf, act_len);
> > + cmd->resid = req_len - act_len;
> > + return 0;
> > + }
>
> This is never true anymore.
Just to be sure: all four if-cases or only the last one?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Geert Uytterhoeven @ 2007-05-29 15:54 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Arnd Bergmann, Ulrich Weigand, Steve Munroe, linuxppc-dev,
Paul Mackerras, Anton Blanchard
In-Reply-To: <624dd5293b5fde0ffdf01ea692c32e9c@kernel.crashing.org>
On Tue, 29 May 2007, Segher Boessenkool wrote:
> > right, as mentioned before, IP32L64 would imply introducing a new
> > ABI, which we don't want.
>
> Hey, you could hijack the mswindows ABI, no need to
> define your own ;-)
Isn't that (IL32)P64?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* BDI cfg file for MPC8349EMDS
From: Gregoire Banderet @ 2007-05-29 15:34 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm searching for a BDI2000 config file for the Freescale evaluation
board MPC8349EMDS.
Does someone have such file?
Thanks,
Greg
^ permalink raw reply
* Re: [RFC/PATCH 5/5] powerpc: Allow ptrace write to pt_regs trap
From: Ulrich Weigand @ 2007-05-29 15:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20070529064535.0C1E0DDFBC@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 05/29/2007
08:45:24 AM:
> This patch allows a ptracer to write to the "trap" word of the
> pt_regs. This, along with the previous patch, should enable gdb
> to properly handle syscall restarting after executing a separate
> function (at least when there's no restart block).
This doesn't look sufficient. If you want GDB to use the save/
restore style means of handling interrupted calls (like i386),
at the very least we also need the capability to *write* the
orig_gpr3 field, which is currently prohibited. (I don't know
why this is case, though.)
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
GNU compiler/toolchain for Linux on System z and Cell BE
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung:
Herbert Kircher
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
[-- Attachment #2: Type: text/html, Size: 1400 bytes --]
^ permalink raw reply
* Re: Latest GCC/GLIBC working combo for a Linux 2.4.x kernel?
From: Sasvata Chatterjee @ 2007-05-29 15:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20070525213909.5BC8C353428@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
Wolfgang,
Thanks for the pointer, and I am familiar with ELDK, since we are planning
on using it for a brand new embedded system.
On the older system, for which I started this thread, we need to use kernel
2.4. ELDK-4.1 is based on kernel 2.6.19. Is there an older ELDK I can get
that supported 2.4.x kernel with > 3.x GCC?
Thanks again!
Shash
PS: I have built gcc-4.1.1-glibc-2.3.6 cross-compiler for powerc-603e, and
working through compilation of kernel-2.4.26, but there are lots of problems
that I am needing to work through.
On 5/25/07, Wolfgang Denk <wd@denx.de> wrote:
>
>
> Did you have a look at the ELDK?
>
>
[-- Attachment #2: Type: text/html, Size: 941 bytes --]
^ permalink raw reply
* RE: How can I get a ramdisk.image for linux2.6 running on ML403?
From: Gerald Ruescher @ 2007-05-29 15:20 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <fa686aa40705290701h590998bfjc36385fa08a821d0@mail.gmail.com>
Grant Likely <grant.likely@secretlab.ca> wrote:
> On 5/29/07, angelalinyao@163.com <angelalinyao@163.com> wrote:
>
> > Is there any ramdisk.image provided for linux 2.6?
> > Or maybe I have to make a ramdisk by myself?
> > [...]
> > Any help from you is appreciated.Thank you!
>
> If you just want an out-of-the-box ramdisk, you can use the one in =
ELDK
>=20
> http://www.denx.de/wiki/DULG/ELDK
>=20
> Or, you can mount your existing ramdisk image on another Linux box and
> copy the needed files over. The /dev entries are the same across all
> architectures.
Additionally I'd like to point out that there is a nice and
well-written O'Reilly book called "Building Embedded Linux System"
by Karim Yaghmour. It contains a number of useful hints and techniques
for newbies, including a chapter about how to set up a root file
system for an embedded system using tools like BusyBox etc.
Some chapters may not be 100% up-to-date but still recommended=20
reading.
Kind regards,
Gerald
______________________________________________
Gerald R=FCscher
Software Development Engineer
Core Real-Time Implementation
dSPACE GmbH Tel.: +49 5251 1638-1826
Technologiepark 25 Fax: +49 5251 16198-1826
33100 Paderborn http://www.dspace.de
Germany mailto:GRuescher@dspace.de
_______________________________________________
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-29 14:49 UTC (permalink / raw)
To: Josh Boyer
Cc: Alexandre Bounine, David Gibson, Paul Mackerras,
linuxppc-dev list
In-Reply-To: <1180448346.3360.49.camel@zod.rchland.ibm.com>
>>> + compatible = "tsi-mdio";
>>
>> Hrm, did I miss this before? A more exact "compatible"
>> property would be better ("tsi109-mdio" "tsi108-mdio" or
>> something like that).
>
> If we must, then tsi108-mdio is what I would recommend. They are the
> same between 108, 109, and 110 as far as I know, so it's the lowest
> common denominator.
[Assuming what is really on the board is a tsi109...]
I recommend putting both 109 and 108 in the property, in
that order; that way, if you need to do something special
on the tsi109 implementation (something you might not yet
know about perhaps, maybe a bug; or some extra feature on
the tsi109 device that the driver doesn't handle yet), the
driver has a chance to do that. If the driver doesn't care
and only uses tsi108 features, it obviously can probe for
tsi108 only and all will be fine as well.
Segher
^ permalink raw reply
* Re: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs mount problems
From: Ben Warren @ 2007-05-29 14:52 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Linux PPC Linux PPC
In-Reply-To: <BAY115-W173A643AF082D78122CB6DB22F0@phx.gbl>
Hi Mohammad,
On Tue, 2007-05-29 at 14:41 +0000, Mohammad Sadegh Sadri wrote:
> Hi all,
>
> well I could bring up the grant's kernel on ml403 completely. the root file system was over nfs.
>
> when I use a 100mbits link for connection to ml403 , every thing is working suitably.
> but when I use a 1000mbits link, I see that ml403 gets ip address from dhcp and mounts the root file system but can not go further , it stops with a message: "nfs server not responding ...." some thing like this.
>
> when pinging to ml403 with 64 bytes packets, ping works fine for both of 100 and 1000mbits links
> but when I try to ping the board with 4000 bytes packets I notice that ml403 on gigabit link can not answer to ping packets, however on 100mbit link every thing works just fine.
>
> any ideas?
NFS is notorious for sending lots of big packets one right after
another. This can easily overwhelm an Ethernet receiver. Until you're
able to figure out why the 1000M link can't keep up, limit the NFS
receive packet sizes by passing the following NFS option in your kernel
command line:
rsize=1024
You can experiment with the value. I believe the NFS default size is
typically 8kB or greater.
regards,
Ben
^ permalink raw reply
* Re: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs mount problems
From: Andrei Konovalov @ 2007-05-29 14:57 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Linux PPC Linux PPC
In-Reply-To: <BAY115-W173A643AF082D78122CB6DB22F0@phx.gbl>
Mohammad Sadegh Sadri wrote:
> Hi all,
>
> well I could bring up the grant's kernel on ml403 completely. the root file system was over nfs.
>
> when I use a 100mbits link for connection to ml403 , every thing is working suitably.
> but when I use a 1000mbits link, I see that ml403 gets ip address from dhcp and mounts the root file system but can not go further , it stops with a message: "nfs server not responding ...." some thing like this.
>
> when pinging to ml403 with 64 bytes packets, ping works fine for both of 100 and 1000mbits links
> but when I try to ping the board with 4000 bytes packets I notice that ml403 on gigabit link can not answer to ping packets, however on 100mbit link every thing works just fine.
>
> any ideas?
TEMAC is in FIFO mode?
Try adding "nfsroot=,rsize=1024,wsize=1024" to cmdline?
Thanks,
Andrei
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Steve Munroe @ 2007-05-29 14:51 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <OF462E078D.FFB634FD-ON422572EA.004D1E28-422572EA.004DB265@de.ibm.com>
Ulrich Weigand <Ulrich.Weigand@de.ibm.com> wrote on 05/29/2007 09:08:39 AM:
>
> Steve Munroe <sjmunroe@us.ibm.com> wrote on 05/29/2007 04:00:42 PM:
>
> > Yes exactly why make an incompatible ABI change to the powerp32 ABI,
when
> > you can just use the existing 64-bit ABI.
> >
> > Especially as you can only run what is proposed on 64-bit hardware!
> >
> > We don't need another ABI change to powerpc32 (still recovering from
the
> > -msecure-plt ABI change) and WE DONT NEED a 3rd ABI.
> >
> > ABI changes ripple everywhere (not just GCC/GLIBC) including all
debuggers
> > and performance tools. Believe me you really don't want this.
>
> Fully agreed. This may have gotten lost in the discussion thread, but
what
> Ben originally proposed was *not* an ABI change, for exactly that reason.
> We simply want to allow strictly local use of 64-bit registers for
> performance optimization purposes, while still fully complying with
> the 32-bit ABI.
>
But unless you take the time to write it up like a full ABI change you are
never sure that it IS compatible. And any change to the size/shape of
ucontext_t is an ABI change.
Also if you want to debug this code (see long long variables correctly from
GDB or even see the upper 32-bits of GPRs) you will need an ABI change so
that GDB/DWARF knows what to do.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-29 14:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <200705291628.35852.arnd@arndb.de>
>> Just call them and trap the SEGV ;-) You can check the
>> aux vector of course, or ask glibc -- but the SEGV way
>> is the only really portable way. Strange world :-)
>
> shouldn't that be SIGILL?
Yes sir. Although you can do it with segmentation
faults as well, I did mean SIGILL.
>> ILP32LL64. The C "mode" stays the same, only the generated
>> machine insns are changed.
>
> right, as mentioned before, IP32L64 would imply introducing a new
> ABI, which we don't want.
Hey, you could hijack the mswindows ABI, no need to
define your own ;-)
Segher
^ permalink raw reply
* Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs mount problems
From: Mohammad Sadegh Sadri @ 2007-05-29 14:41 UTC (permalink / raw)
To: Linux PPC Linux PPC
Hi all,
well I could bring up the grant's kernel on ml403 completely. the root file=
system was over nfs.=20
when I use a 100mbits link for connection to ml403 , every thing is working=
suitably.
but when I use a 1000mbits link, I see that ml403 gets ip address from dhcp=
and mounts the root file system but can not go further , it stops with a m=
essage: "nfs server not responding ...." some thing like this.
when pinging to ml403 with 64 bytes packets, ping works fine for both of 10=
0 and 1000mbits links
but when I try to ping the board with 4000 bytes packets I notice that ml40=
3 on gigabit link can not answer to ping packets, however on 100mbit link e=
very thing works just fine.
any ideas?
_________________________________________________________________
Connect to the next generation of MSN Messenger=A0
http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc=
e=3Dwlmailtagline=
^ 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