* Re: 2 Ethernet port operating in a PPC405EP system
From: Otto Solares @ 2006-08-31 22:07 UTC (permalink / raw)
To: Chun Chung Lo; +Cc: linuxppc-embedded
In-Reply-To: <A7B1E4DD46AA7046A4398F745240F29402737D5F@ASPROEXG.astri.local>
On Thu, Aug 31, 2006 at 08:54:19AM +0800, Chun Chung Lo wrote:
> Hi,
Hi.
> I really do not know what happened about MediaMVP, could you mind giving
> me a review?
Sure, the problem with the MediaMVP is that it ships with a real old
and buggy kernel (specially the NIC driver) and with propietary kernel
modules, so you can't really upgrade the kernel.
I was succesful in booting a 2.6 kernel but without drivers for the
special hw I lost interest.
So I really hate vendors shipping buggy old kernels, that's all. :)
-otto
^ permalink raw reply
* Re: 2 Ethernet port operating in a PPC405EP system
From: Otto Solares @ 2006-08-31 22:08 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20060831011903.GB8863@gate.crashing.org>
On Wed, Aug 30, 2006 at 08:19:03PM -0500, Matt Porter wrote:
> On Wed, Aug 30, 2006 at 01:23:03PM -0500, Otto Solares wrote:
> > Don't repeat the same mistake as the MediaMVP, it uses the same
> > processor and same kernel version, it sucks badly...
>
> FWIW, MediaMVP doesn't use the same processor. It has an
> STBx25xx which is quite different from a 405EP. It is
> the same 405 core at least.
You're right. And kernel is 2.4.17 not 2.4.19 as I stated.
-otto
^ permalink raw reply
* Simple module, but won't build
From: Steven Kaiser @ 2006-08-31 22:55 UTC (permalink / raw)
To: linuxppc-embedded
Hi gurus:
Newbie here. I am using ELDK 3.1.1, 2.4.25 kernel, and a Lite5200b board.
I run the kernel in RAM, and mount a filesystem via NFS. So far so good,
and I move on to trying to build a simple module to write to a few LEDs.
Simple hello world modules compile and insmod/rmmod fine, but when I try to
#include <asm/io.h>, here I have the exact same problem as Richard Danter
did: CONFIG_KERNEL_START and CONFIG_TASK_SIZE are not defined anywhere in
any headers-- just in the config files.
http://ozlabs.org/pipermail/linuxppc-embedded/2004-May/014037.html
My little wrinkle to add to this problem is I have recompiled the kernel, as
advised in the replies to Richard's post, with the 'Set Custom Kernel Base
Address' and 'Set Custom user task size' options enabled, but in my case I
still I cannot find CONFIG_KERNEL_START and CONFIG_TASK_SIZE defined
anywhere noteworthy.
My 'include/linux/autoconf.h' file is empty, and I don't even have an
'include/config/' directory at all. Where in the steps of recompiling the
kernel should these files and directories get generated?
My process for building the kernel is:
$ cd /opt/eldk/usr/src/linuxppc_2_4_devel
$ make mrproper
$ make lite5200b_config
$ make menuconfig
$ make dep
$ make uImage
$ cp arch/ppc/boot/images/uImage /tftpboot/MPC5200/uImage
I can manually include CONFIG_KERNEL_START and CONFIG_TASK_SIZE in my module
source, compile, insmod, and all goes well (except my LEDs don't light up
but first things first).
When my kernel boots, I get a few gripes which I think are related to this
issue:
Finding module dependencies: depmod: Can't open
/lib/modules/2.4.25/modules.deg [FAILED]
modprobe: Can't open dependencies file /lib/modules/2.4.25/modules.dep (No
such)
Young and foolish, I figured maybe I should try:
$ make modules
$ make modules_install
Oops. That was bad. Now I cannot even compile the simplest hello.c module
without a page of errors, the first being a complaint of not being able to
find linux/autoconf.h. Before I only had trouble when I tried to #include
<asm/io.h>, now it happens 100% of the time.
So I went back and turned off module support, recompiled the kernel, and
still cannot compile hello.c. I also tried recompiling the kernel after
doing a "make oldconfig", and still cannot compile a simple module anymore.
I think I am going to have to go back to square 1 and reinstall ELDK and
everything from scratch. But before I do:
Any insight into the generation of autoconf.h, and whereabouts this file
should come from? I will watch for it when I redo the whole process.
Steven Kaiser
Chemistry Electronics Facility
University of California, Irvine
2347 Natural Sciences 2
Irvine, CA 92697-2025
(949)824-7520
^ permalink raw reply
* RE: Rattler 8347 and USB 2.0
From: Li Yang-r58472 @ 2006-09-01 2:54 UTC (permalink / raw)
To: Jamie Guinan, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0608291535260.23035@gemini.home.net>
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.o
> rg] On Behalf Of Jamie Guinan
> Sent: Friday, September 01, 2006 12:14 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Rattler 8347 and USB 2.0
>=20
>=20
> Greetings,
>=20
> I have an mpc8347 board here (A&M Rattler 8347). It shipped with a
> 2.6.16 patched enough to boot the board, but support for=20
> freescale USB 2.0 (ehci) is not present.
>=20
> Working my way backwards in the mainline kernel tree=20
> (2.6.18-rc5), I found drivers/usb/host/ehci-fsl.c, for=20
> FreeScale/PPC EHCI support.
>=20
> In that module, usb_hcd_fsl_probe() requires an initialized=20
> "struct fsl_usb2_platform_data", which only appears in=20
> arch/powerpc/sysdev/fsl_soc.c, yet the 2.6.16 patch provided=20
> puts the board in arch/ppc.
>=20
> My question is, what would be the best way to go about=20
> getting ehci-fsl.c working with this board?
>=20
> 1) Nudge the Rattler port from arch/ppc to arch/powerpc. One=20
> problem with this is that the rattler uses RedBoot, and reading this,
>=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/024116.html
>=20
> it looks like arch/powerpc wants to boot from=20
> OpenFirmware-like "flattened device tree" (does RedBoot=20
> support this?).
Use a shim which directly builds FDT in kernel to use powerpc arch.
>=20
> 2) Support ehci-fsl.c from arch/ppc. If arch/ppc is=20
> deprecated, that's a bad long-term solution. And since=20
> fsl_soc.c lives under arch/powerpc, that doesn't look good either.
Actually you don't need fsl_soc.c in ppc arch. There are predefined
platform_device and platform_data in arch/ppc/syslib/mpc83xx_devices.c.
You can add your usb platform_data there easily.
^ permalink raw reply
* Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Aleck Lin @ 2006-09-01 2:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.5.1157076003.7568.linuxppc-embedded@ozlabs.org>
Hi,
I'm working on booting kernel 2.6 on Xilinx. And I'm encountering a few
problems.=20
1. When I directly download zImage.elf to the RAM and boot from there, I =
see
the kernel starts booting, but it complains about not being able to =
mount
/dev/sysace/disc0/part2 and thus kernel panic happens.
The following is the output
---------------------------------------------------------------
loaded at: 00400000 004D313C
board data at: 004D1124 004D113C
relocated to: 004050F8 00405110
zimage at: 0040580D 004D0AA8
avail ram: 004D4000 04000000
Linux/PPC load: console=3DttyS0,9600 ip=3Doff =
root=3D/dev/xsysace/disc0/part2 rw
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.17.8 (aleck@sac.gdatech.com) (gcc =
version
4.0.0 (DENX ELDK 4.0 4.0.0)) #2 Thu Aug 31 11:49:40 PDT 2006
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Built 1 zonelists
[ 0.000000] Kernel command line: console=3DttyS0,9600 ip=3Doff
root=3D/dev/xsysace/disc0/part2 rw
[ 0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[ 0.000176] Console: colour dummy device 80x25
[ 0.000676] Dentry cache hash table entries: 8192 (order: 3, 32768 =
bytes)
[ 0.001452] Inode-cache hash table entries: 4096 (order: 2, 16384 =
bytes)
[ 0.015453] Memory: 63104k available (1268k kernel code, 468k data, =
80k
init, 0k highmem)
[ 0.204374] Mount-cache hash table entries: 512
[ 0.209943] NET: Registered protocol family 16
[ 0.218843] NET: Registered protocol family 2
[ 0.264481] IP route cache hash table entries: 512 (order: -1, 2048
bytes)
[ 0.265267] TCP established hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.265465] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.265569] TCP: Hash tables configured (established 2048 bind 1024)
[ 0.265599] TCP reno registered
[ 0.272471] io scheduler noop registered
[ 0.272558] io scheduler anticipatory registered (default)
[ 0.272626] io scheduler deadline registered
[ 0.272759] io scheduler cfq registered
[ 0.318755] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharing disabled
[ 0.323749] serial8250.0: ttyS0 at MMIO 0xa0001003 (irq =3D 9) is a =
16450
[ 2.026296] RAMDISK driver initialized: 16 RAM disks of 65536K size =
1024
blocksize
[ 2.117598] tun: Universal TUN/TAP device driver, 1.6
[ 2.177338] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 2.252474] mice: PS/2 mouse device common for all mice
[ 2.314381] TCP bic registered
[ 2.350802] NET: Registered protocol family 1
[ 2.402825] NET: Registered protocol family 17
[ 2.458051] VFS: Cannot open root device "xsysace/disc0/part2" or
unknown-block(0,0)
[ 2.549979] Please append a correct "root=3D" boot option
[ 2.612426] Kernel panic - not syncing: VFS: Unable to mount root fs =
on
unknown-block(0,0)
[ 2.711373] <0>Rebooting in 180 seconds..<NULL>
-----------------------------------------------------------
2. When I tried to boot the zImage (sitting in the flash) from u-boot =
file
(generated from the same source code as uImage.elf), as soon as it gives =
the
control to the kernel, no messages would come. I checked to make sure =
that I
had the right serial port setting (console=3DttyS0,9600), but still =
nothing
shows up.
Here's the output of what I had (I turned on some extra debug msg in =
u-boot)
-------------------------------------------
### No HW ID - assuming ML403
DRAM: 64 MB
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 5 =08=08=08 4 =08=08=08 3 =08=08=08 2 =
=08=08=08 0=20
=3D> bootm 0xffa00000
## Booting image at ffa00000 ...
Image Name: Linux-2.6.17.8
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 832155 Bytes =3D 812.7 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x03E62B70 =3D> set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF3A
memstart =3D 0x00000000
memsize =3D 0x04000000
flashstart =3D 0xFF800000
flashsize =3D 0x00800000
flashoffset =3D 0x00000000
sramstart =3D 0x00000000
sramsize =3D 0x00000000
bootflags =3D 0x40401003
procfreq =3D 300 MHz
plb_busfreq =3D 100 MHz
ethaddr =3D 00:0A:35:00:22:01
IP addr =3D 192.168.10.111
baudrate =3D 9600 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
------------------------------------------------------------
3. Lastly, whenever I issue a reset command in u-boot, it just locks up =
and
hangs. I have to do a hardware reset every time. I'm wondering if the =
reset
vector is going to a wrong place. How would I check that?
I'm fairly new to the whole embedded domain. Please feel free to help. =
It
would be much appreciated! Thanks.
Aleck
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Keith Mannthey @ 2006-09-01 3:08 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco,
Linux Kernel Mailing List, Linux Memory Management List
In-Reply-To: <Pine.LNX.4.64.0608311906300.13392@skynet.skynet.ie>
On 8/31/06, Mel Gorman <mel@csn.ul.ie> wrote:
> On Thu, 31 Aug 2006, Keith Mannthey wrote:
> > On 8/31/06, Mel Gorman <mel@skynet.ie> wrote:
> >> On (30/08/06 13:57), Keith Mannthey didst pronounce:
> >> > On 8/21/06, Mel Gorman <mel@csn.ul.ie> wrote:
> >> > >
> Can you confirm that happens by applying the patch I sent to you and
> checking the output? When the reserve fails, it should print out what
> range it actually checked. I want to be sure it's not checking the
> addresses 0->0x1070000000
See below
> >> > >@@ -329,6 +330,8 @@ acpi_numa_memory_affinity_init(struct ac
> >> > >
> >> > > printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
> >> > > nd->start, nd->end);
> >> > >+ e820_register_active_regions(node, nd->start >> PAGE_SHIFT,
> >> > >+ nd->end >> PAGE_SHIFT);
> >> >
> >> > A node chunk in this section of code may be a hot-pluggable zone. With
> >> > MEMORY_HOTPLUG_SPARSE we don't want to register these regions.
> >> >
> >>
> >> The ranges should not get registered as active memory by
> >> e820_register_active_regions() unless they are marked E820_RAM. My
> >> understanding is that the regions for hotadd would be marked "reserved"
> >> in the e820 map. Is that wrong?
> >
> > This is wrong. In a mult-node system that last node add area will not
> > be marked reserved by the e820. The e820 only defines memory <
> > end_pfn. the last node add area is > end_pfn.
> >
>
> ok, that should still be fine. As long as the ranges are not marked
> "usable", add_active_range() will not be called and the holes should be
> counted correctly with the patch I sent you.
>
> > With RESERVE based add-memory you want the add-areas repored by the
> > srat to be setup during boot like all the other pages.
> >
>
> So, do you actally expect a lot of unused mem_map to be allocated with
> struct pages that are inactive until memory is hot-added in an
> x86_64-specific manner? The arch-independent stuff currently will not do
> that. It sets up memmap for where memory really exists. If that is not
> what you expect, it will hit issues at hotadd time which is not the
> current issue but one that can be fixed.
Yes. RESERVED based is a big waste of mem_map space. The add areas
are marked as RESERVED during boot and then later onlined during add.
It might be ok. I will play with tomorrow. I might just need to
call add_active_range in the right spot :)
> >> > > if (ma->flags.hot_pluggable && !reserve_hotadd(node, start, end)
> >> <
> >> > > 0) {
> >> > > /* Ignore hotadd region. Undo damage */
> >> >
> >> > I have but the e820_register_active_regions as a else to this
> >> > statment the absent pages check fails.
> >> >
> >>
> >> The patch below omits this change because I think
> >> e820_register_active_regions() will still have got called by the time
> >> you encounter a hotplug area.
> >
> > called but then removed in setup arch.
>
> By "removed", I assume you mean the active regions removed by the call
> to remove_all_active_regions() in setup_arch(). Before reserve_hotadd() is
> called, e820_register_active_regions() will have reregistered the active
> regions with the NUMA node id.
I see e820_register_active_regions is acting as a filter against the e820
> >> > Also nodes_cover_memory and alot of these check were based against
> >> > comparing the srat data against the e820. Now all this code is
> >> > comparing SRAT against SRAT....
> >> >
> >>
> >> I don't see why. The SRAT table passes a range to
> >> e820_register_active_regions() so should be comparing SRAT to e820
> >
> > let me go off and look at e820_register_active_regions() some more.
Things get clear :)
Should be ok.
> > Sure thing. It is just the hot-add area I am guessing it is an off by
> > one error of some sort.
> >
See below. I do my e820_register_active_area as an else to to if
(hotplug.....!reserve) and the prink is easy to sort out.
I see your pfn are in base 10. Looks like it considers the last
addres to be a present page. (off by one thing).
Thanks,
Keith
Output below
disabling early console
Linux version 2.6.18-rc4-mm3-smp (root@elm3a153) (gcc version 4.1.0
(SUSE Linux)) #6 SMP Thu Aug 31 22:06:00 EDT 2006
Command line: root=/dev/sda3
ip=9.47.66.153:9.47.66.169:9.47.66.1:255.255.255.0 resume=/dev/sda2
showopts earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0
debug numa=hotadd=100
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000098400 (usable)
BIOS-e820: 0000000000098400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007ff85e00 (usable)
BIOS-e820: 000000007ff85e00 - 000000007ff98880 (ACPI data)
BIOS-e820: 000000007ff98880 - 0000000080000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000470000000 (usable)
BIOS-e820: 0000001070000000 - 0000001160000000 (usable)
Entering add_active_range(0, 0, 152) 0 entries of 3200 used
Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
Entering add_active_range(0, 17235968, 18219008) 3 entries of 3200 used
end_pfn_map = 18219008
DMI 2.3 present.
ACPI: RSDP (v000 IBM ) @ 0x00000000000fdcf0
ACPI: RSDT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98800
ACPI: FADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98780
ACPI: MADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98600
ACPI: SRAT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff983c0
ACPI: HPET (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98380
ACPI: SSDT (v001 IBM VIGSSDT0 0x00001000 INTL 0x20030122) @
0x000000007ff90780
ACPI: SSDT (v001 IBM VIGSSDT1 0x00001000 INTL 0x20030122) @
0x000000007ff88bc0
ACPI: DSDT (v001 IBM EXA01ZEU 0x00001000 INTL 0x20030122) @
0x0000000000000000
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 0 -> APIC 2 -> Node 0
SRAT: PXM 0 -> APIC 3 -> Node 0
SRAT: PXM 0 -> APIC 38 -> Node 0
SRAT: PXM 0 -> APIC 39 -> Node 0
SRAT: PXM 0 -> APIC 36 -> Node 0
SRAT: PXM 0 -> APIC 37 -> Node 0
SRAT: PXM 1 -> APIC 64 -> Node 1
SRAT: PXM 1 -> APIC 65 -> Node 1
SRAT: PXM 1 -> APIC 66 -> Node 1
SRAT: PXM 1 -> APIC 67 -> Node 1
SRAT: PXM 1 -> APIC 102 -> Node 1
SRAT: PXM 1 -> APIC 103 -> Node 1
SRAT: PXM 1 -> APIC 100 -> Node 1
SRAT: PXM 1 -> APIC 101 -> Node 1
SRAT: Node 0 PXM 0 0-80000000
Entering add_active_range(0, 0, 152) 0 entries of 3200 used
Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
SRAT: Node 0 PXM 0 0-470000000
Entering add_active_range(0, 0, 152) 2 entries of 3200 used
Entering add_active_range(0, 256, 524165) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-1070000000
reserve_hotadd called with node 0 sart 470000000 end 1070000000
SRAT: Hotplug area has existing memory
Entering add_active_range(0, 0, 152) 3 entries of 3200 used
Entering add_active_range(0, 256, 524165) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 4653056) 3 entries of 3200 used
SRAT: Node 1 PXM 1 1070000000-1160000000
Entering add_active_range(1, 17235968, 18219008) 3 entries of 3200 used
SRAT: Node 1 PXM 1 1070000000-3200000000
reserve_hotadd called with node 1 sart 1160000000 end 3200000000
SRAT: Hotplug area has existing memory
Entering add_active_range(1, 17235968, 18219008) 4 entries of 3200 used
NUMA: Using 28 for the hash shift.
Bootmem setup node 0 0000000000000000-0000001070000000
Bootmem setup node 1 0000001070000000-0000001160000000
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 18219008
early_node_map[4] active PFN ranges
0: 0 -> 152
0: 256 -> 524165
0: 1048576 -> 4653056
1: 17235968 -> 18219008
On node 0 totalpages: 4128541
0 pages used for SPARSE memmap
1149 pages DMA reserved
DMA zone: 2843 pages, LIFO batch:0
0 pages used for SPARSE memmap
DMA32 zone: 520069 pages, LIFO batch:31
0 pages used for SPARSE memmap
Normal zone: 3604480 pages, LIFO batch:31
On node 1 totalpages: 983040
0 pages used for SPARSE memmap
0 pages used for SPARSE memmap
0 pages used for SPARSE memmap
Normal zone: 983040 pages, LIFO batch:31
^ permalink raw reply
* Re: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-01 3:33 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, inux-kernel,
Rajesh Shah
In-Reply-To: <20060831175001.GE8704@austin.ibm.com>
On Fri, 2006-09-01 at 01:50, Linas Vepstas wrote:
> On Thu, Aug 31, 2006 at 03:10:12PM +0800, Zhang, Yanmin wrote:
> > Linas,
> >
> > I am reviewing the error handlers of e1000 driver and got some ideas. My
> > startpoint is to simplify the err handler implementations for drivers, or
> > driver developers are *not willing* to add it if it's too complicated.
>
> I don't see that its to complicated ...
Originally, I didn't think so, but after I try to add err_handlers to some
drivers, I feel it's too complicated.
>
> > 1) Callback mmio_enabled looks useless. Documentation/pci-error-recovery.txt
> > says the current powerpc implementation does not implement this callback.
>
> I don't know if its useless or not. I have not needed it yet for the
> symbios, ipr and e1000 drivers, but its possible that some more
> sophisticated device may want it. I'm tempted to keep it a while
> longer befoe discarding it.
>
> The scenario is this: the device driver decides that, rather than asking
> for a full electical reset of the card, instead, it wants to perform
> its own recovery. It can do this as follows:
>
> a) enable MMIO
> b) issue reset command to adapter
> c) enable DMA.
>
> If we enabled both DMA and MMIO at the same time, there are mnay cases
> where the card will immediately trap again -- for example, if its
> DMA'ing to some crazy address. Thus, typically, one wants DMA disabled
> until after the card reset. Withouth the mmio_enabled() reset, there
> is no way of doing this.
The new error_resume, or the old slot_reset could take care of it. The specific
device driver knows all the details about how to initiate the devices. The
error_resume could call the step a) b) c) sequencially while doing checking among
steps.
If there is really a device having specific requirement to reinitiate it (very rarely),
it could use walkaround, such like schedule a WORKER. No need to provide a generic
mmio_enabled.
> > 2) Callback slot_reset could be merged with resume. The new resume could be:
> > int (*error_resume)(struct pci_dev *dev); I checked e1000 and e100 drivers and
> > think there is no actual reason to have both slot_reset and resume.
>
> The idea here was to handle multi-function cards. On a multi-function card,
> *all* devices need to indicate that they were able to reset. Once all devices
> have been successfuly reset, then operation can be resumed. If the reset
> of one function fails, then operation is not resumed for any f the
> functions.
I don't think we need slot_reset to coordinate multi-function devices. The new
error_resume could take care of multi-function card. 'reset' here means driver
need do I/O to detect if the device (function) still works well. If a function
of a multi-function device couldn't reset while other functions could reset,
other functions could just go on to reinitiate. In the end, the error recovery
procedure (handle_eeh_events in PowerPC implementation) could check all the
returning values of error_resume. If there is a failure value, then removes
all the functions' pci_dev of the device from the bus.
>
> > 3) link_reset is not used in pci express aer implementation, so it could be
> > deleted also.
>
> OK. Link reset was added explicitly to support PCI-E, so if its not wanted,
> we can eliminate it.
>
> > How did you test e1000 err_handler?
>
> We have three methods (I thought these were documented). In one, a
> technician brushes a grounding strap to some of the signal pins.
> In the second, slots are populated with known-bad cards. The third test
> involes sending a command down to the pci bridge chip, telling it to
> behave as if it detected an error. For development, the last is
> quick-n-easy.
Thanks for your explanation.
>
> > In the simulated enviroment, the testing might be
> > incorrect.
>
> Why would it be incorrect? I mean, we don't simulate having someone pour a
> cup of coffee into the guts of the machine ... but my understanding is
> the machines do get standard vibration/thermal/humidity testing, which
> is good enough for me.
>
> > For example, e1000_io_error_detected would call e1000_down to reset NIC.
>
> Why would that be incorrect?
>
> > During
> > our last discussion on LKML, you said PowerPC will block further I/O if the platform captures
> > a pci error, so the all I/O in e1000_down will be blocked. Later on, e1000_io_slot_reset
> > will reenable pci device and initiate NIC. I guess late initiate might fail because prior
> > e1000_down I/O don't reach NIC.
>
> Why would it fail? The e1000_down serves primarily to get the Linux
> kernel into a known state. It doesn't matter what happens to the card,
> since the next step will be to perform an electrical reset of the card.
Who will perform the electrical reset of the card? Function e1000_reset or the platform?
If it's the platform, I agree with you, but if it's e1000_reset, it might not work because
e1000_reset uses a e1000-specific approach to reset the card. I'm not sure if the e1000_reset
will restore the NIC to fresh system power-on state. At least, from the source codes, e1000_reset
couldn't.
^ permalink raw reply
* Re: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-01 3:42 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <20060831175001.GE8704@austin.ibm.com>
On Fri, 2006-09-01 at 01:50, Linas Vepstas wrote:
> On Thu, Aug 31, 2006 at 03:10:12PM +0800, Zhang, Yanmin wrote:
> > Linas,
> >
> > I am reviewing the error handlers of e1000 driver and got some ideas. My
> > startpoint is to simplify the err handler implementations for drivers, or
> > driver developers are *not willing* to add it if it's too complicated.
>
> I don't see that its to complicated ...
Originally, I didn't think so, but after I try to add err_handlers to some
drivers, I feel it's too complicated.
>
> > 1) Callback mmio_enabled looks useless. Documentation/pci-error-recovery.txt
> > says the current powerpc implementation does not implement this callback.
>
> I don't know if its useless or not. I have not needed it yet for the
> symbios, ipr and e1000 drivers, but its possible that some more
> sophisticated device may want it. I'm tempted to keep it a while
> longer befoe discarding it.
>
> The scenario is this: the device driver decides that, rather than asking
> for a full electical reset of the card, instead, it wants to perform
> its own recovery. It can do this as follows:
>
> a) enable MMIO
> b) issue reset command to adapter
> c) enable DMA.
>
> If we enabled both DMA and MMIO at the same time, there are mnay cases
> where the card will immediately trap again -- for example, if its
> DMA'ing to some crazy address. Thus, typically, one wants DMA disabled
> until after the card reset. Withouth the mmio_enabled() reset, there
> is no way of doing this.
The new error_resume, or the old slot_reset could take care of it. The specific
device driver knows all the details about how to initiate the devices. The
error_resume could call the step a) b) c) sequencially while doing checking among
steps.
If there is really a device having specific requirement to reinitiate it (very rarely),
it could use walkaround, such like schedule a WORKER. No need to provide a generic
mmio_enabled.
>
> > 2) Callback slot_reset could be merged with resume. The new resume could be:
> > int (*error_resume)(struct pci_dev *dev); I checked e1000 and e100 drivers and
> > think there is no actual reason to have both slot_reset and resume.
>
> The idea here was to handle multi-function cards. On a multi-function card,
> *all* devices need to indicate that they were able to reset. Once all devices
> have been successfuly reset, then operation can be resumed. If the reset
> of one function fails, then operation is not resumed for any f the
> functions.
I don't think we need slot_reset to coordinate multi-function devices. The new
error_resume could take care of multi-function card. 'reset' here means driver
need do I/O to detect if the device (function) still works well. If a function
of a multi-function device couldn't reset while other functions could reset,
other functions could just go on to reinitiate. In the end, the error recovery
procedure (handle_eeh_events in PowerPC implementation) could check all the
returning values of error_resume. If there is a failure value, then removes
all the functions' pci_dev of the device from the bus.
>
> > 3) link_reset is not used in pci express aer implementation, so it could be
> > deleted also.
>
> OK. Link reset was added explicitly to support PCI-E, so if its not wanted,
> we can eliminate it.
>
> > How did you test e1000 err_handler?
>
> We have three methods (I thought these were documented). In one, a
> technician brushes a grounding strap to some of the signal pins.
> In the second, slots are populated with known-bad cards. The third test
> involes sending a command down to the pci bridge chip, telling it to
> behave as if it detected an error. For development, the last is
> quick-n-easy.
Thanks for your explanation.
>
> > In the simulated enviroment, the testing might be
> > incorrect.
>
> Why would it be incorrect? I mean, we don't simulate having someone pour a
> cup of coffee into the guts of the machine ... but my understanding is
> the machines do get standard vibration/thermal/humidity testing, which
> is good enough for me.
>
> > For example, e1000_io_error_detected would call e1000_down to reset NIC.
>
> Why would that be incorrect?
>
> > During
> > our last discussion on LKML, you said PowerPC will block further I/O if the platform captures
> > a pci error, so the all I/O in e1000_down will be blocked. Later on, e1000_io_slot_reset
> > will reenable pci device and initiate NIC. I guess late initiate might fail because prior
> > e1000_down I/O don't reach NIC.
>
> Why would it fail? The e1000_down serves primarily to get the Linux
> kernel into a known state. It doesn't matter what happens to the card,
> since the next step will be to perform an electrical reset of the card.
Who will perform the electrical reset of the card? Function e1000_reset or the platform?
If it's the platform, I agree with you, but if it's e1000_reset, it might not work because
e1000_reset uses a e1000-specific approach to reset the card. I'm not sure if the e1000_reset
will restore the NIC to fresh system power-on state. At least, from the source codes, e1000_reset
couldn't.
Yanmin
^ permalink raw reply
* Re: Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Wolfgang Denk @ 2006-09-01 7:35 UTC (permalink / raw)
To: Aleck Lin; +Cc: linuxppc-embedded
In-Reply-To: <000a01c6cd6e$5e1970a0$800101df@monstertop>
In message <000a01c6cd6e$5e1970a0$800101df@monstertop> you wrote:
>
> 1. When I directly download zImage.elf to the RAM and boot from there, I see
...
> 2. When I tried to boot the zImage (sitting in the flash) from u-boot file
When you use U-Boot, you should use the correct image (uImage).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every little picofarad has a nanohenry all its own. - Don Vonada
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-09-01 8:33 UTC (permalink / raw)
To: Keith Mannthey
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco,
Linux Kernel Mailing List, Linux Memory Management List
In-Reply-To: <a762e240608312008v3e35b63ay46c95fbb6c3f15ec@mail.gmail.com>
On Thu, 31 Aug 2006, Keith Mannthey wrote:
> On 8/31/06, Mel Gorman <mel@csn.ul.ie> wrote:
>> On Thu, 31 Aug 2006, Keith Mannthey wrote:
>> > On 8/31/06, Mel Gorman <mel@skynet.ie> wrote:
>> >> On (30/08/06 13:57), Keith Mannthey didst pronounce:
>> >> > On 8/21/06, Mel Gorman <mel@csn.ul.ie> wrote:
>> >> > >
>
>> Can you confirm that happens by applying the patch I sent to you and
>> checking the output? When the reserve fails, it should print out what
>> range it actually checked. I want to be sure it's not checking the
>> addresses 0->0x1070000000
>
> See below
>
Perfect, thanks a lot. I should have enough to reproduce without a test
machine what is going on and develop the required patches.
>> >> > >@@ -329,6 +330,8 @@ acpi_numa_memory_affinity_init(struct ac
>> >> > >
>> >> > > printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
>> >> > > nd->start, nd->end);
>> >> > >+ e820_register_active_regions(node, nd->start >> PAGE_SHIFT,
>> >> > >+ nd->end >>
>> PAGE_SHIFT);
>> >> >
>> >> > A node chunk in this section of code may be a hot-pluggable zone. With
>> >> > MEMORY_HOTPLUG_SPARSE we don't want to register these regions.
>> >> >
>> >>
>> >> The ranges should not get registered as active memory by
>> >> e820_register_active_regions() unless they are marked E820_RAM. My
>> >> understanding is that the regions for hotadd would be marked "reserved"
>> >> in the e820 map. Is that wrong?
>> >
>> > This is wrong. In a mult-node system that last node add area will not
>> > be marked reserved by the e820. The e820 only defines memory <
>> > end_pfn. the last node add area is > end_pfn.
>> >
>>
>> ok, that should still be fine. As long as the ranges are not marked
>> "usable", add_active_range() will not be called and the holes should be
>> counted correctly with the patch I sent you.
>>
>> > With RESERVE based add-memory you want the add-areas repored by the
>> > srat to be setup during boot like all the other pages.
>> >
>>
>> So, do you actally expect a lot of unused mem_map to be allocated with
>> struct pages that are inactive until memory is hot-added in an
>> x86_64-specific manner? The arch-independent stuff currently will not do
>> that. It sets up memmap for where memory really exists. If that is not
>> what you expect, it will hit issues at hotadd time which is not the
>> current issue but one that can be fixed.
>
> Yes. RESERVED based is a big waste of mem_map space.
Right, it's all very clear now. At some point in the future, I'd like to
visit why SPARSEMEM-based hot-add is not always used but it's a separate
issue.
> The add areas
> are marked as RESERVED during boot and then later onlined during add.
That explains the reserve_bootmem_node()
> It might be ok. I will play with tomorrow. I might just need to
> call add_active_range in the right spot :)
>
I'll play with this from the opposite perspective - what is required for
any arch using this API to have spare memmap for reserve-based hot-add.
>> >> > > if (ma->flags.hot_pluggable && !reserve_hotadd(node, start,
>> end)
>> >> <
>> >> > > 0) {
>> >> > > /* Ignore hotadd region. Undo damage */
>> >> >
>> >> > I have but the e820_register_active_regions as a else to this
>> >> > statment the absent pages check fails.
>> >> >
>> >>
>> >> The patch below omits this change because I think
>> >> e820_register_active_regions() will still have got called by the time
>> >> you encounter a hotplug area.
>> >
>> > called but then removed in setup arch.
>>
>> By "removed", I assume you mean the active regions removed by the call
>> to remove_all_active_regions() in setup_arch(). Before reserve_hotadd() is
>> called, e820_register_active_regions() will have reregistered the active
>> regions with the NUMA node id.
>
> I see e820_register_active_regions is acting as a filter against the e820
>
Yes. A range of pfn's in given to e820_register_active_regions() and it
reads the e820 for E820_RAM sections within that range.
>> >> > Also nodes_cover_memory and alot of these check were based against
>> >> > comparing the srat data against the e820. Now all this code is
>> >> > comparing SRAT against SRAT....
>> >> >
>> >>
>> >> I don't see why. The SRAT table passes a range to
>> >> e820_register_active_regions() so should be comparing SRAT to e820
>> >
>> > let me go off and look at e820_register_active_regions() some more.
> Things get clear :)
>
> Should be ok.
>
nice.
>> > Sure thing. It is just the hot-add area I am guessing it is an off by
>> > one error of some sort.
>> >
> See below. I do my e820_register_active_area as an else to to if
> (hotplug.....!reserve) and the prink is easy to sort out.
>
yep, it should be easy to put this into a test program.
> I see your pfn are in base 10. Looks like it considers the last
> addres to be a present page. (off by one thing).
>
Probably. I'll start poking now. Thanks a lot.
> Thanks,
> Keith
>
> Output below
> disabling early console
> Linux version 2.6.18-rc4-mm3-smp (root@elm3a153) (gcc version 4.1.0
> (SUSE Linux)) #6 SMP Thu Aug 31 22:06:00 EDT 2006
> Command line: root=/dev/sda3
> ip=9.47.66.153:9.47.66.169:9.47.66.1:255.255.255.0 resume=/dev/sda2
> showopts earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0
> debug numa=hotadd=100
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000098400 (usable)
> BIOS-e820: 0000000000098400 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000007ff85e00 (usable)
> BIOS-e820: 000000007ff85e00 - 000000007ff98880 (ACPI data)
> BIOS-e820: 000000007ff98880 - 0000000080000000 (reserved)
> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000470000000 (usable)
> BIOS-e820: 0000001070000000 - 0000001160000000 (usable)
> Entering add_active_range(0, 0, 152) 0 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
> Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
> Entering add_active_range(0, 17235968, 18219008) 3 entries of 3200 used
> end_pfn_map = 18219008
> DMI 2.3 present.
> ACPI: RSDP (v000 IBM ) @ 0x00000000000fdcf0
> ACPI: RSDT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98800
> ACPI: FADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98780
> ACPI: MADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98600
> ACPI: SRAT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff983c0
> ACPI: HPET (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98380
> ACPI: SSDT (v001 IBM VIGSSDT0 0x00001000 INTL 0x20030122) @
> 0x000000007ff90780
> ACPI: SSDT (v001 IBM VIGSSDT1 0x00001000 INTL 0x20030122) @
> 0x000000007ff88bc0
> ACPI: DSDT (v001 IBM EXA01ZEU 0x00001000 INTL 0x20030122) @
> 0x0000000000000000
> SRAT: PXM 0 -> APIC 0 -> Node 0
> SRAT: PXM 0 -> APIC 1 -> Node 0
> SRAT: PXM 0 -> APIC 2 -> Node 0
> SRAT: PXM 0 -> APIC 3 -> Node 0
> SRAT: PXM 0 -> APIC 38 -> Node 0
> SRAT: PXM 0 -> APIC 39 -> Node 0
> SRAT: PXM 0 -> APIC 36 -> Node 0
> SRAT: PXM 0 -> APIC 37 -> Node 0
> SRAT: PXM 1 -> APIC 64 -> Node 1
> SRAT: PXM 1 -> APIC 65 -> Node 1
> SRAT: PXM 1 -> APIC 66 -> Node 1
> SRAT: PXM 1 -> APIC 67 -> Node 1
> SRAT: PXM 1 -> APIC 102 -> Node 1
> SRAT: PXM 1 -> APIC 103 -> Node 1
> SRAT: PXM 1 -> APIC 100 -> Node 1
> SRAT: PXM 1 -> APIC 101 -> Node 1
> SRAT: Node 0 PXM 0 0-80000000
> Entering add_active_range(0, 0, 152) 0 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
> SRAT: Node 0 PXM 0 0-470000000
> Entering add_active_range(0, 0, 152) 2 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 2 entries of 3200 used
> Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
> SRAT: Node 0 PXM 0 0-1070000000
> reserve_hotadd called with node 0 sart 470000000 end 1070000000
> SRAT: Hotplug area has existing memory
> Entering add_active_range(0, 0, 152) 3 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 3 entries of 3200 used
> Entering add_active_range(0, 1048576, 4653056) 3 entries of 3200 used
> SRAT: Node 1 PXM 1 1070000000-1160000000
> Entering add_active_range(1, 17235968, 18219008) 3 entries of 3200 used
> SRAT: Node 1 PXM 1 1070000000-3200000000
> reserve_hotadd called with node 1 sart 1160000000 end 3200000000
> SRAT: Hotplug area has existing memory
> Entering add_active_range(1, 17235968, 18219008) 4 entries of 3200 used
> NUMA: Using 28 for the hash shift.
> Bootmem setup node 0 0000000000000000-0000001070000000
> Bootmem setup node 1 0000001070000000-0000001160000000
> Zone PFN ranges:
> DMA 0 -> 4096
> DMA32 4096 -> 1048576
> Normal 1048576 -> 18219008
> early_node_map[4] active PFN ranges
> 0: 0 -> 152
> 0: 256 -> 524165
> 0: 1048576 -> 4653056
> 1: 17235968 -> 18219008
> On node 0 totalpages: 4128541
> 0 pages used for SPARSE memmap
> 1149 pages DMA reserved
> DMA zone: 2843 pages, LIFO batch:0
> 0 pages used for SPARSE memmap
> DMA32 zone: 520069 pages, LIFO batch:31
> 0 pages used for SPARSE memmap
> Normal zone: 3604480 pages, LIFO batch:31
> On node 1 totalpages: 983040
> 0 pages used for SPARSE memmap
> 0 pages used for SPARSE memmap
> 0 pages used for SPARSE memmap
> Normal zone: 983040 pages, LIFO batch:31
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* RE: Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Ming Liu @ 2006-09-01 8:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000a01c6cd6e$5e1970a0$800101df@monstertop>
Hi Aleck,
>1. When I directly download zImage.elf to the RAM and boot from there, I
see
>the kernel starts booting, but it complains about not being able to mount
>/dev/sysace/disc0/part2 and thus kernel panic happens.
>
>The following is the output
>---------------------------------------------------------------
>loaded at: 00400000 004D313C
>board data at: 004D1124 004D113C
>relocated to: 004050F8 00405110
>zimage at: 0040580D 004D0AA8
>avail ram: 004D4000 04000000
>
>Linux/PPC load: console=ttyS0,9600 ip=off root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
>[ 0.000000] Linux version 2.6.17.8 (aleck@sac.gdatech.com) (gcc version
>4.0.0 (DENX ELDK 4.0 4.0.0)) #2 Thu Aug 31 11:49:40 PDT 2006
>[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
>[ 0.000000] Built 1 zonelists
>[ 0.000000] Kernel command line: console=ttyS0,9600 ip=off
>root=/dev/xsysace/disc0/part2 rw
>[ 0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
>[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
>[ 0.000176] Console: colour dummy device 80x25
>[ 0.000676] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
>[ 0.001452] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
>[ 0.015453] Memory: 63104k available (1268k kernel code, 468k data, 80k
>init, 0k highmem)
>[ 0.204374] Mount-cache hash table entries: 512
>[ 0.209943] NET: Registered protocol family 16
>[ 0.218843] NET: Registered protocol family 2
>[ 0.264481] IP route cache hash table entries: 512 (order: -1, 2048
>bytes)
>[ 0.265267] TCP established hash table entries: 2048 (order: 1, 8192
>bytes)
>[ 0.265465] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
>[ 0.265569] TCP: Hash tables configured (established 2048 bind 1024)
>[ 0.265599] TCP reno registered
>[ 0.272471] io scheduler noop registered
>[ 0.272558] io scheduler anticipatory registered (default)
>[ 0.272626] io scheduler deadline registered
>[ 0.272759] io scheduler cfq registered
>[ 0.318755] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
>sharing disabled
>[ 0.323749] serial8250.0: ttyS0 at MMIO 0xa0001003 (irq = 9) is a 16450
>[ 2.026296] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024
>blocksize
>[ 2.117598] tun: Universal TUN/TAP device driver, 1.6
>[ 2.177338] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
>[ 2.252474] mice: PS/2 mouse device common for all mice
>[ 2.314381] TCP bic registered
>[ 2.350802] NET: Registered protocol family 1
>[ 2.402825] NET: Registered protocol family 17
>[ 2.458051] VFS: Cannot open root device "xsysace/disc0/part2" or
>unknown-block(0,0)
>[ 2.549979] Please append a correct "root=" boot option
>[ 2.612426] Kernel panic - not syncing: VFS: Unable to mount root fs on
>unknown-block(0,0)
>[ 2.711373] <0>Rebooting in 180 seconds..<NULL>
>-----------------------------------------------------------
>
Try this:
mount the CF card onto your PC and then goto the /dev folder on your
root filesystem in the card. Here run the following commands as root:
# mknod -m 660 console c 5 1
# mknod -m 660 xsa b 254 0
# mknod -m 660 xsa1 b 254 1
# mknod -m 660 xsa2 b 254 2
# mknod -m 660 xsa3 b 254 3
Now there should be a directory tts in your dev. If not create one
"mkdir tts". Then do this in the dev/tts folder,
# mknod -m 660 0 c 4 64
If you don't need CF card at all, the easiest method to solve it is to
remove it from the linux kernel configuration.
Regards
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* pdata->phy_id
From: Fredrik Roubert @ 2006-09-01 8:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
Hi!
When running a newer kernel on the MPC8349E-mITX development board, I do
the following changes to mpc834x_sys.c in order to get the PHY working:
diff -urN linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c
--- linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-06 22:02:28.000000000 +0200
+++ linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-24 10:10:36.000000000 +0200
@@ -130,7 +130,7 @@
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id = 0;
- pdata->phy_id = 0;
+ pdata->phy_id = 0x1c;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
@@ -138,7 +138,7 @@
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id = 0;
- pdata->phy_id = 1;
+ pdata->phy_id = 0x1f;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
Is this really the best way to do it, or would it be preferable to do it
some other way?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mika Penttilä @ 2006-09-01 8:46 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco,
Linux Kernel Mailing List, Linux Memory Management List,
Keith Mannthey
In-Reply-To: <Pine.LNX.4.64.0609010928010.25057@skynet.skynet.ie>
>
> Right, it's all very clear now. At some point in the future, I'd like
> to visit why SPARSEMEM-based hot-add is not always used but it's a
> separate issue.
>
>> The add areas
>> are marked as RESERVED during boot and then later onlined during add.
>
> That explains the reserve_bootmem_node()
>
But pages are marked reserved by default. You still have to alloc the
bootmem map for the the whole node range, including reserve hot add
areas and areas beyond e820-end-of-ram. So all the areas are already
reserved, until freed.
--Mika
^ permalink raw reply
* Re: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-01 9:04 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <1157082169.20092.174.camel@ymzhang-perf.sh.intel.com>
On Fri, 2006-09-01 at 11:42, Zhang, Yanmin wrote:
> On Fri, 2006-09-01 at 01:50, Linas Vepstas wrote:
> > On Thu, Aug 31, 2006 at 03:10:12PM +0800, Zhang, Yanmin wrote:
> > > Linas,
> > >
> > > I am reviewing the error handlers of e1000 driver and got some ideas. My
> > > startpoint is to simplify the err handler implementations for drivers, or
> > > driver developers are *not willing* to add it if it's too complicated.
> >
> > I don't see that its to complicated ...
> Originally, I didn't think so, but after I try to add err_handlers to some
> drivers, I feel it's too complicated.
>
> >
> > > 1) Callback mmio_enabled looks useless. Documentation/pci-error-recovery.txt
> > > says the current powerpc implementation does not implement this callback.
> >
> > I don't know if its useless or not. I have not needed it yet for the
> > symbios, ipr and e1000 drivers, but its possible that some more
> > sophisticated device may want it. I'm tempted to keep it a while
> > longer befoe discarding it.
> >
> > The scenario is this: the device driver decides that, rather than asking
> > for a full electical reset of the card, instead, it wants to perform
> > its own recovery. It can do this as follows:
> >
> > a) enable MMIO
> > b) issue reset command to adapter
> > c) enable DMA.
> >
> > If we enabled both DMA and MMIO at the same time, there are mnay cases
> > where the card will immediately trap again -- for example, if its
> > DMA'ing to some crazy address. Thus, typically, one wants DMA disabled
> > until after the card reset. Withouth the mmio_enabled() reset, there
> > is no way of doing this.
> The new error_resume, or the old slot_reset could take care of it. The specific
> device driver knows all the details about how to initiate the devices. The
> error_resume could call the step a) b) c) sequencially while doing checking among
> steps.
>
> If there is really a device having specific requirement to reinitiate it (very rarely),
> it could use walkaround, such like schedule a WORKER. No need to provide a generic
> mmio_enabled.
>
> >
> > > 2) Callback slot_reset could be merged with resume. The new resume could be:
> > > int (*error_resume)(struct pci_dev *dev); I checked e1000 and e100 drivers and
> > > think there is no actual reason to have both slot_reset and resume.
> >
> > The idea here was to handle multi-function cards. On a multi-function card,
> > *all* devices need to indicate that they were able to reset. Once all devices
> > have been successfuly reset, then operation can be resumed. If the reset
> > of one function fails, then operation is not resumed for any f the
> > functions.
> I don't think we need slot_reset to coordinate multi-function devices. The new
> error_resume could take care of multi-function card. 'reset' here means driver
> need do I/O to detect if the device (function) still works well. If a function
> of a multi-function device couldn't reset while other functions could reset,
> other functions could just go on to reinitiate. In the end, the error recovery
> procedure (handle_eeh_events in PowerPC implementation) could check all the
> returning values of error_resume. If there is a failure value, then removes
> all the functions' pci_dev of the device from the bus.
>
> >
> > > 3) link_reset is not used in pci express aer implementation, so it could be
> > > deleted also.
> >
> > OK. Link reset was added explicitly to support PCI-E, so if its not wanted,
> > we can eliminate it.
> >
> > > How did you test e1000 err_handler?
> >
> > We have three methods (I thought these were documented). In one, a
> > technician brushes a grounding strap to some of the signal pins.
> > In the second, slots are populated with known-bad cards. The third test
> > involes sending a command down to the pci bridge chip, telling it to
> > behave as if it detected an error. For development, the last is
> > quick-n-easy.
> Thanks for your explanation.
>
> >
> > > In the simulated enviroment, the testing might be
> > > incorrect.
> >
> > Why would it be incorrect? I mean, we don't simulate having someone pour a
> > cup of coffee into the guts of the machine ... but my understanding is
> > the machines do get standard vibration/thermal/humidity testing, which
> > is good enough for me.
> >
> > > For example, e1000_io_error_detected would call e1000_down to reset NIC.
> >
> > Why would that be incorrect?
> >
> > > During
> > > our last discussion on LKML, you said PowerPC will block further I/O if the platform captures
> > > a pci error, so the all I/O in e1000_down will be blocked. Later on, e1000_io_slot_reset
> > > will reenable pci device and initiate NIC. I guess late initiate might fail because prior
> > > e1000_down I/O don't reach NIC.
> >
> > Why would it fail? The e1000_down serves primarily to get the Linux
> > kernel into a known state. It doesn't matter what happens to the card,
> > since the next step will be to perform an electrical reset of the card.
> Who will perform the electrical reset of the card? Function e1000_reset or the platform?
> If it's the platform, I agree with you, but if it's e1000_reset, it might not work because
> e1000_reset uses a e1000-specific approach to reset the card. I'm not sure if the e1000_reset
> will restore the NIC to fresh system power-on state. At least, from the source codes, e1000_reset
> couldn't.
One more comment: The second parameter of error_detected also could be deleted
because recovery procedures will save error to pci_dev->error_state.
So, the err_handler pci_error_handlers could be:
struct pci_error_handlers
{
pci_ers_result_t (*error_detected)(struct pci_dev *dev);
pci_ers_result_t (*error_resume)(struct pci_dev *dev);
};
Yanmin
^ permalink raw reply
* Re: Simple module, but won't build
From: Josu Onandia @ 2006-09-01 6:35 UTC (permalink / raw)
To: Steven Kaiser; +Cc: linuxppc-embedded
In-Reply-To: <000001c6cd50$8c0196f0$6e4ec880@volt>
Steven Kaiser wrote:
>Hi gurus:
>
>Newbie here. I am using ELDK 3.1.1, 2.4.25 kernel, and a Lite5200b board.
>I run the kernel in RAM, and mount a filesystem via NFS. So far so good,
>and I move on to trying to build a simple module to write to a few LEDs.
>
>Simple hello world modules compile and insmod/rmmod fine, but when I try to
>#include <asm/io.h>, here I have the exact same problem as Richard Danter
>did: CONFIG_KERNEL_START and CONFIG_TASK_SIZE are not defined anywhere in
>any headers-- just in the config files.
>
>http://ozlabs.org/pipermail/linuxppc-embedded/2004-May/014037.html
>
>My little wrinkle to add to this problem is I have recompiled the kernel, as
>advised in the replies to Richard's post, with the 'Set Custom Kernel Base
>Address' and 'Set Custom user task size' options enabled, but in my case I
>still I cannot find CONFIG_KERNEL_START and CONFIG_TASK_SIZE defined
>anywhere noteworthy.
>
>My 'include/linux/autoconf.h' file is empty, and I don't even have an
>'include/config/' directory at all. Where in the steps of recompiling the
>kernel should these files and directories get generated?
>
>My process for building the kernel is:
>
>$ cd /opt/eldk/usr/src/linuxppc_2_4_devel
>$ make mrproper
>$ make lite5200b_config
>$ make menuconfig
>$ make dep
>$ make uImage
>$ cp arch/ppc/boot/images/uImage /tftpboot/MPC5200/uImage
>
>I can manually include CONFIG_KERNEL_START and CONFIG_TASK_SIZE in my module
>source, compile, insmod, and all goes well (except my LEDs don't light up
>but first things first).
>
>When my kernel boots, I get a few gripes which I think are related to this
>issue:
>
>Finding module dependencies: depmod: Can't open
>/lib/modules/2.4.25/modules.deg [FAILED]
>modprobe: Can't open dependencies file /lib/modules/2.4.25/modules.dep (No
>such)
>
>Young and foolish, I figured maybe I should try:
>
>$ make modules
>$ make modules_install
>
>Oops. That was bad. Now I cannot even compile the simplest hello.c module
>without a page of errors, the first being a complaint of not being able to
>find linux/autoconf.h. Before I only had trouble when I tried to #include
><asm/io.h>, now it happens 100% of the time.
>
>So I went back and turned off module support, recompiled the kernel, and
>still cannot compile hello.c. I also tried recompiling the kernel after
>doing a "make oldconfig", and still cannot compile a simple module anymore.
>I think I am going to have to go back to square 1 and reinstall ELDK and
>everything from scratch. But before I do:
>
>Any insight into the generation of autoconf.h, and whereabouts this file
>should come from? I will watch for it when I redo the whole process.
>
>Steven Kaiser
>Chemistry Electronics Facility
>University of California, Irvine
>2347 Natural Sciences 2
>Irvine, CA 92697-2025
>(949)824-7520
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
I can help you with the leds part of your problem. Below is some simple
code to manage the leds in a Lite5200b.
About the rest of the problem, I can't tell, because my linux/autoconf.h
is OK, and I can include asm/io.h in my modules without problem. To
reinstall everything from scratch is a good idea.
I'm writing modules for a Lite5200b right now, using RTAI. I use the
leds to do some 'visual debugging'. You can contact me directly if you want.
#include <asm/mpc5xxx.h>
struct mpc5xxx_wu_gpio {
volatile u32 enable;
volatile u32 ode;
volatile u32 dir;
volatile u32 data; };
static void configure_leds(void)
{
struct mpc5xxx_gpio *gpio;
struct mpc5xxx_wu_gpio *wu_gpio;
gpio = (struct mpc5xxx_gpio*) MPC5xxx_GPIO;
wu_gpio = (struct mpc5xxx_wu_gpio*)MPC5xxx_WU_GPIO;
gpio->port_config &= ~(0x00f00000);
gpio->simple_gpioe |= 0x30000000;
gpio->simple_ddr |= 0x30000000;
gpio->simple_dvo |= 0x30000000;
wu_gpio->enable |= 0x30000000;
wu_gpio->ode &= ~0x30000000;
wu_gpio->dir |= 0x30000000;
}
static void led_off(int led)
{
struct mpc5xxx_gpio *gpio;
struct mpc5xxx_wu_gpio *wu_gpio;
gpio = (struct mpc5xxx_gpio*) MPC5xxx_GPIO;
wu_gpio = (struct mpc5xxx_wu_gpio*)MPC5xxx_WU_GPIO;
switch( led)
{
case 1:
wu_gpio->data |= 0x20000000;
break;
case 2:
gpio->simple_dvo |= 0x10000000;
break;
case 3:
wu_gpio->data |= 0x10000000;
break;
case 4:
gpio->simple_dvo |= 0x20000000;
break;
default:
break;
}
}
static void led_on(int led)
{
struct mpc5xxx_gpio *gpio;
struct mpc5xxx_wu_gpio *wu_gpio;
gpio = (struct mpc5xxx_gpio*) MPC5xxx_GPIO;
wu_gpio = (struct mpc5xxx_wu_gpio*)MPC5xxx_WU_GPIO;
switch(led)
{
case 1:
wu_gpio->data &= ~0x20000000;
break;
case 2:
gpio->simple_dvo &= ~0x10000000;
break;
case 3:
wu_gpio->data &= ~0x10000000;
break;
case 4:
gpio->simple_dvo &= ~0x20000000;
break;
default:
break;
}
}
^ permalink raw reply
* Backtrace
From: Matias Sundman (AS/EAB) @ 2006-09-01 6:48 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
Comrades,
I would like to do a backtrace in kernel space similar to an oops but then continue the code flow as before i.e. without a crash.
If someone has done anything similar, help and/or tips would be much appreciated!
Cheers //
Matias Sundman
Senior Sw Designer
Ericssonl
IS Ethernet Switch, DIPN
Ericsson AB
Box 1505 Office: +46 8 719 86 83
SE-125 25 ÄLVSJÖ ECN: 850 98683
SWEDEN Mobile: +46 70 267 2405
Visiting address: E-mail: Matias.Sundman@ericsson.com
Armborstvägen 14 Web: http://www.ericsson.com
Älvsjö, STOCKHOLM
[-- Attachment #2: Type: text/html, Size: 2741 bytes --]
^ permalink raw reply
* RE: pdata->phy_id
From: Claus Gindhart @ 2006-09-01 9:49 UTC (permalink / raw)
To: Fredrik Roubert, linuxppc-embedded
In-Reply-To: <20060901085602.GD15795@igloo.df.lth.se>
Hi Frederick,
if your board is somehow similiar to the MPC834x-SYS, but not exactly =
identical, i would copy the file mpc834x_sys.c and .h to .e.g =
mpc8349_mitx.c and .h; add a config option to the Kconfig within this =
directory, and an entry to the Makefile.
Then, you can add all the HW-specific modifications here.
--=20
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
=20
-----Original Message-----
From: linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org=
]
On Behalf Of Fredrik Roubert
Sent: Freitag, 1. September 2006 10:56
To: linuxppc-embedded@ozlabs.org
Subject: pdata->phy_id
Hi!
When running a newer kernel on the MPC8349E-mITX development board, I do
the following changes to mpc834x_sys.c in order to get the PHY working:
diff -urN linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c =
linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c
--- linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-06 =
22:02:28.000000000 +0200
+++ linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-24 =
10:10:36.000000000 +0200
@@ -130,7 +130,7 @@
if (pdata) {
pdata->board_flags =3D FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id =3D 0;
- pdata->phy_id =3D 0;
+ pdata->phy_id =3D 0x1c;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
@@ -138,7 +138,7 @@
if (pdata) {
pdata->board_flags =3D FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id =3D 0;
- pdata->phy_id =3D 1;
+ pdata->phy_id =3D 0x1f;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
Is this really the best way to do it, or would it be preferable to do it
some other way?
Cheers // Fredrik Roubert
--=20
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
^ permalink raw reply
* Re: Backtrace
From: KokHow Teh @ 2006-09-01 10:12 UTC (permalink / raw)
To: matias.sundman; +Cc: linuxppc-embedded
Hi;
Is using hardware/software breakpoint with a hardware debugger wh=
at
you are looking for?
Regards,
Teh
"Matias Sundman \(AS/EAB\)" <matias.sundman@ericsson.com>@ozlabs.org on=
09/01/2006 02:48:43 PM
Sent by: linuxppc-embedded-bounces+kokhow.teh=3Dmarconi.com@ozlabs.o=
rg
To: <linuxppc-embedded@ozlabs.org>
cc:
Subject: Backtrace
Comrades,
I would like to do a backtrace in kernel space similar to an oops but t=
hen
continue the code flow as before i.e. without a crash.
If someone has done anything similar, help and/or tips would be much
appreciated!
Cheers //
Matias Sundman
Senior Sw Designer
Ericssonl
IS Ethernet Switch, DIPN
Ericsson AB
Box 1505=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=
Office: +46=A0 8 719 86 83
SE-125 25 =C4LVSJ=D6=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 ECN:=A0=
=A0=A0 850 98683
SWEDEN=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Mobile: +46 70 26=
7 2405
Visiting address:=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0E-mail: Matias=
.Sundman@ericsson.com
Armborstv=E4gen 14=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Web:=A0=A0=
=A0 http://www.ericsson.com
=C4lvsj=F6, STOCKHOLM
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=
^ permalink raw reply
* RE: Backtrace
From: Matias Sundman (AS/EAB) @ 2006-09-01 10:49 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Örjan Gustavsson (AS/EAB)
In-Reply-To: <OFAC529115.08187271-ON482571DC.003802B3@uk.marconicomms.com>
=20
Hello,
We have HW debuggers ; Windriver ICE and BDI2000 , but in our specific =
scenario the system is up=20
and running and we cannot be breakpoint intrusive, other parts of the =
system would be affected ( and our own blade ).
No, what we would like to do is that when a specific condition is met a =
backtrace printout
is performed and after that the system runs as designed.
:
[Existing code]
:=20
:
if ( some_variable =3D=3D my_condition )
{
print_out_backtrace();
}
:
:
[Existing code]
:=20
:
We have implemented "forced" kernel ooops:es in "print_out_backtrace();" =
but we would like to=20
have controlled backtraces ;-))
This is in Kernel space on a ppc8270.=20
Cheers // Matias
-----Original Message-----
From: KokHow Teh [mailto:KokHow.Teh@marconi.com]=20
Sent: den 1 september 2006 12:13
To: Matias Sundman (AS/EAB)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Backtrace
Hi;
Is using hardware/software breakpoint with a hardware debugger =
what
you are looking for?
Regards,
Teh
"Matias Sundman \(AS/EAB\)" <matias.sundman@ericsson.com>@ozlabs.org on
09/01/2006 02:48:43 PM
Sent by: =
linuxppc-embedded-bounces+kokhow.teh=3Dmarconi.com@ozlabs.org
To: <linuxppc-embedded@ozlabs.org>
cc:
Subject: Backtrace
Comrades,
I would like to do a backtrace in kernel space similar to an oops but =
then
continue the code flow as before i.e. without a crash.
If someone has done anything similar, help and/or tips would be much
appreciated!
Cheers //
Matias Sundman
Senior Sw Designer
Ericssonl
IS Ethernet Switch, DIPN
Ericsson AB
Box 1505=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0 Office: +46=A0 8 719 86 83
SE-125 25 =C4LVSJ=D6=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
ECN:=A0=A0=A0 850 98683
SWEDEN=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Mobile: +46 70 267 =
2405
Visiting address:=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0E-mail: =
Matias.Sundman@ericsson.com
Armborstv=E4gen 14=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
Web:=A0=A0=A0 http://www.ericsson.com
=C4lvsj=F6, STOCKHOLM
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 82xx fcc_enet problem between Linux 2.4 and 2.6
From: Bastos Fernandez Alexandre @ 2006-09-01 11:43 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <002101c6cd25$6945e470$5201a8c0@GEG2400>
Laurent,
>
> I work on several custom 82xx boards with Linux 2.4 and 2.6.
>
> I have ported Linux 2.6.9 on different boards and I noticed
> that I have tx carrier errors on my FCC ports. Almost one
> error per xmit.
>
I have experienced same problem. I suppose you are using the old
fcc driver in /arch/ppc
> I reinstalled Linux 2.4.18 on these boards and I have NO ERROR.
>
> The errors arise with PHY configured in 100M full duplex (or autoneg).
> The FCC has the same duplex as PHY.
Are you sure? In my case, the problem was that while the PHY had autoneg
to full-duplex, the MAC kept in half-duplex mode
> [...]
>
> I think this is not a phy or hardware problem but rather a FCC configuration
> mismatch in fcc_enet.c.
>
Yes. But I thing the driver has been obsoleted by fs_enet one,
so modifiying it now has no sense.
Best regards,
Alex BASTOS
^ permalink raw reply
* Re: Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Jeff Angielski @ 2006-09-01 13:49 UTC (permalink / raw)
To: Aleck Lin; +Cc: linuxppc-embedded
In-Reply-To: <000a01c6cd6e$5e1970a0$800101df@monstertop>
On Thu, 2006-08-31 at 19:28 -0700, Aleck Lin wrote:
> Hi,
>
> I'm working on booting kernel 2.6 on Xilinx. And I'm encountering a few
> problems.
>
> 1. When I directly download zImage.elf to the RAM and boot from there, I see
> the kernel starts booting, but it complains about not being able to mount
> /dev/sysace/disc0/part2 and thus kernel panic happens.
Can u-boot access the systemace CF?
Do the kernel statup messages show that the system ace driver is loaded
and has successfully initialized? I don't see this in your boot message
dump.
Jeff Angielski
The PTR Group
^ permalink raw reply
* RE: 82xx fcc_enet problem between Linux 2.4 and 2.6
From: Laurent Lagrange @ 2006-09-01 14:26 UTC (permalink / raw)
To: 'Bastos Fernandez Alexandre'; +Cc: linuxppc-embedded
In-Reply-To: <1157111000.44f81cd8cb6d6@webmail.televes.com:443>
Hello Alex,
> > I have ported Linux 2.6.9 on different boards and I noticed
> > that I have tx carrier errors on my FCC ports. Almost one
> > error per xmit.
> I have experienced same problem. I suppose you are using the old
> fcc driver in /arch/ppc
Yes that's right.
> > I reinstalled Linux 2.4.18 on these boards and I have NO ERROR.
> > The errors arise with PHY configured in 100M full duplex (or autoneg).
> > The FCC has the same duplex as PHY.
> Are you sure? In my case, the problem was that while the PHY had autoneg
> to full-duplex, the MAC kept in half-duplex mode
I have modified some code in fcc_enet.c for Linux 2.4 to manage PHY as I
wanted.
Perhaps was I in luck to correct something wrong. I checked that the duplex
were identical for FCC and PHY and I had no carrier error.
> > I think this is not a phy or hardware problem but rather a
> FCC configuration mismatch in fcc_enet.c.
> Yes. But I think the driver has been obsoleted by fs_enet one,
> so modifiying it now has no sense.
Yes I retreived fs_enet in Linux 2.6.15 and I'll try it.
This driver seems to appear in Linux 2.6.11 tree not before.
Is it right ?
Thanks very much for your reply.
Best regards
Laurent
^ permalink raw reply
* [PATCH] Add new, missing argument to of_irq_map_raw().
From: Jon Loeliger @ 2006-09-01 15:17 UTC (permalink / raw)
To: linuxppc-dev
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
^ permalink raw reply related
* Re: Backtrace
From: Carlos Munoz @ 2006-09-01 16:42 UTC (permalink / raw)
To: Matias Sundman (AS/EAB); +Cc: linuxppc-embedded
In-Reply-To: <24521B9781EAC745A4BE65966F69C9BE02BACDA8@esealmw115.eemea.ericsson.se>
Matias Sundman (AS/EAB) wrote:
> Comrades,
> I would like to do a backtrace in kernel space similar to an oops but
> then continue the code flow as before i.e. without a crash.
>
Try dump_stack(). It should do what you want.
Carlos
^ permalink raw reply
* Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Aleck Lin @ 2006-09-01 17:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.3.1157101919.2423.linuxppc-embedded@ozlabs.org>
Sorry ,that was a typo, I did use "uImage"
Thanks,
Aleck
>
> 1. When I directly download zImage.elf to the RAM and boot from there, I
see
...
> 2. When I tried to boot the zImage (sitting in the flash) from u-boot file
When you use U-Boot, you should use the correct image (uImage).
Best regards,
Wolfgang Denk
^ 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