* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-28 15:10 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0708281642520.4960-100000@slslc02.psi.ch>
On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> 8. I have typed: md 0x20f0c4 100 and it showed me the buffer:
>
> 0020f0c4: 3c353e5b 20202020 302e3030 30303030 <5>[ 0.000000
> 0020f0d4: 5d204c69 6e757820 76657273 696f6e20 ] Linux version
> 0020f0e4: 322e362e 32312d72 63362028 726f6f74 2.6.21-rc6 (root
> 0020f0f4: 40706335 32313529 20286763 63207665 @pc5215) (gcc ve
> 0020f104: 7273696f 6e20342e 302e3229 20233136 rsion 4.0.2) #16
> 0020f114: 204d6f6e 20417567 20323720 31323a33 Mon Aug 27 12:3
> 0020f124: 373a3038 20434553 54203230 30370a3c 7:08 CEST 2007.<
> 0020f134: 363e5b20 20202030 2e303030 3030305d 6>[ 0.000000]
> 0020f144: 2058696c 696e7820 4d4c3430 33205265 Xilinx ML403 Re
> 0020f154: 66657265 6e636520 53797374 656d2028 ference System (
> 0020f164: 56697274 65782d34 20465829 0a3c373e Virtex-4 FX).<7>
> 0020f174: 5b202020 20302e30 30303030 305d2045 [ 0.000000] E
> 0020f184: 6e746572 696e6720 6164645f 61637469 ntering add_acti
> 0020f194: 76655f72 616e6765 28302c20 302c2038 ve_range(0, 0, 8
> 0020f1a4: 31393129 20302065 6e747269 6573206f 191) 0 entries o
> 0020f1b4: 66203235 36207573 65640a3c 343e5b20 f 256 used.<4>[
> 0020f1c4: 20202030 2e303030 3030305d 205a6f6e 0.000000] Zon
> 0020f1d4: 65205046 4e207261 6e676573 3a0a3c34 e PFN ranges:.<4
>
> So it seams to be that the address points to the __log_buf (I hope).
>
> Does it mean that when I try to start zImage kernel from u-boot
> it hangs during uncompressing the image and it does even start booting?
Think about what you're looking at. That buffer is ASCII text. Does
it look like the entire buffer is displayed, or does it look like
there is more?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-28 15:00 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708280650t41046711g4161cc0c5be05d16@mail.gmail.com>
Hi Grant,
I have did as you suggested:
1. I have started u-boot
2. I have loaded zImage.elf to the memory 0xf00000
3. I have typed: bootelf 0xf00000
Linux has hanged during uncompressing
4. I have stopped the system and reloaded u-boot to examine __log_buf
( address 0x20f0c4)
Unfortunately all the bytes were set just to zero.
5. I have stopped the system
6. I have downloaded via jtag the zImage.elf and started it
the system has started properly
7. I have stopped the system and reloaded u-boot to examine the memory
8. I have typed: md 0x20f0c4 100 and it showed me the buffer:
0020f0c4: 3c353e5b 20202020 302e3030 30303030 <5>[ 0.000000
0020f0d4: 5d204c69 6e757820 76657273 696f6e20 ] Linux version
0020f0e4: 322e362e 32312d72 63362028 726f6f74 2.6.21-rc6 (root
0020f0f4: 40706335 32313529 20286763 63207665 @pc5215) (gcc ve
0020f104: 7273696f 6e20342e 302e3229 20233136 rsion 4.0.2) #16
0020f114: 204d6f6e 20417567 20323720 31323a33 Mon Aug 27 12:3
0020f124: 373a3038 20434553 54203230 30370a3c 7:08 CEST 2007.<
0020f134: 363e5b20 20202030 2e303030 3030305d 6>[ 0.000000]
0020f144: 2058696c 696e7820 4d4c3430 33205265 Xilinx ML403 Re
0020f154: 66657265 6e636520 53797374 656d2028 ference System (
0020f164: 56697274 65782d34 20465829 0a3c373e Virtex-4 FX).<7>
0020f174: 5b202020 20302e30 30303030 305d2045 [ 0.000000] E
0020f184: 6e746572 696e6720 6164645f 61637469 ntering add_acti
0020f194: 76655f72 616e6765 28302c20 302c2038 ve_range(0, 0, 8
0020f1a4: 31393129 20302065 6e747269 6573206f 191) 0 entries o
0020f1b4: 66203235 36207573 65640a3c 343e5b20 f 256 used.<4>[
0020f1c4: 20202030 2e303030 3030305d 205a6f6e 0.000000] Zon
0020f1d4: 65205046 4e207261 6e676573 3a0a3c34 e PFN ranges:.<4
So it seams to be that the address points to the __log_buf (I hope).
Does it mean that when I try to start zImage kernel from u-boot
it hangs during uncompressing the image and it does even start booting?
Best Regards
Mirek
On Tue, 28 Aug 2007, Grant Likely wrote:
> On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> > Hi Grant,
> >
> > Thanks for your answer.
> > I have found in the System.map :
> > c020f0c4 b __log_buf
> >
> > Is the address c020f0c4 relative to the .data segment?
>
> 0xc0000000 are virtual kernel addresses; not physical addresses. If
> the MMU is still on, then you need to use the virtual address to
> examine memory. If the MMU is off (such as after reloading u-boot),
> then you need to change 0xCxxxxxxx to 0x0xxxxxxxx.
>
> > I understand that when the system hangs I should type in the XMD window
> > stop.
> >
> > Is there anyway to examine the memory from the XMD window? or should I
> > reload the u-boot and examine the memory from u-boot?
>
> I don't know; I've never used XMD. Read the XMD documentation. You
> can do it from u-boot too.
>
> g.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: James Chapman @ 2007-08-28 14:55 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, shemminger, David Miller
In-Reply-To: <200708281348.21302.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> On Tuesday 28 August 2007 11:22, James Chapman wrote:
>>> So in this scheme what runs ->poll() to process incoming packets?
>>> The hrtimer?
>> No, the regular NAPI networking core calls ->poll() as usual; no timers
>> are involved. This scheme simply delays the napi_complete() from the
>> driver so the device stays in the poll list longer. It means that its
>> ->poll() will be called when there is no work to do for 1-2 jiffies,
>> hence the optimization at the top of ->poll() to efficiently handle that
>> case. The device's ->poll() is called by the NAPI core until it has
>> continuously done no work for 1-2 jiffies, at which point it finally
>> does the netif_rx_complete() and re-enables its interrupts.
>>
> I'm not sure if I understand your approach correctly.
> This approach may reduce the number of interrupts, but it does so
> by blocking the CPU for up to 1 jiffy (that can be quite some time
> on some platforms). So no other application / tasklet / softIRQ type
> can do anything in between.
I think I've misread the reworked NAPI net_rx_action code. I thought
that it ran each device ->poll() just once, rescheduling the NET_RX
softirq again if a device stayed in polled mode. I can see now that it
loops while one or more devices stays in the poll list for up to a
jiffy, just like it always has. So by keeping the device in the poll
list and not consuming quota, net_rx_action() spins until the next jiffy
tick unless another device consumes quota, like you say.
I can only assume that the encouraging results that I get with this
scheme are specific to my test setups (measuring packet forwarding
rates). I agree that it isn't desirable to tie up the CPU for up to a
jiffy in net_rx_action() in order to do this. I need to go away and
rework my ideas. Perhaps it is possible to get the behavior I'm looking
for by somehow special-casing the zero return from ->poll() in
net_rx_action(), but I'm not sure.
Thanks for asking questions.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 14:44 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280743i7b3b4ef3g9df015e4be39a9cd@mail.gmail.com>
On 8/28/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> > Okay, im really blind i think, so i started again :
> >
> > - 2.6.22 kernel from kernel.org
> > - cp /arch/ppc/configs/ml300_defconfig .config
BTW, "make ml300_defconfig" does this for you.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 14:43 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <46D42D40.9040204@fz-juelich.de>
On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> Okay, im really blind i think, so i started again :
>
> - 2.6.22 kernel from kernel.org
> - cp /arch/ppc/configs/ml300_defconfig .config
> - edit Makefile to use ARCH=3Dppc and CROSS_COMPILE=3Dpowerpc-405-linux-g=
nu-
> - copy xparams
> - make menuconfig -> no SYSACE blockdevice :((( *aaaaargh*
grant@trillian:~/linux-hacking/linux-2.6$ grep SYSACE drivers/block/Kconfig=
-A 6
config XILINX_SYSACE
tristate "Xilinx SystemACE support"
depends on 4xx
help
Include support for the Xilinx SystemACE CompactFlash interface
>
> i will try the grant kernel now :)
>
> G
>
>
> Grant Likely wrote:
> > On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> >
> >> Grant Likely wrote:
> >>
> >>> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> >>>
> >>>
> >>>> Grant Likely wrote:
> >>>>
> >>>>
> >>>>> You've got 2 choices:
> >>>>> 1. use the new sysace driver; it's already in mainline. The new
> >>>>> driver is faster, but it doesn't handle hotswap of the CF card (yet=
)
> >>>>>
> >>>>>
> >>>>>
> >>>> But where in menuconfig could i find the sysace driver ? i'm blind, =
i
> >>>> think :)
> >>>>
> >>>>
> >>> Which version of kernel are you using? The new sysace driver was
> >>> merged into 2.6.22
> >>>
> >>>
> >>>
> >> linux-2.6.22.5
> >>
> >
> > Should be under drivers->block devices then.
> >
> >
> >>>>> 2. use the EDK driver; easiest way is to use my tree which already =
hasGrant Likely <grant.likely@secretlab.ca>
> >>>>> it merged: http://git.secretlab.ca
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> i made an EDK update and now i have the linux_2_2 os in the software
> >>>> options. the bsp with all drivers is generated.
> >>>> and now ?
> >>>> - copy to kernel tree
> >>>> - use the xmake to build the kernel, or make ?
> >>>>
> >>>>
> >>> Grant Likely <grant.likely@secretlab.ca>
> >>> Don't use EDK to build you're kernel. It's too fragile and you need
> >>> to use the *exact* version of kernel that EDK expects. You're better
> >>> off to manually copy the xparams file from the generated BSP. (ie.
> >>> Don't let EDK know where your real kernel source tree is)
> >>>
> >>>
> >> wuh ? i dont need all the driver from the generatet bsp files ? what
> >> about the gpios and leds ?
> >>
> >
> > Most drivers are already in my tree; any that are missing you can copy
> > over manually.
> >
> >
> >> i compile the kernel with a self made cross toolchain, not with the ed=
k.
> >> until now i copied the bsp files into the kernel tree (modfied some
> >> defines) und compile with "make zImage". But know with the linux_2_6
> >> option there is some more stuff in the bsp directory and i don't know
> >> what to do with :)
> >>
> >>
> >>>> and why is there no dokumentation :)
> >>>>
> >>> Care to write some?
> >>>
> >>>
> >> huh, not really :)
> >> im just a little newbie
> >>
> >
> > best way to learn. :-)
> >
> > g.
> >
>
>
>
> -------------------------------------------------------------------------=
----------------
> -------------------------------------------------------------------------=
----------------
> Forschungszentrum J=FClich GmbH
> 52425 J=FClich
>
> Sitz der Gesellschaft: J=FClich
> Eingetragen im Handelsregister des Amtsgerichts D=FCren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in B=E4rbel Brumme-Bothe
> Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stell=
v.
> Vorsitzender)
> -------------------------------------------------------------------------=
----------------
> -------------------------------------------------------------------------=
----------------
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] Use strcasecmp() rather than strncasecmp() when determining device node compatibility.
From: Josh Boyer @ 2007-08-28 14:33 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070820163659.GB29912@ld0162-tx32.am.freescale.net>
On Mon, 20 Aug 2007 11:36:59 -0500
Scott Wood <scottwood@freescale.com> wrote:
> The current code assumes "foo-bar" must always be compatible with a node
> compatible with "foo", which breaks device trees where this is not so.
>
> The "case" part is also wrong according to Open Firmware, but it's more
> likely to have drivers and/or device trees depending on it, and thus
> needs to be handled more carefully.
After wasting about an hour with git bisect, I finally realized that
this patch "caught" an error in the walnut patches I'm working on (by
making it not boot). So thanks!
josh
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 1/5] spu_manage: use newer physical-id
From: Christian Krafft @ 2007-08-28 14:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, linuxppc-dev, jk, krafft, cbe-oss-dev
In-Reply-To: <200708231812.20493.arnd@arndb.de>
On Thu, 23 Aug 2007 18:12:19 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 23 August 2007, kou.ishizaki@toshiba.co.jp wrote:
> > Please check "unit-id" if "physical-id" doesn't exist. Because Celleb
> > uses "unit-id" to provide spe_id.
Sorry for the late answer, wasn't on cc
and had to receive all mails of the last 6 month once again :-(
Can you check if the patch below is working with celleb device tree ?
------
Subject: spu_manage: fix spu_unit_number for celleb device tree
From: Christian Krafft <krafft@de.ibm.com>
New device trees provide "physical-id".
Celleb device tree provide the "unit-id".
Legacy device tree used the reg property for the physical id of an spe.
This patch fixes find_spu_unit_number to look for the spu id in that order.
The length is checked to avoid misinterpretation in case the attributes
unit-id or reg do not contain the id.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux/arch/powerpc/platforms/cell/spu_manage.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux.orig/arch/powerpc/platforms/cell/spu_manage.c
+++ linux/arch/powerpc/platforms/cell/spu_manage.c
@@ -48,10 +48,18 @@ static u64 __init find_spu_unit_number(s
{
const unsigned int *prop;
int proplen;
+
+ /* new device trees should provide the physical-id attribute */
prop =3D of_get_property(spe, "physical-id", &proplen);
if (proplen =3D=3D 4)
return (u64)*prop;
=20
+ /* celleb device tree provides the unit-id */
+ prop =3D of_get_property(spe, "unit-id", &proplen);
+ if (proplen =3D=3D 4)
+ return (u64)*prop;
+
+ /* legacy device trees provide the id in the reg attribute */
prop =3D of_get_property(spe, "reg", &proplen);
if (proplen =3D=3D 4)
return (u64)*prop;
--=20
Mit freundlichen Gr=FCssen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,=20
Linux Kernel Development
IT Specialist
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-28 14:12 UTC (permalink / raw)
To: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280655mf0c08cct43eb9dbd75452690@mail.gmail.com>
Okay, im really blind i think, so i started again :
- 2.6.22 kernel from kernel.org
- cp /arch/ppc/configs/ml300_defconfig .config
- edit Makefile to use ARCH=ppc and CROSS_COMPILE=powerpc-405-linux-gnu-
- copy xparams
- make menuconfig -> no SYSACE blockdevice :((( *aaaaargh*
i will try the grant kernel now :)
G
Grant Likely wrote:
> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
>
>> Grant Likely wrote:
>>
>>> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
>>>
>>>
>>>> Grant Likely wrote:
>>>>
>>>>
>>>>> You've got 2 choices:
>>>>> 1. use the new sysace driver; it's already in mainline. The new
>>>>> driver is faster, but it doesn't handle hotswap of the CF card (yet)
>>>>>
>>>>>
>>>>>
>>>> But where in menuconfig could i find the sysace driver ? i'm blind, i
>>>> think :)
>>>>
>>>>
>>> Which version of kernel are you using? The new sysace driver was
>>> merged into 2.6.22
>>>
>>>
>>>
>> linux-2.6.22.5
>>
>
> Should be under drivers->block devices then.
>
>
>>>>> 2. use the EDK driver; easiest way is to use my tree which already hasGrant Likely <grant.likely@secretlab.ca>
>>>>> it merged: http://git.secretlab.ca
>>>>>
>>>>>
>>>>>
>>>>>
>>>> i made an EDK update and now i have the linux_2_2 os in the software
>>>> options. the bsp with all drivers is generated.
>>>> and now ?
>>>> - copy to kernel tree
>>>> - use the xmake to build the kernel, or make ?
>>>>
>>>>
>>> Grant Likely <grant.likely@secretlab.ca>
>>> Don't use EDK to build you're kernel. It's too fragile and you need
>>> to use the *exact* version of kernel that EDK expects. You're better
>>> off to manually copy the xparams file from the generated BSP. (ie.
>>> Don't let EDK know where your real kernel source tree is)
>>>
>>>
>> wuh ? i dont need all the driver from the generatet bsp files ? what
>> about the gpios and leds ?
>>
>
> Most drivers are already in my tree; any that are missing you can copy
> over manually.
>
>
>> i compile the kernel with a self made cross toolchain, not with the edk.
>> until now i copied the bsp files into the kernel tree (modfied some
>> defines) und compile with "make zImage". But know with the linux_2_6
>> option there is some more stuff in the bsp directory and i don't know
>> what to do with :)
>>
>>
>>>> and why is there no dokumentation :)
>>>>
>>> Care to write some?
>>>
>>>
>> huh, not really :)
>> im just a little newbie
>>
>
> best way to learn. :-)
>
> g.
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 13:55 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <46D4257C.7060208@fz-juelich.de>
On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> Grant Likely wrote:
> > On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> >
> >> Grant Likely wrote:
> >>
> >>> You've got 2 choices:
> >>> 1. use the new sysace driver; it's already in mainline. The new
> >>> driver is faster, but it doesn't handle hotswap of the CF card (yet)
> >>>
> >>>
> >> But where in menuconfig could i find the sysace driver ? i'm blind, i
> >> think :)
> >>
> >
> > Which version of kernel are you using? The new sysace driver was
> > merged into 2.6.22
> >
> >
> linux-2.6.22.5
Should be under drivers->block devices then.
> >>> 2. use the EDK driver; easiest way is to use my tree which already hasGrant Likely <grant.likely@secretlab.ca>
> >>> it merged: http://git.secretlab.ca
> >>>
> >>>
> >>>
> >> i made an EDK update and now i have the linux_2_2 os in the software
> >> options. the bsp with all drivers is generated.
> >> and now ?
> >> - copy to kernel tree
> >> - use the xmake to build the kernel, or make ?
> >>
> > Grant Likely <grant.likely@secretlab.ca>
> > Don't use EDK to build you're kernel. It's too fragile and you need
> > to use the *exact* version of kernel that EDK expects. You're better
> > off to manually copy the xparams file from the generated BSP. (ie.
> > Don't let EDK know where your real kernel source tree is)
> >
> wuh ? i dont need all the driver from the generatet bsp files ? what
> about the gpios and leds ?
Most drivers are already in my tree; any that are missing you can copy
over manually.
> i compile the kernel with a self made cross toolchain, not with the edk.
> until now i copied the bsp files into the kernel tree (modfied some
> defines) und compile with "make zImage". But know with the linux_2_6
> option there is some more stuff in the bsp directory and i don't know
> what to do with :)
>
> >
> >> and why is there no dokumentation :)
> >
> > Care to write some?
> >
> huh, not really :)
> im just a little newbie
best way to learn. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-28 13:50 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0708281531060.3856-100000@slslc02.psi.ch>
On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> Hi Grant,
>
> Thanks for your answer.
> I have found in the System.map :
> c020f0c4 b __log_buf
>
> Is the address c020f0c4 relative to the .data segment?
0xc0000000 are virtual kernel addresses; not physical addresses. If
the MMU is still on, then you need to use the virtual address to
examine memory. If the MMU is off (such as after reloading u-boot),
then you need to change 0xCxxxxxxx to 0x0xxxxxxxx.
> I understand that when the system hangs I should type in the XMD window
> stop.
>
> Is there anyway to examine the memory from the XMD window? or should I
> reload the u-boot and examine the memory from u-boot?
I don't know; I've never used XMD. Read the XMD documentation. You
can do it from u-boot too.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-28 13:39 UTC (permalink / raw)
Cc: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280630x67856334qaf2e0dd59ecb95bf@mail.gmail.com>
Grant Likely wrote:
> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
>
>> Grant Likely wrote:
>>
>>> You've got 2 choices:
>>> 1. use the new sysace driver; it's already in mainline. The new
>>> driver is faster, but it doesn't handle hotswap of the CF card (yet)
>>>
>>>
>> But where in menuconfig could i find the sysace driver ? i'm blind, i
>> think :)
>>
>
> Which version of kernel are you using? The new sysace driver was
> merged into 2.6.22
>
>
linux-2.6.22.5
>>> 2. use the EDK driver; easiest way is to use my tree which already hasGrant Likely <grant.likely@secretlab.ca>
>>> it merged: http://git.secretlab.ca
>>>
>>>
>>>
>> i made an EDK update and now i have the linux_2_2 os in the software
>> options. the bsp with all drivers is generated.
>> and now ?
>> - copy to kernel tree
>> - use the xmake to build the kernel, or make ?
>>
> Grant Likely <grant.likely@secretlab.ca>
> Don't use EDK to build you're kernel. It's too fragile and you need
> to use the *exact* version of kernel that EDK expects. You're better
> off to manually copy the xparams file from the generated BSP. (ie.
> Don't let EDK know where your real kernel source tree is)
>
wuh ? i dont need all the driver from the generatet bsp files ? what
about the gpios and leds ?
i compile the kernel with a self made cross toolchain, not with the edk.
until now i copied the bsp files into the kernel tree (modfied some
defines) und compile with "make zImage". But know with the linux_2_6
option there is some more stuff in the bsp directory and i don't know
what to do with :)
>
>> and why is there no dokumentation :)
>>
>
> Care to write some?
>
>
huh, not really :)
im just a little newbie
G
> g.
>
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-28 13:37 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708280602vc00920do459a087c25b830e1@mail.gmail.com>
Hi Grant,
Thanks for your answer.
I have found in the System.map :
c020f0c4 b __log_buf
Is the address c020f0c4 relative to the .data segment?
I understand that when the system hangs I should type in the XMD window
stop.
Is there anyway to examine the memory from the XMD window? or should I
reload the u-boot and examine the memory from u-boot?
Best Regards
Mirek
On Tue, 28 Aug 2007, Grant Likely wrote:
> On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> > Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
> > nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
> > ip=::::virtex4-mirek:eth0:dhcp panic=1
> > Uncompressing Linux...
> >
> >
> > After that system just hangs.
> >
> > I do not understand why it is possible to run zImage.elf straight from jtag
> > but it hangs when started from u-boot.
> >
> > Is it any fundamental problem with running Linux from u-boot on ML403
> > (Virtex-4) boards?
>
> No there isn't. It should work. Most likely the kernel did not hang
> immediately, but rather the console is not setup correctly. You need
> to halt the processor after the hang and look at __log_buf in memory
> (Find the address in System.map).
>
> Cheers,
> g.
>
> >
> > Best Regards
> >
> > Mirek
> >
> >
>
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 13:30 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <46D4221D.8030500@fz-juelich.de>
On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> Grant Likely wrote:
> >
> > You've got 2 choices:
> > 1. use the new sysace driver; it's already in mainline. The new
> > driver is faster, but it doesn't handle hotswap of the CF card (yet)
> >
> But where in menuconfig could i find the sysace driver ? i'm blind, i
> think :)
Which version of kernel are you using? The new sysace driver was
merged into 2.6.22
>
> > 2. use the EDK driver; easiest way is to use my tree which already has
> > it merged: http://git.secretlab.ca
> >
> >
> i made an EDK update and now i have the linux_2_2 os in the software
> options. the bsp with all drivers is generated.
> and now ?
> - copy to kernel tree
> - use the xmake to build the kernel, or make ?
Don't use EDK to build you're kernel. It's too fragile and you need
to use the *exact* version of kernel that EDK expects. You're better
off to manually copy the xparams file from the generated BSP. (ie.
Don't let EDK know where your real kernel source tree is)
>
> and why is there no dokumentation :)
Care to write some?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] PS3: fix the bug the major version part is not compared
From: Andreas Schwab @ 2007-08-28 13:26 UTC (permalink / raw)
To: Masakazu Mokuno; +Cc: Geert Uytterhoeven, linuxppc-dev, paulus
In-Reply-To: <20070828211415.C2B5.MOKUNO@sm.sony.co.jp>
Masakazu Mokuno <mokuno@sm.sony.co.jp> writes:
> Fix the bug that the major version part of the firmware
> is not compared.
>
> Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
> CC: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> arch/powerpc/platforms/ps3/setup.c | 2 +-
> include/asm-powerpc/ps3.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/platforms/ps3/setup.c
> +++ b/arch/powerpc/platforms/ps3/setup.c
> @@ -54,7 +54,7 @@ void ps3_get_firmware_version(union ps3_
> }
> EXPORT_SYMBOL_GPL(ps3_get_firmware_version);
>
> -int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
> +s64 ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
> {
> union ps3_firmware_version x;
>
Better yet: normalize the return value.
return (ps3_firmware_version.raw > x.raw) -
(ps3_firmware_version.raw < x.raw);
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-28 13:24 UTC (permalink / raw)
Cc: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280606p67fd74p9287d041d955c538@mail.gmail.com>
Grant Likely wrote:
> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
>
>> Hi Grant,
>>
>> i need your help again :)
>>
>> my 2.6. kernel is running. now i want to add the system ace driver to
>> mount a rootfs on the systemace-flash.
>> but i don't know how to import the EKD driver to the linux kernel, or is
>> there a ready to go driver in the kernel tree ?
>> i didn't find anything...
>>
>
> You've got 2 choices:
> 1. use the new sysace driver; it's already in mainline. The new
> driver is faster, but it doesn't handle hotswap of the CF card (yet)
>
But where in menuconfig could i find the sysace driver ? i'm blind, i
think :)
> 2. use the EDK driver; easiest way is to use my tree which already has
> it merged: http://git.secretlab.ca
>
>
i made an EDK update and now i have the linux_2_2 os in the software
options. the bsp with all drivers is generated.
and now ?
- copy to kernel tree
- use the xmake to build the kernel, or make ?
and why is there no dokumentation :)
Thanks a lot
Georg
> Cheers,
> g.
>
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: Grant Likely @ 2007-08-28 13:06 UTC (permalink / raw)
To: schardt, Linux PPC Linux PPC
In-Reply-To: <46D41298.7060109@fz-juelich.de>
On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
> Hi Grant,
>
> i need your help again :)
>
> my 2.6. kernel is running. now i want to add the system ace driver to
> mount a rootfs on the systemace-flash.
> but i don't know how to import the EKD driver to the linux kernel, or is
> there a ready to go driver in the kernel tree ?
> i didn't find anything...
You've got 2 choices:
1. use the new sysace driver; it's already in mainline. The new
driver is faster, but it doesn't handle hotswap of the CF card (yet)
2. use the EDK driver; easiest way is to use my tree which already has
it merged: http://git.secretlab.ca
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-28 13:02 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0708281300570.31877-100000@slslc02.psi.ch>
On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
> nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
> ip=::::virtex4-mirek:eth0:dhcp panic=1
> Uncompressing Linux...
>
>
> After that system just hangs.
>
> I do not understand why it is possible to run zImage.elf straight from jtag
> but it hangs when started from u-boot.
>
> Is it any fundamental problem with running Linux from u-boot on ML403
> (Virtex-4) boards?
No there isn't. It should work. Most likely the kernel did not hang
immediately, but rather the console is not setup correctly. You need
to halt the processor after the hang and look at __log_buf in memory
(Find the address in System.map).
Cheers,
g.
>
> Best Regards
>
> Mirek
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC 440EPx: Sequoia bootwrapper
From: Valentine Barshak @ 2007-08-28 12:54 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20070816055135.GH3540@localhost.localdomain>
David Gibson wrote:
> On Wed, Aug 15, 2007 at 04:22:58PM +0400, Valentine Barshak wrote:
>> David Gibson wrote:
>>> On Tue, Aug 14, 2007 at 10:53:55PM +0400, Valentine Barshak wrote:
>>>> Bootwrapper code for AMCC 440EPx Sequoia board.
>>>> The DDR2 Denali controller support has been moved to
>>>> arch/powerpc/boot/4xx.c
>>>> The code also uses 440EP clocking fixups
>>>> initially provided for 440EP Bamboo.
>>>>
>>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> [snip]
>>>> diff -ruN linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c linux-2.6/arch/powerpc/boot/cuboot-sequoia.c
>>>> --- linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c 1970-01-01 03:00:00.000000000 +0300
>>>> +++ linux-2.6/arch/powerpc/boot/cuboot-sequoia.c 2007-08-14 17:25:37.000000000 +0400
>>>> @@ -0,0 +1,31 @@
>>>> +/*
>>>> + * Old U-boot compatibility for Sequoia
>>>> + *
>>>> + * Based on Ebony code by David Gibson <david@gibson.dropbear.id.au>
>>>> + *
>>>> + * Copyright 2007 David Gibson, IBM Corporatio.
>>>> + * Based on cuboot-83xx.c, which is:
>>>> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify it
>>>> + * under the terms of the GNU General Public License version 2 as published
>>>> + * by the Free Software Foundation.
>>>> + */
>>>> +
>>>> +#include "ops.h"
>>>> +#include "stdio.h"
>>>> +#include "44x.h"
>>>> +#include "cuboot.h"
>>>> +
>>>> +#define TARGET_4xx
>>>> +#define TARGET_44x
>>> Surely you need to be more specific than that to select the correct
>>> bd_t structure?
>> Both TARGET_4xx and TARGET_44x should be selected for 44x. Otherwise I
>> get wrong bd_t structure (wrong offsets to the eth0/eth1 MAC addresses).
>> In the older arch/ppc code it used to be CONFIG_4xx and it was selected
>> for CONFIG_40x and CONFIG_44x as well.
>
> Yes, I'm not objecting to those TARGET macros, but I'd be very
> surprised if you don't need more to really get the correct bd_t
> structure.
Sorry, I don't quite follow.
As far as I can tell the bd_t structure looks OK.
Could you be more specific, please?
What exactly do you think I need to get the correct bd_t?
Thanks,
Valentine.
>
> [snip]
>>>> diff -ruN linux-2.6.orig/arch/powerpc/boot/sequoia.c linux-2.6/arch/powerpc/boot/sequoia.c
>>>> --- linux-2.6.orig/arch/powerpc/boot/sequoia.c 1970-01-01 03:00:00.000000000 +0300
>>>> +++ linux-2.6/arch/powerpc/boot/sequoia.c 2007-08-14 20:52:10.000000000 +0400
>>> Unless another bootloader is expected to come along for Sequoia,
>>> there's no reason to separate sequoia.c from cuboot-sequoia.c
>> The previous version of Sequoia series had treeboot-sequoia.c, but I've
>> removed it since only u-boot is used now.
>> I'm not sure if there are any other bootloaders expected, but is it OK
>> if I leave 2 separate files just in case? :)
>
> Not unless you have a particular reason to expect another bootloader
> will come along, which doesn't seem that likely to me. Or rather the
> only likely future bootloader I'd see is newer versions of u-boot
> which are device tree aware and handled separately anyway.
>
^ permalink raw reply
* [PATCH] PS3: fix the bug the major version part is not compared
From: Masakazu Mokuno @ 2007-08-28 12:32 UTC (permalink / raw)
To: paulus; +Cc: Geert Uytterhoeven, linuxppc-dev
Fix the bug that the major version part of the firmware
is not compared.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/setup.c | 2 +-
include/asm-powerpc/ps3.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -54,7 +54,7 @@ void ps3_get_firmware_version(union ps3_
}
EXPORT_SYMBOL_GPL(ps3_get_firmware_version);
-int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
+s64 ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
{
union ps3_firmware_version x;
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -36,7 +36,7 @@ union ps3_firmware_version {
};
void ps3_get_firmware_version(union ps3_firmware_version *v);
-int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev);
+s64 ps3_compare_firmware_version(u16 major, u16 minor, u16 rev);
/* 'Other OS' area */
--
Masakazu MOKUNO
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Evgeniy Polyakov @ 2007-08-28 12:16 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: tklein, themann, stefan.roscher, netdev, James Chapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger,
David Miller
In-Reply-To: <200708281348.21302.ossthema@de.ibm.com>
On Tue, Aug 28, 2007 at 01:48:20PM +0200, Jan-Bernd Themann (ossthema@de.ibm.com) wrote:
> I'm not sure if I understand your approach correctly.
> This approach may reduce the number of interrupts, but it does so
> by blocking the CPU for up to 1 jiffy (that can be quite some time
> on some platforms). So no other application / tasklet / softIRQ type
> can do anything in between. The CPU utilization does not drop at all,
> and I thought that is one reason why we try to reduce the number of interrupts.
Only NICs interrupts are suposed to be stopped, system will continue to
work as usual, since all others are alive.
Having hrtimer to reshcedule NIC procesing can work only if number of
timer's interrupts are much less than NICs and if rate of the timer's
starts/changes (presumbly in NICs interrupt) is small too, otherwise
having too many NIC interrupts will not gain anything (actually it is
what is supposed to be dropped noticebly).
--
Evgeniy Polyakov
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-28 11:48 UTC (permalink / raw)
To: James Chapman
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, shemminger, David Miller
In-Reply-To: <46D3E971.4010909@katalix.com>
On Tuesday 28 August 2007 11:22, James Chapman wrote:
> > So in this scheme what runs ->poll() to process incoming packets?
> > The hrtimer?
>
> No, the regular NAPI networking core calls ->poll() as usual; no timers
> are involved. This scheme simply delays the napi_complete() from the
> driver so the device stays in the poll list longer. It means that its
> ->poll() will be called when there is no work to do for 1-2 jiffies,
> hence the optimization at the top of ->poll() to efficiently handle that
> case. The device's ->poll() is called by the NAPI core until it has
> continuously done no work for 1-2 jiffies, at which point it finally
> does the netif_rx_complete() and re-enables its interrupts.
>
I'm not sure if I understand your approach correctly.
This approach may reduce the number of interrupts, but it does so
by blocking the CPU for up to 1 jiffy (that can be quite some time
on some platforms). So no other application / tasklet / softIRQ type
can do anything in between. The CPU utilization does not drop at all,
and I thought that is one reason why we try to reduce the number of interrupts.
> If people feel that holding the device in the poll list for 1-2 jiffies
> is too long (because there are too many wasted polls), a counter could
> be used to to delay the netif_rx_complete() by N polls instead. N would
> be a value depending on CPU speed. I use the jiffy sampling method
> because it results in some natural randomization of the actual delay
> depending on when the jiffy value was sampled in relation to the jiffy tick.
>
Waiting for N polls seems to make no sense if there are no further network adapters
in that machine. It would take no time to call poll N times in a row when no
new packets arrive. There is no real delay as the net_rx_action function will
do nothing else between the poll calls.
Please correct me if I'm wrong.
Regards,
Jan-Bernd
^ permalink raw reply
* [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
From: Jochen Friedrich @ 2007-08-28 11:20 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations.
This ensures r3 gets saved and restored.
This has been posted to linuxppc-embedded by Marcelo Tosatti
<marcelo@kvack.org>, but only an incomplete version of the patch
has been applied in c51e078f82096a7d35ac8ec2416272e843a0e1c4.
This patch adds the rest of the fix.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/ppc/kernel/head_8xx.S | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
This can be pulled from git://git.bocc.de/dbox2.git ppc-fixes
[-- Attachment #2: d14ebb1e9d133983252a14f2ef037f76969ab3c6.diff --]
[-- Type: text/x-patch, Size: 362 bytes --]
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index 944c35c..eb8d26f 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -495,9 +495,7 @@ LoadLargeDTLB:
lwz r11, 4(r0)
lwz r12, 16(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is the data TLB error on the MPC8xx. This could be due to
^ permalink raw reply related
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-28 11:21 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070827.140251.95055210.davem@davemloft.net>
Hi
On Monday 27 August 2007 23:02, David Miller wrote:
> But there are huger fish to fry for you I think. Talk to your
> platform maintainers and ask for an interface for obtaining
> a flat static distribution of interrupts to cpus in order to
> support multiqueue NAPI better.
>
> In your previous postings you made arguments saying that the
> automatic placement of interrupts to cpus made everything
> bunch of to a single cpu and you wanted to propagate the
> NAPI work to other cpu's software interrupts from there.
>
> That logic is bogus, because it merely proves that the hardware
> interrupt distribution is broken. If it's a bad cpu to run
> software interrupts on, it's also a bad cpu to run hardware
> interrupts on.
>
As already mentioned some mails were mixed up here. To clarify the interrupt
issue that has nothing to do with the reduction of interrupts:
- Interrupts are distributed the round robin way on IBM POWER6 processors
- Interrupt distribution can be modified by user/daemons (smp_affinity, pinning)
- NAPI is scheduled on CPU where interrupt is catched
- NAPI polls on that CPU as long as poll has packets to process (default)
(David please correct if there is a misunderstanding here)
Problem for multi queue driver with interrupt distribution scheme set to
round robin for this simple example:
Assuming we have 2 SLOW CPUs. CPU_1 is under heavy load (applications). CPU_2
is not under heavy load. Now we receive a lot of packets (high load situation).
Receive queue 1 (RQ1) is scheduled on CPU_1. NAPI-Poll does not manage to empty
RQ1 ever, so it stays on CPU_1. The second receive queue (RQ2) is scheduled on
CPU_2. As that CPU is not under heavy load, RQ2 can be emptied, and the next IRQ
for RQ2 will go to CPU_1. Then both RQs are on CPU_1 and will stay there if
no IRQ is forced at some time as both RQs are never emptied completely.
This is a simplified example to demonstrate the problem. The interrupt scheme
is not bogus, it is just an effect you see if you don't use pinning.
The user can avoid this problem by pinning the interrupts to CPUs.
As pointed out by David, it will be too expensive to schedule NAPI poll on
a different CPU than the one that gets the IRQ. So I guess one solution
is to "force" an HW interrupt when two many RQs are processed on the same CPU
(when no IRQ pinning is used). This is something the driver has to handle.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-28 11:19 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070827.133721.59473971.davem@davemloft.net>
On Monday 27 August 2007 22:37, David Miller wrote:
> From: Jan-Bernd Themann <ossthema@de.ibm.com>
> Date: Mon, 27 Aug 2007 11:47:01 +0200
>
> > So the question is simply: Do we want drivers that need (benefit
> > from) a timer based polling support to implement their own timers
> > each, or should there be a generic support?
>
> I'm trying to figure out how an hrtimer implementation would
> even work.
>
> Would you start the timer from the chip interrupt handler? If so,
> that's taking two steps backwards as you've already taken all of the
> overhead of running the interrupt handler.
I'm also still trying to understand how hrtimer work exactly.
The implementation of hrtimers for P6 has not been finished yet, so
I can't do experiments with hrtimers and eHEA now.
I will try the following scheme (once we get hrtimers):
Each device (queue) has a hrtimer.
Schedule the timer in the poll function instead of reactivating IRQs
when a high load situation has been detected and all packets have
been emptied from the receive queue.
The timer function could then just call netif_rx_schedule to register
the rx_queue for NAPI again.
The advantages of this scheme (if it works as I understood it) would be:
- we don't have to modify NAPI
- benefit from fairness amoung rx_queues / network devices
- The poll function can decide how long to stick to the timer based
polling mode, and when to switch back to it's HW IRQs.
- driver can determine the time to wait based on the receive queue length and
speed
Regards,
Jan-Bernd
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-28 11:18 UTC (permalink / raw)
To: Grant Likely, Leonid; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708270753u1411796fv698d3b39ee908599@mail.gmail.com>
I have done additional test with my u-boot and linux kernel.
I have downloaded u-boot(.elf) and zImage.elf via jtag to SDRAM:
The SDRAM has 32 MB:
Address Map for Processor ppc405_0
(0x00000000-0x01ffffff) DDR_SDRAM_1 plb
The steps I have doe are as following:
1. XMD% dow -data zImage.elf 0xe00000
2. XMD% dow u-boot.elf
section, .text: 0x00800000-0x0081513c
section, .resetvec: 0x0081513c-0x00815140
section, .rodata: 0x00815140-0x00817ce0
section, .reloc: 0x00817d00-0x00818674
section, .data: 0x00818674-0x00818b08
section, .data.rel: 0x00818b08-0x00818b34
section, .data.rel.local: 0x00818b34-0x00818f6c
section, .u_boot_cmd: 0x00818f6c-0x008191dc
section, .bss: 0x00819200-0x0081dd04
Downloaded Program u-boot.elf
Setting PC with program start addr = 0x00800100
PC reset to 0x00800100, Clearing MSR Register
3. XMD% run
------------------------------------------------------------------
output on the serial port
------------------------------------------------------------------
U-Boot 1.2.0 (Aug 28 2007 - 11:56:19)
U-Boot: checkboard
DRAM: U-Boot: initdram
32 MB
Using default environment
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
=>
U-Boot 1.2.0 (Aug 27 2007 - 14:23:15)
U-Boot: checkboard
DRAM: U-Boot: initdram
32 MB
Using default environment
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
=> bootelf 0xe00000
Loading .text @ 0x00400000 (14028 bytes)
Loading .data @ 0x00404000 (995328 bytes)
Clearing .bss @ 0x004f7000 (8504 bytes)
## Starting application at 0x00400000 ...
loaded at: 00400000 004F9138
board data at: 004F7120 004F7138
relocated to: 004040B4 004040CC
zimage at: 00404E59 004F6EE8
avail ram: 004FA000 01FFFFFF
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...
After that system just hangs.
I do not understand why it is possible to run zImage.elf straight from jtag
but it hangs when started from u-boot.
Is it any fundamental problem with running Linux from u-boot on ML403
(Virtex-4) boards?
Best Regards
Mirek
^ 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