* Re: [PATCH] [v2] watchdog: booke_wdt: clean up status messages
From: Kumar Gala @ 2011-03-15 15:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: wim, linux-watchdog, linuxppc-dev
In-Reply-To: <1297208386-15010-1-git-send-email-timur@freescale.com>
On Feb 8, 2011, at 5:39 PM, Timur Tabi wrote:
> Improve the status messages that are displayed during some operations =
of the
> PowerPC watchdog timer driver. When the watchdog is enabled, the =
timeout is
> displayed as a number of seconds, instead of an obscure "period". The =
"period"
> is the position of a bit in a 64-bit timer register. The higher the =
value,
> the quicker the watchdog timeout occurs. Some people chose a high =
"period"
> value for the timer and get confused as to why the board resets within =
a
> few seconds.
>=20
> Messages displayed during open and close are now debug messages, so =
that they
> don't clutter the console by default. Finally, printk() is replaced =
with the
> pr_xxx() equivalent.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> drivers/watchdog/booke_wdt.c | 19 +++++++++----------
> 1 files changed, 9 insertions(+), 10 deletions(-)
applied
- k=
^ permalink raw reply
* Re: [PATCH] I2C: Add support for 64bit system.
From: Kumar Gala @ 2011-03-15 15:44 UTC (permalink / raw)
To: Ben Dooks; +Cc: Xulei, linux-i2c, linuxppc-dev
In-Reply-To: <20101220145954.GA1126@trinity.fluff.org>
On Dec 20, 2010, at 8:59 AM, Ben Dooks wrote:
> On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote:
>> Currently I2C_MPC supports 32bit system only, then this
>> modification makes it support 32bit and 64bit system both.
>>
>> Signed-off-by: Xulei <B33228@freescale.com>
>
> This been build or run tested?
Yes, Any issues with me applying this via the powerpc.git tree?
>
>> ---
>> drivers/i2c/busses/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index 9c6170c..3392f4b 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -422,7 +422,7 @@ config I2C_IXP2000
>>
>> config I2C_MPC
>> tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
>> - depends on PPC32
>> + depends on PPC32 || PPC64
>> help
>> If you say yes to this option, support will be included for the
>> built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
>> --
>> 1.7.0.4
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/
>
> Large Hadron Colada: A large Pina Colada that makes the universe disappear.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/4] drivers/serial/ucc_uart.c: Add of_node_put to avoid memory leak
From: Kumar Gala @ 2011-03-15 15:51 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, devicetree-discuss, linuxppc-dev, Timur Tabi,
linux-kernel
In-Reply-To: <1283269738-14612-2-git-send-email-julia@diku.dk>
On Aug 31, 2010, at 10:48 AM, Julia Lawall wrote:
> Add a call to of_node_put in the error handling code following a call =
to
> of_find_compatible_node or of_find_node_by_type.
>=20
> This patch also substantially reorganizes the error handling code in =
the
> function, to that it is possible first to jump to code that frees =
qe_port
> and then to jump to code that also puts np.
>=20
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>=20
> // <smpl>
> @r exists@
> local idexpression x;
> expression E,E1,E2;
> statement S;
> @@
>=20
> *x =3D=20
> (of_find_node_by_path
> |of_find_node_by_name
> |of_find_node_by_phandle
> |of_get_parent
> |of_get_next_parent
> |of_get_next_child
> |of_find_compatible_node
> |of_match_node
> |of_find_node_by_type
> |of_find_node_with_property
> |of_find_matching_node
> |of_parse_phandle
> )(...);
> ...
> if (x =3D=3D NULL) S
> <... when !=3D x =3D E
> *if (...) {
> ... when !=3D of_node_put(x)
> when !=3D if (...) { ... of_node_put(x); ... }
> (
> return <+...x...+>;
> |
> * return ...;
> )
> }
> ...>
> (
> E2 =3D x;
> |
> of_node_put(x);
> )
> // </smpl>
>=20
> Signed-off-by: Julia Lawall <julia@diku.dk>
>=20
> ---
> drivers/serial/ucc_uart.c | 67 =
++++++++++++++++++++++++----------------------
> 1 file changed, 35 insertions(+), 32 deletions(-)
applied
- k=
^ permalink raw reply
* Re: [PATCH] Fix SPE float to integer conversion failure
From: Kumar Gala @ 2011-03-15 15:51 UTC (permalink / raw)
To: Shan Hai; +Cc: linuxppc-dev
In-Reply-To: <1289960933-5172-2-git-send-email-shan.hai@windriver.com>
On Nov 16, 2010, at 8:28 PM, Shan Hai wrote:
> Conversion from float to integer should based on both the instruction
> encoding and the sign of the operand.
>
> Signed-off-by: Shan Hai <shan.hai@windriver.com>
> ---
> arch/powerpc/math-emu/math_efp.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
applied
- k
^ permalink raw reply
* Re: Bug in arch/powerpc/sysdev/fsl_gtm.c
From: Kumar Gala @ 2011-03-15 15:53 UTC (permalink / raw)
To: Jean-Denis Boyer
Cc: 'Anton Vorontsov',
'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <265ED5BA1B926340AF277A54E6A8341441FD6401F2@exchange.media5corp.com>
On Feb 16, 2011, at 8:59 AM, Jean-Denis Boyer wrote:
> Hi.
> There is a bug in the function gtm_set_ref_timer16.
> When called, it correctly sets the requested timer,
> but the other timer that shares the register GTCFR is reset.
>
> The parameter 'clear' passed to macro clrsetbits_8 should not be
> a bitwise complement, since the macro already complements it.
>
> Here is a patch that should fix this issue.
>
> --- linux-2.6.35.11/arch/powerpc/sysdev/fsl_gtm.c
> +++ linux/arch/powerpc/sysdev/fsl_gtm.c
> @@ -203,13 +203,10 @@
> spin_lock_irqsave(>m->lock, flags);
>
> /*
> - * Properly reset timers: stop, reset, set up prescalers, reference
> + * Properly set timers: stop, set up prescalers, reference
> * value and clear event register.
> */
> - clrsetbits_8(tmr->gtcfr, ~(GTCFR_STP(num) | GTCFR_RST(num)),
> - GTCFR_STP(num) | GTCFR_RST(num));
> -
> - setbits8(tmr->gtcfr, GTCFR_STP(num));
> + setbits8(tmr->gtcfr, GTCFR_STP(num) | GTCFR_RST(num));
>
> if (tmr->gtpsr)
> out_be16(tmr->gtpsr, psr);
If you'd like this applied please re-send w/proper signed-off-by
- k
^ permalink raw reply
* Re: [PATCH 1/2] ATA: Add FSL sata v2 controller support
From: Kumar Gala @ 2011-03-15 15:39 UTC (permalink / raw)
To: Xulei; +Cc: linux-ide, linuxppc-dev, jgarzik
In-Reply-To: <1295428050-21934-1-git-send-email-B33228@freescale.com>
On Jan 19, 2011, at 3:07 AM, Xulei wrote:
> In FSL sata v2 block, the snoop bit of PRDT Word3 description
> information is at bit28 instead of bit22.
>
> This patch adds FSL sata v2 probe and resolve this difference.
>
> Signed-off-by: Lei Xu <B33228@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
> ---
> drivers/ata/sata_fsl.c | 25 ++++++++++++++++++-------
> 1 files changed, 18 insertions(+), 7 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] I2C: Add support for 64bit system.
From: Timur Tabi @ 2011-03-15 15:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: Xulei, linux-i2c, Ben Dooks, linuxppc-dev
In-Reply-To: <D9BF0938-44B1-4BB8-BF3C-0A9CB44B9CC5@kernel.crashing.org>
On Tue, Mar 15, 2011 at 10:44 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Dec 20, 2010, at 8:59 AM, Ben Dooks wrote:
>
>> On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote:
>>> Currently I2C_MPC supports 32bit system only, then this
>>> modification makes it support 32bit and 64bit system both.
>>>
>>> Signed-off-by: Xulei <B33228@freescale.com>
>>
>> This been build or run tested?
>
> Yes, Any issues with me applying this via the powerpc.git tree?
I'm concerned about the fact that we have to have two defines to
declare code that is 32-bit and 64-bit clean. Technically speaking,
all drivers should work in both environments. It seems silly to have
"PPC32 || PPC64" for everything. Isn't there a generic "PPC" config
option that covers this?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] I2C: Add support for 64bit system.
From: Kumar Gala @ 2011-03-15 16:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: Xulei, linux-i2c, Ben Dooks, linuxppc-dev
In-Reply-To: <AANLkTim0_ttjDPJvx71B-=Ze5dRTrKXfpavx7gxvYr5p@mail.gmail.com>
On Mar 15, 2011, at 10:56 AM, Timur Tabi wrote:
> On Tue, Mar 15, 2011 at 10:44 AM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> On Dec 20, 2010, at 8:59 AM, Ben Dooks wrote:
>>=20
>>> On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote:
>>>> Currently I2C_MPC supports 32bit system only, then this
>>>> modification makes it support 32bit and 64bit system both.
>>>>=20
>>>> Signed-off-by: Xulei <B33228@freescale.com>
>>>=20
>>> This been build or run tested?
>>=20
>> Yes, Any issues with me applying this via the powerpc.git tree?
>=20
> I'm concerned about the fact that we have to have two defines to
> declare code that is 32-bit and 64-bit clean. Technically speaking,
> all drivers should work in both environments. It seems silly to have
> "PPC32 || PPC64" for everything. Isn't there a generic "PPC" config
> option that covers this?
There is, I'll post a new patch that uses it.
- k=
^ permalink raw reply
* [PATCH] i2c-mpc: Add support for 64bit system
From: Kumar Gala @ 2011-03-15 16:02 UTC (permalink / raw)
To: ben-linux; +Cc: linuxppc-dev, linux-i2c, B33228
Currently i2c-mpc supports 32bit system only, this modification makes it
supported on both 32-bit and 64-bit systems. The P5020 is the first
64-bit PPC system with the i2c-mpc controller.
Based in patch from Xulei <B33228@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/i2c/busses/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 113505a..107d5c2 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -433,7 +433,7 @@ config I2C_IXP2000
config I2C_MPC
tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
- depends on PPC32
+ depends on PPC
help
If you say yes to this option, support will be included for the
built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH][v2] define binding for fsl mpic interrupt controllers
From: Kumar Gala @ 2011-03-15 16:06 UTC (permalink / raw)
To: Stuart yoder; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <1295476214-27698-1-git-send-email-stuart.yoder@freescale.com>
On Jan 19, 2011, at 4:30 PM, Stuart yoder wrote:
> From: Stuart Yoder <stuart.yoder@freescale.com>
>=20
> define the binding for compatible =3D "fsl,mpic", including
> the definition of 4-cell interrupt specifiers. The
> 3rd and 4th cells are needed to define additional
> types of interrupt source outside the "normal"
> external and internal interrupts in FSL SoCs. Define
> error interrupt, IPIs, and PIC timer sources.
>=20
> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
> ---
> -version 2
> -fix some typos
> -move defintion of interrupt number to the interrupt
> type 0
> -defined no-reset property
> -added some examples
>=20
> Documentation/powerpc/dts-bindings/fsl/mpic.txt | 251 =
+++++++++++++++++++----
> 1 files changed, 209 insertions(+), 42 deletions(-)
applied
- k=
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/fsl: 85xx: document cache sram bindings
From: Kumar Gala @ 2011-03-15 16:17 UTC (permalink / raw)
To: Linuxppc-dev list
In-Reply-To: <1260257477-21942-1-git-send-email-vivek.mahajan@freescale.com>
On Dec 8, 2009, at 1:31 AM, Vivek Mahajan wrote:
> Adds binding documentation for cache sram for the PQ3 and
> some QorIQ based platforms.
>=20
> Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
> ---
> .../powerpc/dts-bindings/fsl/85xx_cache_sram.txt | 20 =
++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
> create mode 100644 =
Documentation/powerpc/dts-bindings/fsl/85xx_cache_sram.txt
applied
- k=
^ permalink raw reply
* Re: [PATCH] i2c-mpc: Add support for 64bit system
From: Ben Dooks @ 2011-03-15 16:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-i2c, ben-linux, B33228
In-Reply-To: <1300204963-15855-1-git-send-email-galak@kernel.crashing.org>
On Tue, Mar 15, 2011 at 11:02:43AM -0500, Kumar Gala wrote:
> Currently i2c-mpc supports 32bit system only, this modification makes it
> supported on both 32-bit and 64-bit systems. The P5020 is the first
> 64-bit PPC system with the i2c-mpc controller.
>
> Based in patch from Xulei <B33228@freescale.com>
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
ok, will add to -next
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 113505a..107d5c2 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -433,7 +433,7 @@ config I2C_IXP2000
>
> config I2C_MPC
> tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
> - depends on PPC32
> + depends on PPC
> help
> If you say yes to this option, support will be included for the
> built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
> --
> 1.7.2.3
>
--
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
From: nello martuscielli @ 2011-03-15 16:44 UTC (permalink / raw)
Cc: linuxppc-dev, acrux @ cruxppc
In-Reply-To: <AANLkTinOo9tJ5=WWF2WJEZn3VwAUOa+SOYE0txNm-moM@mail.gmail.com>
ok, it seems that no one is interested to fix Pegasos1 G3 600MHz support.
But if someone is capable (i don't have this skill) here what it
happens reading from serial debug console untill it freezes with
linux-2.6.36.4
Pegasos Boot Strap (c) 2002 bplan GmbH
Running on CPU PVR:00083311
PLL setting : 00000001
Enable L1 ICache... Done.
Setting ROM Defaults... Done.
Configuring SDRAM...
08000000
10000000
Delaying...Done.
RAMSIZE = 18000000
00000004
Reading W83194 : 00FFFFFFFFFF0000 Done.
Setting Front Side Bus to 100MHz... Done.
Releasing IDE reset ... Done.
Configuring Legacy Devices
Initializing KBD... Done.
PLL setting : 00000003
10000000
Done.
FFFFFFFF
BIOS: Stage 2 entered arg(FFFC0000,00000000,18000000)
BIOS: MachineInfo at 0FFFFE68
BIOS: set MemPool limit to BAT size (old=18000000 new=10000000)
BIOS: 0F6FFFE8 bytes added to mempool
LoadFromRFS: starting
LoadFromRFS: lib module 00 has abs load adr at 00C00000
CopyModule: start
CopyModule: load address : 00C00000
CopyModule: copy module to ram...done
ModuleCopy: expanding... done
LoadFromRFS: 00000001 modules out of 00000001 loaded
InitLib: start
InitLib: call module as OF
allocated g_e=0xFD00008 (len=19232)
install_root: pkg=0xFD53B90
after init_environ e=0xFD00008
running nvramrc...
after running nvramrc
no/bad nvramrc - performing default startup script
Bus addresses:
253@2
I/O addresses:
7936@FE002100
Memory addresses:
127M@88040000
1.3G@98000000
Prefetchable memory addresses:
install_ata_disk_driver: reg=0x1000
init_drive: reset controller 0x1000/0x100E
init_drive: allow 4-bits for heads
init_drive: select drive 0
init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x0 cyl_hi=0x0
init_drive: error=0x1 status=0x50 status2=0x50
init_drive: identify drive: atapi=0
install_ata_disk_driver: return no error (0)
install_ata_disk_driver: reg=0x1000
init_drive: allow 4-bits for heads
init_drive: select drive 1
init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x14 cyl_hi=0xEB
init_drive: error=0x1 status=0x0 status2=0x0
init_drive: identify drive: atapi=1
atapi_cmd: cmdlen=12
atapi_cmd: inlen=8 len=65534
install_ata_disk_driver: return no error (0)
install_ata_disk_driver: reg=0x1010
init_drive: reset controller 0x1010/0x101E
init_drive: allow 4-bits for heads
init_drive: select drive 0
init_drive: seccnt=0x20 sector=0x20 cyl_lo=0x20 cyl_hi=0x20
init_drive: error=0x20 status=0x20 status2=0x20
ATA-wait-ready: timeout: status=0x20
init_drive: failed
install_ata_disk_driver: reg=0x1010
init_drive: allow 4-bits for heads
init_drive: select drive 1
init_drive: seccnt=0x30 sector=0x30 cyl_lo=0x30 cyl_hi=0x30
init_drive: error=0x30 status=0x30 status2=0x30
ATA-wait-ready: timeout: status=0x30
init_drive: failed
Bus addresses:
254@2
I/O addresses:
8@FE001038
3072@FE001400
48K@FE004000
Memory addresses:
1792@A0000100
1.2G@A0001000
Prefetchable memory addresses:
12M@FD400000
F_INSTALL_CONSOLE: BEGIN
F_INSTALL_CONSOLE: ALIASING SCREEN
F_INSTALL_CONSOLE: ALIASING KBD
EMULATION INT HANDLER ENTERED WITH:
INT NO: 15
EAX=0003 EBX=1111 ECX=2222 EDX=3333 ESP=0000 EBP=5555 ESI=6666 EDI=7777
AX=4E08 BX=C505 CX=0003 DX=202A SP=6CAA BP=5555 SI=5CF9 DI=7777
DS=C000 ES=BAD0 SS=C000 CS=F000 IP=FE15 NV UP -- PL ZR NA PE NC
CS:IP = F4 C558 C000 0244 3000 0000 01B4 AC63 0200
UNHANDLED INT 10 FUNCTION 0007 WITHIN EMULATION
F_INSTALL_CONSOLE: END
auto-booting...
do_load: dev="" dlen=0 args="" alen=0
do_load: alstr=""
do_load: path doesn't start with /
do_load: <diag-device> == <eth>
do_load: no args..use the default
do_load: <diag-file> == <diag>
try_load: dev="eth" dlen=3 args="diag" alen=4
entering main read/eval loop...
[...]
atapi_cmd: cmdlen=12
atapi_cmd: inlen=2048 len=2048
iso_walk: read: name="zImage.chrp" extent=0x44FD size=0x337272 ret=no error
iso9660: return R_END
file_system: return end (-4089)
disk-label return len=3371634 ret=end (-4089)
ata_disk_close
disk-label close:
checking exec type Fcode
fcode_is_exec: load=0x400000 loadlen=3371634
checking exec type Forth
checking exec type ELF
f_go:
checking exec type Fcode
fcode_is_exec: load=0x400000 loadlen=3371634
checking exec type Forth
checking exec type ELF
alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
0xFFFFFFFF, size 0x332000, addr 0x300000
alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
0xFD54910 u2 0xFD54914 u3 0xFD54918
alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x300000
size 0xFD00000
alloc_constrained: fsblock 0x0
alloc_constrained: addr[] 0x300000
alloc_constrained: bsize[] 0xFD00000
alloc_constrained: passed min check
alloc_constrained: addr 0x300000, align 0xFFF, off 0x69696969
sum 0x0
alloc_constrained: passed align check
alloc_constrained: passed max check
alloc_constrained: passed mask check
alloc_constrained: passed full size check
alloc_constrained: passed size check
alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
0xFFFFFFFF, size 0x6883C0, addr 0x632000
alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
0xFD54910 u2 0xFD54914 u3 0xFD54918
alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x632000
size 0xF9CE000
alloc_constrained: fsblock 0x0
alloc_constrained: addr[] 0x632000
alloc_constrained: bsize[] 0xF9CE000
alloc_constrained: passed min check
alloc_constrained: addr 0x632000, align 0xFFF, off 0x0
sum 0x0
alloc_constrained: passed align check
alloc_constrained: passed max check
alloc_constrained: passed mask check
alloc_constrained: passed full size check
alloc_constrained: passed size check
and here giving a try with a smaller (1.9MB) linux boot kernel
[...]
atapi_cmd: cmdlen=12
atapi_cmd: inlen=2048 len=2048
iso_walk: read: name="zImage.chrp" extent=0x3CC size=0x1D8A1A ret=no error
iso9660: return R_END
file_system: return end (-4089)
disk-label return len=1935898 ret=end (-4089)
ata_disk_close
disk-label close:
checking exec type Fcode
fcode_is_exec: load=0x400000 loadlen=1935898
checking exec type Forth
checking exec type ELF
f_go:
checking exec type Fcode
fcode_is_exec: load=0x400000 loadlen=1935898
checking exec type Forth
checking exec type ELF
alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
0xFFFFFFFF, size 0x1D3000, addr 0x300000
alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
0xFD54910 u2 0xFD54914 u3 0xFD54918
alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x300000
size 0xFD00000
alloc_constrained: fsblock 0x0
alloc_constrained: addr[] 0x300000
alloc_constrained: bsize[] 0xFD00000
alloc_constrained: passed min check
alloc_constrained: addr 0x300000, align 0xFFF, off 0x69696969
sum 0x0
alloc_constrained: passed align check
alloc_constrained: passed max check
alloc_constrained: passed mask check
alloc_constrained: passed full size check
alloc_constrained: passed size check
alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
0xFFFFFFFF, size 0x3AC9A0, addr 0x4D3000
alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
0xFD54910 u2 0xFD54914 u3 0xFD54918
alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x4D3000
size 0xFB2D000
alloc_constrained: fsblock 0x0
alloc_constrained: addr[] 0x4D3000
alloc_constrained: bsize[] 0xFB2D000
alloc_constrained: passed min check
alloc_constrained: addr 0x4D3000, align 0xFFF, off 0x0
sum 0x0
alloc_constrained: passed align check
alloc_constrained: passed max check
alloc_constrained: passed mask check
alloc_constrained: passed full size check
alloc_constrained: passed size check
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Mahesh J Salgaonkar @ 2011-03-15 16:52 UTC (permalink / raw)
To: Américo Wang
Cc: kexec, linux-kernel, linuxppc-dev, Anton Blanchard, akpm,
Eric W. Biederman
In-Reply-To: <AANLkTi=aDzCaa7_=5XTrnJCzmZPrDy3omXwDarEF8XmH@mail.gmail.com>
On Tue, Mar 15, 2011 at 03:52:38PM +0800, Américo Wang wrote:
> On Tue, Mar 15, 2011 at 2:13 AM, Mahesh J Salgaonkar
> <mahesh@linux.vnet.ibm.com> wrote:
> >
> > During free we do free all of them including RMO region. But since the rtas
> > region is always on top of RMO, crashkernel memory overlaps rtas region and
> > we endup freeing that even, which is causing the crash.
> >
>
> Okay, but with this patch applied, we will just ignore rtas region, right?
Correct.
> Thus, when I echo 0 to free all the 128M crashkernel memory, the final
> result will be 32M left, which means crash_size will still show 32M.
> This looks odd.
>
> How about skipping the 32M as a whole? I mean once the region being freed
> has overlap with this rtas region, skip the whole rtas region, and let
> crash_size
> show 0?
The existing code from crash_shrink_memory() function reduces the crash
size to 0 when echo'ed 0. I did test this patchset and verified that
/sys/kernel/kexec_crash_size show 0 value.
Thanks,
-Mahesh.
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
^ permalink raw reply
* Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
From: Baurzhan Ismagulov @ 2011-03-15 16:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTim6urK-1-0MXrXZPTDWifZsi+7QEH_c8S-vzWSL@mail.gmail.com>
On Tue, Mar 15, 2011 at 05:44:49PM +0100, nello martuscielli wrote:
> But if someone is capable (i don't have this skill) here what it
> happens reading from serial debug console untill it freezes with
> linux-2.6.36.4
What is the last kernel version working on that machine? If you have a
working kernel and can build kernels, you could try bisecting to
identify the change that led to that. Perhaps then someone could have
some ideas.
With kind regards,
--
Baurzhan Ismagulov
http://www.kz-easy.com/
^ permalink raw reply
* Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
From: Gerhard Pircher @ 2011-03-15 17:14 UTC (permalink / raw)
To: nello martuscielli; +Cc: linuxppc-dev, acrux_it
In-Reply-To: <AANLkTim6urK-1-0MXrXZPTDWifZsi+7QEH_c8S-vzWSL@mail.gmail.com>
-------- Original-Nachricht --------
> Datum: Tue, 15 Mar 2011 17:44:49 +0100
> Von: nello martuscielli <ppc.addon@gmail.com>
> An:
> CC: linuxppc-dev@lists.ozlabs.org, "acrux @ cruxppc" <acrux_it@libero.it>
> Betreff: Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
> ok, it seems that no one is interested to fix Pegasos1 G3 600MHz
> support.
>
> But if someone is capable (i don't have this skill) here what it
> happens reading from serial debug console untill it freezes with
> linux-2.6.36.4
>
> Pegasos Boot Strap (c) 2002 bplan GmbH
> Running on CPU PVR:00083311
> PLL setting : 00000001
> Enable L1 ICache...
> Done.
> Setting ROM Defaults...
> Done.
> Configuring SDRAM...
> 08000000
> 10000000
> Delaying...Done.
> RAMSIZE = 18000000
> 00000004
> Reading W83194 : 00FFFFFFFFFF0000
> Done.
> Setting Front Side Bus to 100MHz...
> Done.
> Releasing IDE reset ...
> Done.
> Configuring Legacy Devices
> Initializing KBD...
> Done.
> PLL setting : 00000003
> 10000000
> Done.
> FFFFFFFF
> BIOS: Stage 2 entered arg(FFFC0000,00000000,18000000)
> BIOS: MachineInfo at 0FFFFE68
> BIOS: set MemPool limit to BAT size (old=18000000 new=10000000)
> BIOS: 0F6FFFE8 bytes added to mempool
> LoadFromRFS: starting
> LoadFromRFS: lib module 00 has abs load adr at 00C00000
> CopyModule: start
> CopyModule: load address : 00C00000
> CopyModule: copy module to ram...done
> ModuleCopy: expanding... done
> LoadFromRFS: 00000001 modules out of 00000001 loaded
> InitLib: start
> InitLib: call module as OF
> allocated g_e=0xFD00008 (len=19232)
> install_root: pkg=0xFD53B90
> after init_environ e=0xFD00008
> running nvramrc...
> after running nvramrc
> no/bad nvramrc - performing default startup script
> Bus addresses:
> 253@2
> I/O addresses:
> 7936@FE002100
> Memory addresses:
> 127M@88040000
> 1.3G@98000000
> Prefetchable memory addresses:
> install_ata_disk_driver: reg=0x1000
> init_drive: reset controller 0x1000/0x100E
> init_drive: allow 4-bits for heads
> init_drive: select drive 0
> init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x0 cyl_hi=0x0
> init_drive: error=0x1 status=0x50 status2=0x50
> init_drive: identify drive: atapi=0
> install_ata_disk_driver: return no error (0)
> install_ata_disk_driver: reg=0x1000
> init_drive: allow 4-bits for heads
> init_drive: select drive 1
> init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x14 cyl_hi=0xEB
> init_drive: error=0x1 status=0x0 status2=0x0
> init_drive: identify drive: atapi=1
> atapi_cmd: cmdlen=12
> atapi_cmd: inlen=8 len=65534
> install_ata_disk_driver: return no error (0)
> install_ata_disk_driver: reg=0x1010
> init_drive: reset controller 0x1010/0x101E
> init_drive: allow 4-bits for heads
> init_drive: select drive 0
> init_drive: seccnt=0x20 sector=0x20 cyl_lo=0x20 cyl_hi=0x20
> init_drive: error=0x20 status=0x20 status2=0x20
> ATA-wait-ready: timeout: status=0x20
> init_drive: failed
> install_ata_disk_driver: reg=0x1010
> init_drive: allow 4-bits for heads
> init_drive: select drive 1
> init_drive: seccnt=0x30 sector=0x30 cyl_lo=0x30 cyl_hi=0x30
> init_drive: error=0x30 status=0x30 status2=0x30
> ATA-wait-ready: timeout: status=0x30
> init_drive: failed
> Bus addresses:
> 254@2
> I/O addresses:
> 8@FE001038
> 3072@FE001400
> 48K@FE004000
> Memory addresses:
> 1792@A0000100
> 1.2G@A0001000
> Prefetchable memory addresses:
> 12M@FD400000
> F_INSTALL_CONSOLE: BEGIN
> F_INSTALL_CONSOLE: ALIASING SCREEN
> F_INSTALL_CONSOLE: ALIASING KBD
> EMULATION INT HANDLER ENTERED WITH:
> INT NO: 15
>
> EAX=0003 EBX=1111 ECX=2222 EDX=3333 ESP=0000 EBP=5555 ESI=6666 EDI=7777
> AX=4E08 BX=C505 CX=0003 DX=202A SP=6CAA BP=5555 SI=5CF9 DI=7777
> DS=C000 ES=BAD0 SS=C000 CS=F000 IP=FE15 NV UP -- PL ZR NA PE NC
> CS:IP = F4 C558 C000 0244 3000 0000 01B4 AC63 0200
> UNHANDLED INT 10 FUNCTION 0007 WITHIN EMULATION
> F_INSTALL_CONSOLE: END
> auto-booting...
> do_load: dev="" dlen=0 args="" alen=0
> do_load: alstr=""
> do_load: path doesn't start with /
> do_load: <diag-device> == <eth>
> do_load: no args..use the default
> do_load: <diag-file> == <diag>
> try_load: dev="eth" dlen=3 args="diag" alen=4
> entering main read/eval loop...
>
> [...]
> atapi_cmd: cmdlen=12
> atapi_cmd: inlen=2048 len=2048
> iso_walk: read: name="zImage.chrp" extent=0x44FD size=0x337272 ret=no
> error
> iso9660: return R_END
> file_system: return end (-4089)
> disk-label return len=3371634 ret=end (-4089)
> ata_disk_close
> disk-label close:
> checking exec type Fcode
> fcode_is_exec: load=0x400000 loadlen=3371634
> checking exec type Forth
> checking exec type ELF
> f_go:
> checking exec type Fcode
> fcode_is_exec: load=0x400000 loadlen=3371634
> checking exec type Forth
> checking exec type ELF
> alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> 0xFFFFFFFF, size 0x332000, addr 0x300000
> alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> 0xFD54910 u2 0xFD54914 u3 0xFD54918
> alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x300000
> size 0xFD00000
> alloc_constrained: fsblock 0x0
> alloc_constrained: addr[] 0x300000
> alloc_constrained: bsize[] 0xFD00000
> alloc_constrained: passed min check
> alloc_constrained: addr 0x300000, align 0xFFF, off 0x69696969
> sum 0x0
> alloc_constrained: passed align check
> alloc_constrained: passed max check
> alloc_constrained: passed mask check
> alloc_constrained: passed full size check
> alloc_constrained: passed size check
> alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> 0xFFFFFFFF, size 0x6883C0, addr 0x632000
> alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> 0xFD54910 u2 0xFD54914 u3 0xFD54918
> alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x632000
> size 0xF9CE000
> alloc_constrained: fsblock 0x0
> alloc_constrained: addr[] 0x632000
> alloc_constrained: bsize[] 0xF9CE000
> alloc_constrained: passed min check
> alloc_constrained: addr 0x632000, align 0xFFF, off 0x0
> sum 0x0
> alloc_constrained: passed align check
> alloc_constrained: passed max check
> alloc_constrained: passed mask check
> alloc_constrained: passed full size check
> alloc_constrained: passed size check
>
>
>
> and here giving a try with a smaller (1.9MB) linux boot kernel
> [...]
> atapi_cmd: cmdlen=12
> atapi_cmd: inlen=2048 len=2048
> iso_walk: read: name="zImage.chrp" extent=0x3CC size=0x1D8A1A ret=no error
> iso9660: return R_END
> file_system: return end (-4089)
> disk-label return len=1935898 ret=end (-4089)
> ata_disk_close
> disk-label close:
> checking exec type Fcode
> fcode_is_exec: load=0x400000 loadlen=1935898
> checking exec type Forth
> checking exec type ELF
> f_go:
> checking exec type Fcode
> fcode_is_exec: load=0x400000 loadlen=1935898
> checking exec type Forth
> checking exec type ELF
> alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> 0xFFFFFFFF, size 0x1D3000, addr 0x300000
> alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> 0xFD54910 u2 0xFD54914 u3 0xFD54918
> alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x300000
> size 0xFD00000
> alloc_constrained: fsblock 0x0
> alloc_constrained: addr[] 0x300000
> alloc_constrained: bsize[] 0xFD00000
> alloc_constrained: passed min check
> alloc_constrained: addr 0x300000, align 0xFFF, off 0x69696969
> sum 0x0
> alloc_constrained: passed align check
> alloc_constrained: passed max check
> alloc_constrained: passed mask check
> alloc_constrained: passed full size check
> alloc_constrained: passed size check
> alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> 0xFFFFFFFF, size 0x3AC9A0, addr 0x4D3000
> alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> 0xFD54910 u2 0xFD54914 u3 0xFD54918
> alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x4D3000
> size 0xFB2D000
> alloc_constrained: fsblock 0x0
> alloc_constrained: addr[] 0x4D3000
> alloc_constrained: bsize[] 0xFB2D000
> alloc_constrained: passed min check
> alloc_constrained: addr 0x4D3000, align 0xFFF, off 0x0
> sum 0x0
> alloc_constrained: passed align check
> alloc_constrained: passed max check
> alloc_constrained: passed mask check
> alloc_constrained: passed full size check
> alloc_constrained: passed size check
I don't know much about the Pegasos OF, but did you give GRUB2 for OF
a try? Maybe it can boot a newer Linux kernel, if it is not a device
tree related problem.
On the other side you mentioned this workaround in
arch/ppc/kernel/prom_init.c to me some time ago:
unsigned long __init prom_init(int r3, int r4, prom_entry pp) :
> node = call_prom("finddevice", 1, 1, "/");
> rc = call_prom("getprop", 4, 1, node, "model", model, sizeof(model));
> if (rc > 0 && !strncmp (model, "Pegasos", 7)
> && strncmp (model, "Pegasos2", 8)) {
> /* Pegasos 1 has a broken translate method in the OF,
> * and furthermore the BATs are mapped 1:1 so the phys
> * address calculated above is correct, so let's use
> * it directly.
> */
> } else if (offset == 0) {
> /* If we are already running at 0xc0000000, we assume we were
> * loaded by an OF bootloader which did set a BAT for us.
> * This breaks OF translate so we force phys to be 0.
> */
> prom_print("(already at 0xc0000000) phys=0\n");
> phys = 0;
> } else if (call_prom("getprop", 4, 1, prom_chosen, "mmu",
> &prom_mmu, sizeof(prom_mmu)) <= 0) {
> prom_print(" no MMU found\n");
> } else if (call_prom_ret("call-method", 4, 4, result, "translate",
> prom_mmu, &_stext, 1) != 0) {
> prom_print(" (translate failed)\n");
> } else {
> /* We assume the phys. address size is 3 cells */
> phys = result[2];
> }
Can anybody comment, if this "broken translate method in the OF" would
still be needed for arch/powerpc?
Gerhard
--
Schon gehört? GMX hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://www.gmx.net/de/go/toolbar
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_msi: Handle msi-available-ranges better
From: Kumar Gala @ 2011-03-15 17:58 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110117202528.GB561@udp111988uds.am.freescale.net>
On Jan 17, 2011, at 2:25 PM, Scott Wood wrote:
> Now handles multiple ranges, doesn't make assumptions about interrupt
> specifier format, and doesn't claim interrupts that don't correspond =
to an
> available range.
>=20
> Also has some better error checking.
>=20
> The device tree binding is updated to clarify some existing =
assumptions.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Documentation/powerpc/dts-bindings/fsl/msi-pic.txt | 9 ++-
> arch/powerpc/sysdev/fsl_msi.c | 92 =
++++++++++++--------
> 2 files changed, 64 insertions(+), 37 deletions(-)
applied
- k=
^ permalink raw reply
* Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
From: Sven Luther @ 2011-03-15 17:49 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: nello martuscielli, linuxppc-dev, acrux_it
In-Reply-To: <20110315171448.100300@gmx.net>
On Tue, Mar 15, 2011 at 06:14:48PM +0100, Gerhard Pircher wrote:
>
> -------- Original-Nachricht --------
> > Datum: Tue, 15 Mar 2011 17:44:49 +0100
> > Von: nello martuscielli <ppc.addon@gmail.com>
> > An:
> > CC: linuxppc-dev@lists.ozlabs.org, "acrux @ cruxppc" <acrux_it@libero.it>
> > Betreff: Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
>
> > ok, it seems that no one is interested to fix Pegasos1 G3 600MHz
> > support.
> >
> > But if someone is capable (i don't have this skill) here what it
> > happens reading from serial debug console untill it freezes with
> > linux-2.6.36.4
> >
> > Pegasos Boot Strap (c) 2002 bplan GmbH
> > Running on CPU PVR:00083311
> > PLL setting : 00000001
> > Enable L1 ICache...
> > Done.
> > Setting ROM Defaults...
> > Done.
> > Configuring SDRAM...
> > 08000000
> > 10000000
> > Delaying...Done.
> > RAMSIZE = 18000000
> > 00000004
> > Reading W83194 : 00FFFFFFFFFF0000
> > Done.
> > Setting Front Side Bus to 100MHz...
> > Done.
> > Releasing IDE reset ...
> > Done.
> > Configuring Legacy Devices
> > Initializing KBD...
> > Done.
> > PLL setting : 00000003
> > 10000000
> > Done.
> > FFFFFFFF
> > BIOS: Stage 2 entered arg(FFFC0000,00000000,18000000)
> > BIOS: MachineInfo at 0FFFFE68
> > BIOS: set MemPool limit to BAT size (old=18000000 new=10000000)
> > BIOS: 0F6FFFE8 bytes added to mempool
> > LoadFromRFS: starting
> > LoadFromRFS: lib module 00 has abs load adr at 00C00000
> > CopyModule: start
> > CopyModule: load address : 00C00000
> > CopyModule: copy module to ram...done
> > ModuleCopy: expanding... done
> > LoadFromRFS: 00000001 modules out of 00000001 loaded
> > InitLib: start
> > InitLib: call module as OF
> > allocated g_e=0xFD00008 (len=19232)
> > install_root: pkg=0xFD53B90
> > after init_environ e=0xFD00008
> > running nvramrc...
> > after running nvramrc
> > no/bad nvramrc - performing default startup script
> > Bus addresses:
> > 253@2
> > I/O addresses:
> > 7936@FE002100
> > Memory addresses:
> > 127M@88040000
> > 1.3G@98000000
> > Prefetchable memory addresses:
> > install_ata_disk_driver: reg=0x1000
> > init_drive: reset controller 0x1000/0x100E
> > init_drive: allow 4-bits for heads
> > init_drive: select drive 0
> > init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x0 cyl_hi=0x0
> > init_drive: error=0x1 status=0x50 status2=0x50
> > init_drive: identify drive: atapi=0
> > install_ata_disk_driver: return no error (0)
> > install_ata_disk_driver: reg=0x1000
> > init_drive: allow 4-bits for heads
> > init_drive: select drive 1
> > init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x14 cyl_hi=0xEB
> > init_drive: error=0x1 status=0x0 status2=0x0
> > init_drive: identify drive: atapi=1
> > atapi_cmd: cmdlen=12
> > atapi_cmd: inlen=8 len=65534
> > install_ata_disk_driver: return no error (0)
> > install_ata_disk_driver: reg=0x1010
> > init_drive: reset controller 0x1010/0x101E
> > init_drive: allow 4-bits for heads
> > init_drive: select drive 0
> > init_drive: seccnt=0x20 sector=0x20 cyl_lo=0x20 cyl_hi=0x20
> > init_drive: error=0x20 status=0x20 status2=0x20
> > ATA-wait-ready: timeout: status=0x20
> > init_drive: failed
> > install_ata_disk_driver: reg=0x1010
> > init_drive: allow 4-bits for heads
> > init_drive: select drive 1
> > init_drive: seccnt=0x30 sector=0x30 cyl_lo=0x30 cyl_hi=0x30
> > init_drive: error=0x30 status=0x30 status2=0x30
> > ATA-wait-ready: timeout: status=0x30
> > init_drive: failed
> > Bus addresses:
> > 254@2
> > I/O addresses:
> > 8@FE001038
> > 3072@FE001400
> > 48K@FE004000
> > Memory addresses:
> > 1792@A0000100
> > 1.2G@A0001000
> > Prefetchable memory addresses:
> > 12M@FD400000
> > F_INSTALL_CONSOLE: BEGIN
> > F_INSTALL_CONSOLE: ALIASING SCREEN
> > F_INSTALL_CONSOLE: ALIASING KBD
> > EMULATION INT HANDLER ENTERED WITH:
> > INT NO: 15
> >
> > EAX=0003 EBX=1111 ECX=2222 EDX=3333 ESP=0000 EBP=5555 ESI=6666 EDI=7777
> > AX=4E08 BX=C505 CX=0003 DX=202A SP=6CAA BP=5555 SI=5CF9 DI=7777
> > DS=C000 ES=BAD0 SS=C000 CS=F000 IP=FE15 NV UP -- PL ZR NA PE NC
> > CS:IP = F4 C558 C000 0244 3000 0000 01B4 AC63 0200
> > UNHANDLED INT 10 FUNCTION 0007 WITHIN EMULATION
> > F_INSTALL_CONSOLE: END
> > auto-booting...
> > do_load: dev="" dlen=0 args="" alen=0
> > do_load: alstr=""
> > do_load: path doesn't start with /
> > do_load: <diag-device> == <eth>
> > do_load: no args..use the default
> > do_load: <diag-file> == <diag>
> > try_load: dev="eth" dlen=3 args="diag" alen=4
> > entering main read/eval loop...
> >
> > [...]
> > atapi_cmd: cmdlen=12
> > atapi_cmd: inlen=2048 len=2048
> > iso_walk: read: name="zImage.chrp" extent=0x44FD size=0x337272 ret=no
> > error
> > iso9660: return R_END
> > file_system: return end (-4089)
> > disk-label return len=3371634 ret=end (-4089)
> > ata_disk_close
> > disk-label close:
> > checking exec type Fcode
> > fcode_is_exec: load=0x400000 loadlen=3371634
> > checking exec type Forth
> > checking exec type ELF
> > f_go:
> > checking exec type Fcode
> > fcode_is_exec: load=0x400000 loadlen=3371634
> > checking exec type Forth
> > checking exec type ELF
> > alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> > alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> > 0xFFFFFFFF, size 0x332000, addr 0x300000
> > alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> > 0xFD54910 u2 0xFD54914 u3 0xFD54918
> > alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x300000
> > size 0xFD00000
> > alloc_constrained: fsblock 0x0
> > alloc_constrained: addr[] 0x300000
> > alloc_constrained: bsize[] 0xFD00000
> > alloc_constrained: passed min check
> > alloc_constrained: addr 0x300000, align 0xFFF, off 0x69696969
> > sum 0x0
> > alloc_constrained: passed align check
> > alloc_constrained: passed max check
> > alloc_constrained: passed mask check
> > alloc_constrained: passed full size check
> > alloc_constrained: passed size check
> > alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> > alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> > 0xFFFFFFFF, size 0x6883C0, addr 0x632000
> > alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> > 0xFD54910 u2 0xFD54914 u3 0xFD54918
> > alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x632000
> > size 0xF9CE000
> > alloc_constrained: fsblock 0x0
> > alloc_constrained: addr[] 0x632000
> > alloc_constrained: bsize[] 0xF9CE000
> > alloc_constrained: passed min check
> > alloc_constrained: addr 0x632000, align 0xFFF, off 0x0
> > sum 0x0
> > alloc_constrained: passed align check
> > alloc_constrained: passed max check
> > alloc_constrained: passed mask check
> > alloc_constrained: passed full size check
> > alloc_constrained: passed size check
> >
> >
> >
> > and here giving a try with a smaller (1.9MB) linux boot kernel
> > [...]
> > atapi_cmd: cmdlen=12
> > atapi_cmd: inlen=2048 len=2048
> > iso_walk: read: name="zImage.chrp" extent=0x3CC size=0x1D8A1A ret=no error
> > iso9660: return R_END
> > file_system: return end (-4089)
> > disk-label return len=1935898 ret=end (-4089)
> > ata_disk_close
> > disk-label close:
> > checking exec type Fcode
> > fcode_is_exec: load=0x400000 loadlen=1935898
> > checking exec type Forth
> > checking exec type ELF
> > f_go:
> > checking exec type Fcode
> > fcode_is_exec: load=0x400000 loadlen=1935898
> > checking exec type Forth
> > checking exec type ELF
> > alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> > alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> > 0xFFFFFFFF, size 0x1D3000, addr 0x300000
> > alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> > 0xFD54910 u2 0xFD54914 u3 0xFD54918
> > alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x300000
> > size 0xFD00000
> > alloc_constrained: fsblock 0x0
> > alloc_constrained: addr[] 0x300000
> > alloc_constrained: bsize[] 0xFD00000
> > alloc_constrained: passed min check
> > alloc_constrained: addr 0x300000, align 0xFFF, off 0x69696969
> > sum 0x0
> > alloc_constrained: passed align check
> > alloc_constrained: passed max check
> > alloc_constrained: passed mask check
> > alloc_constrained: passed full size check
> > alloc_constrained: passed size check
> > alloc_aligned: a 0xFD548E8 align 0xFD5491C size 0xFD54918 addr 0xFD54914
> > alloc_constrained: min 0x0, max 0xFFFFFFFF, align 0x1000, mask
> > 0xFFFFFFFF, size 0x3AC9A0, addr 0x4D3000
> > alloc_constrained: acells 0x1 scells 0x1 t1 0xC t2 0xFD5490C u1
> > 0xFD54910 u2 0xFD54914 u3 0xFD54918
> > alloc_constrained: allocator_block 0xFD54930, next 0x0 addr 0x4D3000
> > size 0xFB2D000
> > alloc_constrained: fsblock 0x0
> > alloc_constrained: addr[] 0x4D3000
> > alloc_constrained: bsize[] 0xFB2D000
> > alloc_constrained: passed min check
> > alloc_constrained: addr 0x4D3000, align 0xFFF, off 0x0
> > sum 0x0
> > alloc_constrained: passed align check
> > alloc_constrained: passed max check
> > alloc_constrained: passed mask check
> > alloc_constrained: passed full size check
> > alloc_constrained: passed size check
>
> I don't know much about the Pegasos OF, but did you give GRUB2 for OF
> a try? Maybe it can boot a newer Linux kernel, if it is not a device
> tree related problem.
>
> On the other side you mentioned this workaround in
> arch/ppc/kernel/prom_init.c to me some time ago:
>
> unsigned long __init prom_init(int r3, int r4, prom_entry pp) :
> > node = call_prom("finddevice", 1, 1, "/");
> > rc = call_prom("getprop", 4, 1, node, "model", model, sizeof(model));
> > if (rc > 0 && !strncmp (model, "Pegasos", 7)
> > && strncmp (model, "Pegasos2", 8)) {
> > /* Pegasos 1 has a broken translate method in the OF,
> > * and furthermore the BATs are mapped 1:1 so the phys
> > * address calculated above is correct, so let's use
> > * it directly.
> > */
> > } else if (offset == 0) {
> > /* If we are already running at 0xc0000000, we assume we were
> > * loaded by an OF bootloader which did set a BAT for us.
> > * This breaks OF translate so we force phys to be 0.
> > */
> > prom_print("(already at 0xc0000000) phys=0\n");
> > phys = 0;
> > } else if (call_prom("getprop", 4, 1, prom_chosen, "mmu",
> > &prom_mmu, sizeof(prom_mmu)) <= 0) {
> > prom_print(" no MMU found\n");
> > } else if (call_prom_ret("call-method", 4, 4, result, "translate",
> > prom_mmu, &_stext, 1) != 0) {
> > prom_print(" (translate failed)\n");
> > } else {
> > /* We assume the phys. address size is 3 cells */
> > phys = result[2];
> > }
>
> Can anybody comment, if this "broken translate method in the OF" would
> still be needed for arch/powerpc?
Well, since this is long dead hardware not produced anymore, i don't see how the
OF could have unbroken itself by moving to powerpc.
It has been age since i looked into this, but to the best of my knowledge (and i
wrote the above code or at least the earlier versions) it should be still broken.
But YMMV, ...
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] [v2] watchdog: booke_wdt: clean up status messages
From: Wim Van Sebroeck @ 2011-03-15 18:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: wim, linux-watchdog, Timur Tabi, linuxppc-dev
In-Reply-To: <C8B1E427-5A9D-4ED2-9C39-C1D8201E636E@kernel.crashing.org>
Hi Kumar,
I allready had it in the watchdog tree for a couple of weeks (and thus also in linux-next).
Are you going to sent it of to Linus or will I sent it over via the watchdog tree?
Thanks in advance,
Wim.
>
> On Feb 8, 2011, at 5:39 PM, Timur Tabi wrote:
>
> > Improve the status messages that are displayed during some operations of the
> > PowerPC watchdog timer driver. When the watchdog is enabled, the timeout is
> > displayed as a number of seconds, instead of an obscure "period". The "period"
> > is the position of a bit in a 64-bit timer register. The higher the value,
> > the quicker the watchdog timeout occurs. Some people chose a high "period"
> > value for the timer and get confused as to why the board resets within a
> > few seconds.
> >
> > Messages displayed during open and close are now debug messages, so that they
> > don't clutter the console by default. Finally, printk() is replaced with the
> > pr_xxx() equivalent.
> >
> > Signed-off-by: Timur Tabi <timur@freescale.com>
> > ---
> > drivers/watchdog/booke_wdt.c | 19 +++++++++----------
> > 1 files changed, 9 insertions(+), 10 deletions(-)
>
> applied
>
> - k
^ permalink raw reply
* Re: [PATCH] [v2] watchdog: booke_wdt: clean up status messages
From: Kumar Gala @ 2011-03-15 18:47 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: linux-watchdog, Timur Tabi, linuxppc-dev
In-Reply-To: <20110315181904.GM1751@infomag.iguana.be>
On Mar 15, 2011, at 1:19 PM, Wim Van Sebroeck wrote:
> Hi Kumar,
>=20
> I allready had it in the watchdog tree for a couple of weeks (and thus =
also in linux-next).
> Are you going to sent it of to Linus or will I sent it over via the =
watchdog tree?
>=20
> Thanks in advance,
> Wim.
I'll drop it from my tree.
- k=
^ permalink raw reply
* [PATCH] update name of pic-no-reset property
From: Stuart Yoder @ 2011-03-15 18:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stuart Yoder
From: Stuart Yoder <stuart.yoder@freescale.com>
-changed name from 'no-reset' to 'pic-not-reset' be consisent with
Meador Inge's open pic binding patch
-update definition
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
---
Documentation/powerpc/dts-bindings/fsl/mpic.txt | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
index fdf97c5..8b76e0f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/mpic.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
@@ -44,7 +44,7 @@ PROPERTIES
Value type: <u32>
Definition: Shall be 0.
- - no-reset
+ - pic-no-reset
Usage: optional
Value type: <empty>
Definition: The presence of this property specifies that the
@@ -53,7 +53,10 @@ PROPERTIES
configuration registers to a sane state-- masked or
directed at other cores. This ensures that the client
program will not receive interrupts for sources not belonging
- to the client.
+ to the client. The presence of this property also mandates
+ that any initialization related to interrupt sources shall
+ be limited to sources explicitly referenced in the device tree.
+
INTERRUPT SPECIFIER DEFINITION
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH] update name of pic-no-reset property
From: Kumar Gala @ 2011-03-15 19:09 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev
In-Reply-To: <1300214278-1588-1-git-send-email-stuart.yoder@freescale.com>
On Mar 15, 2011, at 1:37 PM, Stuart Yoder wrote:
> From: Stuart Yoder <stuart.yoder@freescale.com>
>
> -changed name from 'no-reset' to 'pic-not-reset' be consisent with
> Meador Inge's open pic binding patch
> -update definition
>
> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
> ---
> Documentation/powerpc/dts-bindings/fsl/mpic.txt | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
applied, I squashed this with the mpic binding patch.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: sysdev: fix signedness bug
From: Kumar Gala @ 2011-03-15 19:19 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Harninder Rai, devicetree-discuss, kernel-janitors, linux-kernel,
Paul Mackerras, linuxppc-dev, Vivek Mahajan
In-Reply-To: <1287327102-9068-1-git-send-email-segooon@gmail.com>
On Oct 17, 2010, at 9:51 AM, Vasiliy Kulikov wrote:
> sram_params.sram_size and sram_params.sram_offset were unsigned.
> If get_cache_sram_size() or get_cache_sram_offset() returns error code
> then it is not seen to the caller. Made sram_size and sram_offset signed.
>
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-booke: Add e500mc smp defconfig
From: Kumar Gala @ 2011-03-15 19:23 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinJq78ZQbW_r0mJqA884-Mt+a_m6pJSLn-PAGuT@mail.gmail.com>
On Oct 14, 2010, at 8:51 AM, Timur Tabi wrote:
> On Thu, Oct 14, 2010 at 8:25 AM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>=20
>> +CONFIG_MATH_EMULATION=3Dy
>=20
> Don't these chips have hardware FP?
removed.
>=20
>> +CONFIG_E1000=3Dy
>> +CONFIG_E1000E=3Dy
>=20
> Are you sure you want these on by default? We may use the E1000 cards
> in-house, but I don't know if our customers do.
leaving, customers can always disable
>> +CONFIG_MSDOS_FS=3Dm
>> +CONFIG_VFAT_FS=3Dy
>> +CONFIG_NTFS_FS=3Dy
leaving since we deal with USB flashes and MMC cards which could be =
MSDOS, VFAT, etc.
- k=
^ permalink raw reply
* Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
From: Gerhard Pircher @ 2011-03-15 20:08 UTC (permalink / raw)
To: Sven Luther; +Cc: ppc.addon, linuxppc-dev, acrux_it
In-Reply-To: <20110315174924.GA24001@z-innov.com>
-------- Original-Nachricht --------
> Datum: Tue, 15 Mar 2011 18:49:24 +0100
> Von: Sven Luther <sven@z-innov.com>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: nello martuscielli <ppc.addon@gmail.com>, linuxppc-dev@lists.ozlabs.org, acrux_it@libero.it
> Betreff: Re: any chance to use a modern linux kernel on Pegasos1 G3 ?
> On Tue, Mar 15, 2011 at 06:14:48PM +0100, Gerhard Pircher wrote:
[...]
> > On the other side you mentioned this workaround in
> > arch/ppc/kernel/prom_init.c to me some time ago:
> >
> > unsigned long __init prom_init(int r3, int r4, prom_entry pp) :
> > > node = call_prom("finddevice", 1, 1, "/");
> > > rc = call_prom("getprop", 4, 1, node, "model", model,
> sizeof(model));
> > > if (rc > 0 && !strncmp (model, "Pegasos", 7)
> > > && strncmp (model, "Pegasos2", 8)) {
> > > /* Pegasos 1 has a broken translate method in the OF,
> > > * and furthermore the BATs are mapped 1:1 so the phys
> > > * address calculated above is correct, so let's use
> > > * it directly.
> > > */
> > > } else if (offset == 0) {
> > > /* If we are already running at 0xc0000000, we assume
> we were
> > > * loaded by an OF bootloader which did set a BAT for
> us.
> > > * This breaks OF translate so we force phys to be 0.
> > > */
> > > prom_print("(already at 0xc0000000) phys=0\n");
> > > phys = 0;
> > > } else if (call_prom("getprop", 4, 1, prom_chosen, "mmu",
> > > &prom_mmu, sizeof(prom_mmu)) <= 0) {
> > > prom_print(" no MMU found\n");
> > > } else if (call_prom_ret("call-method", 4, 4, result,
> "translate",
> > > prom_mmu, &_stext, 1) != 0) {
> > > prom_print(" (translate failed)\n");
> > > } else {
> > > /* We assume the phys. address size is 3 cells */
> > > phys = result[2];
> > > }
> >
> > Can anybody comment, if this "broken translate method in the OF" would
> > still be needed for arch/powerpc?
>
> Well, since this is long dead hardware not produced anymore, i don't see
> how the OF could have unbroken itself by moving to powerpc.
>
> It has been age since i looked into this, but to the best of my knowledge
> (and i wrote the above code or at least the earlier versions) it should
> be still broken.
Any idea then, how the workaround can be ported to arch/powerpc/ or if
there is a better one available?
regards,
Gerhard
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
^ 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