* 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: 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
* [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: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
* 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
* [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: [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
* 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: 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: 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: [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: 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: 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: 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: 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: 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: 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: [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: [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: 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: 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: 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: 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: 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:22 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708280810v48d294h87779374e6a7038d@mail.gmail.com>
This buffer refers to the kernel which I boot straight from jtag but not
u-boot.
Below I attach whole buffer printout:
=> 0x20f0c4 200
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
0020f1e4: 3e5b2020 2020302e 30303030 30305d20 >[ 0.000000]
0020f1f4: 2020444d 41202020 20202020 20202020 DMA
0020f204: 20203020 2d3e2020 20202038 3139310a 0 -> 8191.
0020f214: 3c343e5b 20202020 302e3030 30303030 <4>[ 0.000000
0020f224: 5d202020 4e6f726d 616c2020 20202020 ] Normal
0020f234: 20383139 31202d3e 20202020 20383139 8191 -> 819
0020f244: 310a3c34 3e5b2020 2020302e 30303030 1.<4>[ 0.0000
0020f254: 30305d20 6561726c 795f6e6f 64655f6d 00] early_node_m
0020f264: 61705b31 5d206163 74697665 2050464e ap[1] active PFN
0020f274: 2072616e 6765730a 3c343e5b 20202020 ranges.<4>[
0020f284: 302e3030 30303030 5d202020 2020303a 0.000000] 0:
0020f294: 20202020 20202020 30202d3e 20202020 0 ->
0020f2a4: 20383139 310a3c37 3e5b2020 2020302e 8191.<7>[ 0.
0020f2b4: 30303030 30305d20 4f6e206e 6f646520 000000] On node
0020f2c4: 3020746f 74616c70 61676573 3a203831 0 totalpages: 81
0020f2d4: 39310a3c 373e5b20 20202030 2e303030 91.<7>[ 0.000
0020f2e4: 3030305d 20202044 4d41207a 6f6e653a 000] DMA zone:
0020f2f4: 20363320 70616765 73207573 65642066 63 pages used f
0020f304: 6f72206d 656d6d61 700a3c37 3e5b2020 or memmap.<7>[
0020f314: 2020302e 30303030 30305d20 2020444d 0.000000] DM
0020f324: 41207a6f 6e653a20 30207061 67657320 A zone: 0 pages
0020f334: 72657365 72766564 0a3c373e 5b202020 reserved.<7>[
0020f344: 20302e30 30303030 305d2020 20444d41 0.000000] DMA
0020f354: 207a6f6e 653a2038 31323820 70616765 zone: 8128 page
0020f364: 732c204c 49464f20 62617463 683a300a s, LIFO batch:0.
0020f374: 3c373e5b 20202020 302e3030 30303030 <7>[ 0.000000
0020f384: 5d202020 4e6f726d 616c207a 6f6e653a ] Normal zone:
0020f394: 20302070 61676573 20757365 6420666f 0 pages used fo
0020f3a4: 72206d65 6d6d6170 0a3c343e 5b202020 r memmap.<4>[
0020f3b4: 20302e30 30303030 305d2042 75696c74 0.000000] Built
0020f3c4: 2031207a 6f6e656c 69737473 2e202054 1 zonelists. T
0020f3d4: 6f74616c 20706167 65733a20 38313238 otal pages: 8128
0020f3e4: 0a3c353e 5b202020 20302e30 30303030 .<5>[ 0.00000
0020f3f4: 305d204b 65726e65 6c20636f 6d6d616e 0] Kernel comman
0020f404: 64206c69 6e653a20 636f6e73 6f6c653d d line: console=
0020f414: 74747955 4c302c39 36303020 726f6f74 ttyUL0,9600 root
0020f424: 3d2f6465 762f6e66 73207277 206e6673 =/dev/nfs rw nfs
0020f434: 726f6f74 3d313239 2e313239 2e313434 root=129.129.144
0020f444: 2e313133 3a2f6f70 742f656c 646b3431 .113:/opt/eldk41
0020f454: 2f707063 5f347878 2c746370 20206970 /ppc_4xx,tcp ip
0020f464: 3d3a3a3a 3a766972 74657834 2d6d6972 =::::virtex4-mir
0020f474: 656b3a65 7468303a 64686370 2070616e ek:eth0:dhcp pan
0020f484: 69633d31 0a3c363e 5b202020 20302e30 ic=1.<6>[ 0.0
0020f494: 30303030 305d2058 696c696e 7820494e 00000] Xilinx IN
0020f4a4: 54432023 30206174 20307834 31323030 TC #0 at 0x41200
0020f4b4: 30303020 6d617070 65642074 6f203078 000 mapped to 0x
0020f4c4: 46444646 46303030 0a3c343e 5b202020 FDFFF000.<4>[
0020f4d4: 20302e30 30303030 305d2050 49442068 0.000000] PID h
0020f4e4: 61736820 7461626c 6520656e 74726965 ash table entrie
0020f4f4: 733a2031 32382028 6f726465 723a2037 s: 128 (order: 7
0020f504: 2c203531 32206279 74657329 0a3c343e , 512 bytes).<4>
0020f514: 5b202020 20302e30 30303237 385d2043 [ 0.000278] C
0020f524: 6f6e736f 6c653a20 636f6c6f 75722064 onsole: colour d
0020f534: 756d6d79 20646576 69636520 38307832 ummy device 80x2
0020f544: 350a3c34 3e5b2020 2020302e 30303036 5.<4>[ 0.0006
0020f554: 30335d20 44656e74 72792063 61636865 03] Dentry cache
0020f564: 20686173 68207461 626c6520 656e7472 hash table entr
0020f574: 6965733a 20343039 3620286f 72646572 ies: 4096 (order
0020f584: 3a20322c 20313633 38342062 79746573 : 2, 16384 bytes
0020f594: 290a3c34 3e5b2020 2020302e 30303131 ).<4>[ 0.0011
0020f5a4: 37315d20 496e6f64 652d6361 63686520 71] Inode-cache
0020f5b4: 68617368 20746162 6c652065 6e747269 hash table entri
0020f5c4: 65733a20 32303438 20286f72 6465723a es: 2048 (order:
0020f5d4: 20312c20 38313932 20627974 6573290a 1, 8192 bytes).
0020f5e4: 3c343e5b 20202020 302e3031 30393034 <4>[ 0.010904
0020f5f4: 5d204d65 6d6f7279 3a203330 3238386b ] Memory: 30288k
0020f604: 20617661 696c6162 6c652028 31353638 available (1568
0020f614: 6b206b65 726e656c 20636f64 652c2035 k kernel code, 5
0020f624: 31326b20 64617461 2c203936 6b20696e 12k data, 96k in
0020f634: 69742c20 306b2068 6967686d 656d290a it, 0k highmem).
0020f644: 3c373e5b 20202020 302e3031 32363435 <7>[ 0.012645
0020f654: 5d204361 6c696272 6174696e 67206465 ] Calibrating de
0020f664: 6c617920 6c6f6f70 2e2e2e20 39392e35 lay loop... 99.5
0020f674: 3820426f 676f4d49 50532028 6c706a3d 8 BogoMIPS (lpj=
0020f684: 31393931 3638290a 3c343e5b 20202020 199168).<4>[
0020f694: 302e3039 37303031 5d204d6f 756e742d 0.097001] Mount-
0020f6a4: 63616368 65206861 73682074 61626c65 cache hash table
0020f6b4: 20656e74 72696573 3a203531 320a3c36 entries: 512.<6
0020f6c4: 3e5b2020 2020302e 31303230 32365d20 >[ 0.102026]
0020f6d4: 4e45543a 20526567 69737465 72656420 NET: Registered
0020f6e4: 70726f74 6f636f6c 2066616d 696c7920 protocol family
0020f6f4: 31360a3c 363e5b20 20202030 2e313233 16.<6>[ 0.123
0020f704: 3532335d 204e4554 3a205265 67697374 523] NET: Regist
0020f714: 65726564 2070726f 746f636f 6c206661 ered protocol fa
0020f724: 6d696c79 20320a3c 343e5b20 20202030 mily 2.<4>[ 0
0020f734: 2e313630 3438315d 20495020 726f7574 .160481] IP rout
0020f744: 65206361 63686520 68617368 20746162 e cache hash tab
0020f754: 6c652065 6e747269 65733a20 31303234 le entries: 1024
0020f764: 20286f72 6465723a 20302c20 34303936 (order: 0, 4096
0020f774: 20627974 6573290a 3c343e5b 20202020 bytes).<4>[
0020f784: 302e3136 31323734 5d205443 50206573 0.161274] TCP es
0020f794: 7461626c 69736865 64206861 73682074 tablished hash t
0020f7a4: 61626c65 20656e74 72696573 3a203130 able entries: 10
0020f7b4: 32342028 6f726465 723a2031 2c203831 24 (order: 1, 81
0020f7c4: 39322062 79746573 290a3c34 3e5b2020 92 bytes).<4>[
0020f7d4: 2020302e 31363135 39355d20 54435020 0.161595] TCP
0020f7e4: 62696e64 20686173 68207461 626c6520 bind hash table
0020f7f4: 656e7472 6965733a 20313032 3420286f entries: 1024 (o
0020f804: 72646572 3a20302c 20343039 36206279 rder: 0, 4096 by
0020f814: 74657329 0a3c363e 5b202020 20302e31 tes).<6>[ 0.1
0020f824: 36313831 385d2054 43503a20 48617368 61818] TCP: Hash
0020f834: 20746162 6c657320 636f6e66 69677572 tables configur
0020f844: 65642028 65737461 626c6973 68656420 ed (established
0020f854: 31303234 2062696e 64203130 3234290a 1024 bind 1024).
0020f864: 3c363e5b 20202020 302e3136 31383938 <6>[ 0.161898
0020f874: 5d205443 50207265 6e6f2072 65676973 ] TCP reno regis
0020f884: 74657265 640a3c36 3e5b2020 2020302e tered.<6>[ 0.
0020f894: 31373934 37385d20 696f2073 63686564 179478] io sched
0020f8a4: 756c6572 206e6f6f 70207265 67697374 uler noop regist
0020f8b4: 65726564 0a3c363e 5b202020 20302e31 ered.<6>[ 0.1
=>
0020f8c4: 37393536 315d2069 6f207363 68656475 79561] io schedu
0020f8d4: 6c657220 616e7469 63697061 746f7279 ler anticipatory
0020f8e4: 20726567 69737465 72656420 28646566 registered (def
0020f8f4: 61756c74 290a3c36 3e5b2020 2020302e ault).<6>[ 0.
0020f904: 31373936 33375d20 696f2073 63686564 179637] io sched
0020f914: 756c6572 20646561 646c696e 65207265 uler deadline re
0020f924: 67697374 65726564 0a3c363e 5b202020 gistered.<6>[
0020f934: 20302e31 37393932 305d2069 6f207363 0.179920] io sc
0020f944: 68656475 6c657220 63667120 72656769 heduler cfq regi
0020f954: 73746572 65640a3c 363e5b20 20202031 stered.<6>[ 1
0020f964: 2e303034 3633395d 20756172 746c6974 .004639] uartlit
0020f974: 652e303a 20747479 554c3020 6174204d e.0: ttyUL0 at M
0020f984: 4d494f20 30783430 36303030 30332028 MIO 0x40600003 (
0020f994: 69727120 3d203229 20697320 61207561 irq = 2) is a ua
0020f9a4: 72746c69 74650a3c 343e5b20 20202032 rtlite.<4>[ 2
0020f9b4: 2e393031 3633335d 2052414d 4449534b .901633] RAMDISK
0020f9c4: 20647269 76657220 696e6974 69616c69 driver initiali
0020f9d4: 7a65643a 20312052 414d2064 69736b73 zed: 1 RAM disks
0020f9e4: 206f6620 38313932 4b207369 7a652031 of 8192K size 1
0020f9f4: 30323420 626c6f63 6b73697a 650a3c36 024 blocksize.<6
0020fa04: 3e5b2020 2020322e 39393232 37395d20 >[ 2.992279]
0020fa14: 74756e3a 20556e69 76657273 616c2054 tun: Universal T
0020fa24: 554e2f54 41502064 65766963 65206472 UN/TAP device dr
0020fa34: 69766572 2c20312e 360a3c36 3e5b2020 iver, 1.6.<6>[
0020fa44: 2020332e 30353239 36315d20 74756e3a 3.052961] tun:
0020fa54: 20284329 20313939 392d3230 3034204d (C) 1999-2004 M
0020fa64: 6178204b 7261736e 79616e73 6b79203c ax Krasnyansky <
0020fa74: 6d61786b 40717561 6c636f6d 6d2e636f maxk@qualcomm.co
0020fa84: 6d3e0a3c 363e5b20 20202033 2e313238 m>.<6>[ 3.128
0020fa94: 3733335d 20585465 6d61633a 20757369 733] XTemac: usi
0020faa4: 6e672046 49464f20 64697265 63742069 ng FIFO direct i
0020fab4: 6e746572 72757074 20647269 76656e20 nterrupt driven
0020fac4: 6d6f6465 2e0a3c36 3e5b2020 2020332e mode..<6>[ 3.
0020fad4: 31393639 33355d20 65746825 643a2058 196935] eth%d: X
0020fae4: 54656d61 633a2050 48592064 65746563 Temac: PHY detec
0020faf4: 74656420 61742061 64647265 73732033 ted at address 3
0020fb04: 2e0a3c36 3e5b2020 2020332e 32353931 ..<6>[ 3.2591
0020fb14: 35385d20 65746830 3a205869 6c696e78 58] eth0: Xilinx
0020fb24: 2054454d 41432023 30206174 20307838 TEMAC #0 at 0x8
0020fb34: 31323030 30303020 6d617070 65642074 1200000 mapped t
0020fb44: 6f203078 43323032 30303030 2c206972 o 0xC2020000, ir
0020fb54: 713d300a 3c363e5b 20202020 332e3334 q=0.<6>[ 3.34
0020fb64: 32383037 5d206574 68303a20 5854656d 2807] eth0: XTem
0020fb74: 61632069 6420312e 30662c20 626c6f63 ac id 1.0f, bloc
0020fb84: 6b206964 20352c20 74797065 20380a3c k id 5, type 8.<
0020fb94: 363e5b20 20202033 2e343033 3233385d 6>[ 3.403238]
0020fba4: 206d6963 653a2050 532f3220 6d6f7573 mice: PS/2 mous
0020fbb4: 65206465 76696365 20636f6d 6d6f6e20 e device common
0020fbc4: 666f7220 616c6c20 6d696365 0a3c363e for all mice.<6>
0020fbd4: 5b202020 20332e34 36353937 385d2054 [ 3.465978] T
0020fbe4: 43502063 75626963 20726567 69737465 CP cubic registe
0020fbf4: 7265640a 3c363e5b 20202020 332e3530 red.<6>[ 3.50
0020fc04: 34383134 5d204e45 543a2052 65676973 4814] NET: Regis
0020fc14: 74657265 64207072 6f746f63 6f6c2066 tered protocol f
0020fc24: 616d696c 7920310a 3c363e5b 20202020 amily 1.<6>[
0020fc34: 332e3535 37303939 5d204e45 543a2052 3.557099] NET: R
0020fc44: 65676973 74657265 64207072 6f746f63 egistered protoc
0020fc54: 6f6c2066 616d696c 79203137 0a3c363e ol family 17.<6>
0020fc64: 5b202020 20342e31 31333537 345d2065 [ 4.113574] e
0020fc74: 7468303a 20585465 6d61633a 204f7074 th0: XTemac: Opt
0020fc84: 696f6e73 3a203078 62386632 0a3c363e ions: 0xb8f2.<6>
0020fc94: 5b202020 20382e31 34353433 305d2065 [ 8.145430] e
0020fca4: 7468303a 20585465 6d61633a 20576520 th0: XTemac: We
0020fcb4: 72656e65 676f7469 61746564 20746865 renegotiated the
0020fcc4: 20737065 65642074 6f3a2031 30300a3c speed to: 100.<
0020fcd4: 363e5b20 20202038 2e323132 3134375d 6>[ 8.212147]
0020fce4: 20657468 303a2058 54656d61 633a2073 eth0: XTemac: s
0020fcf4: 70656564 20736574 20746f20 3130304d peed set to 100M
0020fd04: 622f730a 3c353e5b 20202020 392e3237 b/s.<5>[ 9.27
0020fd14: 36303637 5d205365 6e64696e 67204448 6067] Sending DH
0020fd24: 43502072 65717565 73747320 2e2c204f CP requests ., O
0020fd34: 4b0a3c34 3e5b2020 2020392e 38343830 K.<4>[ 9.8480
0020fd44: 38355d20 49502d43 6f6e6669 673a2047 85] IP-Config: G
0020fd54: 6f742044 48435020 616e7377 65722066 ot DHCP answer f
0020fd64: 726f6d20 3235352e 3235352e 3235352e rom 255.255.255.
0020fd74: 3235352c 206d7920 61646472 65737320 255, my address
0020fd84: 69732031 32392e31 32392e31 34342e38 is 129.129.144.8
0020fd94: 320a3c34 3e5b2020 2020392e 39343831 2.<4>[ 9.9481
0020fda4: 33385d20 49502d43 6f6e6669 673a2043 38] IP-Config: C
0020fdb4: 6f6d706c 6574653a 0a3c343e 5b202020 omplete:.<4>[
0020fdc4: 20392e39 38343732 395d2020 20202020 9.984729]
0020fdd4: 20646576 6963653d 65746830 2c206164 device=eth0, ad
0020fde4: 64723d31 32392e31 32392e31 34342e38 dr=129.129.144.8
0020fdf4: 322c206d 61736b3d 3235352e 3235352e 2, mask=255.255.
0020fe04: 3235352e 302c2067 773d3132 392e3132 255.0, gw=129.12
0020fe14: 392e3134 342e312c 0a3c343e 5b202020 9.144.1,.<4>[
0020fe24: 31302e30 38313736 395d2020 20202020 10.081769]
0020fe34: 686f7374 3d766972 74657834 2d6d6972 host=virtex4-mir
0020fe44: 656b2c20 646f6d61 696e3d70 73692e63 ek, domain=psi.c
0020fe54: 682c206e 69732d64 6f6d6169 6e3d286e h, nis-domain=(n
0020fe64: 6f6e6529 2c0a3c34 3e5b2020 2031302e one),.<4>[ 10.
0020fe74: 31363031 32385d20 20202020 20626f6f 160128] boo
0020fe84: 74736572 7665723d 3235352e 3235352e tserver=255.255.
0020fe94: 3235352e 3235352c 20726f6f 74736572 255.255, rootser
0020fea4: 7665723d 3132392e 3132392e 3134342e ver=129.129.144.
0020feb4: 3131332c 20726f6f 74706174 683d0a3c 113, rootpath=.<
0020fec4: 353e5b20 20203130 2e323535 3737355d 5>[ 10.255775]
0020fed4: 204c6f6f 6b696e67 20757020 706f7274 Looking up port
0020fee4: 206f6620 52504320 31303030 30332f32 of RPC 100003/2
0020fef4: 206f6e20 3132392e 3132392e 3134342e on 129.129.144.
0020ff04: 3131330a 3c353e5b 20202031 302e3332 113.<5>[ 10.32
0020ff14: 39383830 5d204c6f 6f6b696e 67207570 9880] Looking up
0020ff24: 20706f72 74206f66 20525043 20313030 port of RPC 100
0020ff34: 3030352f 31206f6e 20313239 2e313239 005/1 on 129.129
0020ff44: 2e313434 2e313133 0a3c343e 5b202020 .144.113.<4>[
0020ff54: 31302e34 31323935 325d2056 46533a20 10.412952] VFS:
0020ff64: 4d6f756e 74656420 726f6f74 20286e66 Mounted root (nf
0020ff74: 73206669 6c657379 7374656d 292e0a3c s filesystem)..<
0020ff84: 343e5b20 20203130 2e343638 3134395d 4>[ 10.468149]
0020ff94: 20467265 65696e67 20756e75 73656420 Freeing unused
0020ffa4: 6b65726e 656c206d 656d6f72 793a2039 kernel memory: 9
0020ffb4: 366b2069 6e69740a 00000000 00000000 6k init.........
0020ffc4: 00000000 00000000 00000000 00000000 ................
0020ffd4: 00000000 00000000 00000000 00000000 ................
0020ffe4: 00000000 00000000 00000000 00000000 ................
That is a whole buffer
Mirek
On Tue, 28 Aug 2007, Grant Likely wrote:
> 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.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ 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