* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-29 12:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070829074902.7634024044@gemini.denx.de>
Hi,
>
> Probably it does not hang, but you just don't see any console output.
> Eventually you just forgot to set the correct console device
> (/dev/ttyPSC0) or console speed.
I checked this. I think the TQM5200 is really hanging after the ...OK
because I have activated the telnet server and normally I'm able to
connect to the device after booting via ethernet. No ping, no telnet.
With an older 2.6.19.2 kernel this was O.K.
>
> Also, you need a recent version of U-Boot (for example 99c2fdab or
> later).
I'm using U-Boot 1.2.0-gbc2b9c33-dirty (Feb 22 2007 - 09:53:14). Is that
recent enough? (I don't know exactly what you mean with "99c2fdab", is
this the second number after "1.2.0-"?)
>
> Try something like this:
>
> => tftp 200000 /tftpboot/tqm5200/uImage
> => tftp 400000 /tftpboot/tqm5200/tqm5200.dtb
Maybe the problem is the missing tqm5200.dtb file. I have booted the
kernel without it (just bootm 200000). Does the kernel need this file? I
found a tqm5200.dts file the the kernel sources, but the device tree
compiler (dtc) seems not to be in the 4.1 ELDK. Do I have to install
this compiler and build the appropriate dtb file?
>
> Please note that the device tree we have at the moment is for the
> TQM5200 only and does not include support for the TQM5200S.
>
> But probably you just had the same problem - missing or bad console
> device specification.
>
In older kernels it was O.K. just to uncheck the SM501 drivers in the
kernel configuration. Has this changed?
Thanks and bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: [PATCH 1/4] PowerPC 440EPx: Sequoia bootwrapper
From: Stefan Roese @ 2007-08-29 12:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46D56226.8020500@ru.mvista.com>
On Wednesday 29 August 2007, Valentine Barshak wrote:
> >> +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
> >
> > Hm. Having these as just DDR_... seems like it would lead to confusion
> > if there are other DDR controllers that get added later. But I'm not
> > too picky either way.
>
> What names would you suggest? DDR_DENALI_... looks too long :)
> The names have been taken from the docs, I've just prefixed them with DDR_.
It's such a generic macro and not Denali or even SDRAM specific. So it really
should be no problem to keep it as is.
Just my 0.02$.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 1/4] PowerPC 440EPx: Sequoia bootwrapper
From: Josh Boyer @ 2007-08-29 12:26 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200708291428.23522.sr@denx.de>
On Wed, 29 Aug 2007 14:28:23 +0200
Stefan Roese <sr@denx.de> wrote:
> On Wednesday 29 August 2007, Valentine Barshak wrote:
> > >> +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
> > >
> > > Hm. Having these as just DDR_... seems like it would lead to confusion
> > > if there are other DDR controllers that get added later. But I'm not
> > > too picky either way.
> >
> > What names would you suggest? DDR_DENALI_... looks too long :)
> > The names have been taken from the docs, I've just prefixed them with DDR_.
>
> It's such a generic macro and not Denali or even SDRAM specific. So it really
> should be no problem to keep it as is.
I wasn't talking about DDR_GET_VAL. I meant having the DDR registers
defines just as "DDR_START", "DDR_START_SHIFT", etc could be confusing
later.
But I don't really see a need to change it at the moment. We can
prefix the with something else if a conflicting DDR controller ever
shows up.
josh
^ permalink raw reply
* Re: [PATCH 1/4] PowerPC 440EPx: Sequoia bootwrapper
From: Valentine Barshak @ 2007-08-29 12:13 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20070829063323.GG3206@localhost.localdomain>
David Gibson wrote:
> On Tue, Aug 28, 2007 at 08:56:10PM +0400, Valentine Barshak wrote:
>> Bootwrapper code for AMCC PPC440EPx Sequoia.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> [snip]
>> +static void sequoia_fixups(void)
>> +{
>> + unsigned long sysclk = 33333333;
>> +
>> + ibm440ep_fixup_clocks(sysclk, 11059200);
>> + ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
>> + ibm4xx_denali_fixup_memsize();
>> + dt_fixup_mac_addresses(sequoia_mac0, sequoia_mac1);
>> +}
>> +
>> +static void sequoia_init(void *mac0, void *mac1)
>
> No need to separate this function out, just drop it into
> platform_init(). Also no need for the seqouia_mac* variables - they
> were in ebony to handle the cuboot vs. openbios variants. For
> sequoia, you can just pull the values straight from the bd_t in
> sequoia_fixups()
>
OK,
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH 1/4] PowerPC 440EPx: Sequoia bootwrapper
From: Valentine Barshak @ 2007-08-29 12:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070828130921.13809093@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, 28 Aug 2007 20:56:10 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> +/* 4xx DDR1/2 Denali memory controller support */
>> +/* DDR0 registers */
>> +#define DDR0_02 2
>> +#define DDR0_08 8
>> +#define DDR0_10 10
>> +#define DDR0_14 14
>> +#define DDR0_42 42
>> +#define DDR0_43 43
>> +
>> +/* DDR0_02 */
>> +#define DDR_START 0x1
>> +#define DDR_START_SHIFT 0
>> +#define DDR_MAX_CS_REG 0x3
>> +#define DDR_MAX_CS_REG_SHIFT 24
>> +#define DDR_MAX_COL_REG 0xf
>> +#define DDR_MAX_COL_REG_SHIFT 16
>> +#define DDR_MAX_ROW_REG 0xf
>> +#define DDR_MAX_ROW_REG_SHIFT 8
>> +/* DDR0_08 */
>> +#define DDR_DDR2_MODE 0x1
>> +#define DDR_DDR2_MODE_SHIFT 0
>> +/* DDR0_10 */
>> +#define DDR_CS_MAP 0x3
>> +#define DDR_CS_MAP_SHIFT 8
>> +/* DDR0_14 */
>> +#define DDR_REDUC 0x1
>> +#define DDR_REDUC_SHIFT 16
>> +/* DDR0_42 */
>> +#define DDR_APIN 0x7
>> +#define DDR_APIN_SHIFT 24
>> +/* DDR0_43 */
>> +#define DDR_COL_SZ 0x7
>> +#define DDR_COL_SZ_SHIFT 8
>> +#define DDR_BANK8 0x1
>> +#define DDR_BANK8_SHIFT 0
>> +
>> +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
>
> Hm. Having these as just DDR_... seems like it would lead to confusion
> if there are other DDR controllers that get added later. But I'm not
> too picky either way.
What names would you suggest? DDR_DENALI_... looks too long :)
The names have been taken from the docs, I've just prefixed them with DDR_.
Thanks,
Valentine.
>
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/4xx.h linux-2.6/arch/powerpc/boot/4xx.h
>> --- linux-2.6.orig/arch/powerpc/boot/4xx.h 2007-08-27 14:08:42.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/4xx.h 2007-08-28 17:04:51.000000000 +0400
>> @@ -12,6 +12,7 @@
>> #define _POWERPC_BOOT_4XX_H_
>>
>> void ibm4xx_fixup_memsize(void);
>> +void ibm4xx_denali_fixup_memsize(void);
>> void ibm44x_dbcr_reset(void);
>> void ibm40x_dbcr_reset(void);
>> void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1);
>> 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-28 17:21:55.000000000 +0400
>> @@ -0,0 +1,67 @@
>
> <snip>
>
>> +
>> +#include <stdarg.h>
>> +#include <stddef.h>
>> +#include "types.h"
>> +#include "elf.h"
>> +#include "string.h"
>> +#include "stdio.h"
>> +#include "page.h"
>> +#include "ops.h"
>> +#include "dcr.h"
>> +#include "4xx.h"
>> +#include "44x.h"
>> +#include "cuboot.h"
>> +
>> +#define TARGET_4xx
>> +#define TARGET_44x
>> +#include "ppcboot.h"
>> +
>> +static bd_t bd;
>> +static u8 *sequoia_mac0, *sequoia_mac1;
>> +
>> +extern char _dtb_start[];
>> +extern char _dtb_end[];
>
> These got added to ops.h in commit 2f1d4899321be so you don't need to
> specify them here anymore.
OK
>
> josh
^ permalink raw reply
* [PATCH] PS3: fix the bug the major version part is not compared, take2
From: Masakazu Mokuno @ 2007-08-29 11:30 UTC (permalink / raw)
To: paulus; +Cc: 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 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -63,7 +63,8 @@ int ps3_compare_firmware_version(u16 maj
x.minor = minor;
x.rev = rev;
- return (ps3_firmware_version.raw - x.raw);
+ return (ps3_firmware_version.raw > x.raw) -
+ (ps3_firmware_version.raw < x.raw);
}
EXPORT_SYMBOL_GPL(ps3_compare_firmware_version);
--
Masakazu MOKUNO
^ permalink raw reply
* Re: [PATCH] PS3: fix the bug the major version part is not compared
From: Masakazu Mokuno @ 2007-08-29 11:21 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Geert Uytterhoeven, linuxppc-dev, paulus
In-Reply-To: <jehcmj3i3p.fsf@sykes.suse.de>
On Tue, 28 Aug 2007 15:26:50 +0200
Andreas Schwab <schwab@suse.de> wrote:
> 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);
Thank you!
I'll submit new patch.
--
Masakazu MOKUNO
^ permalink raw reply
* linux2.6.17.4 with temac patch running on ML403 hung while initializing from ramdisk
From: angelalinyao @ 2007-08-29 11:12 UTC (permalink / raw)
To: Linuxppc-embedded
Hi, all
I have run linux-xilinx-26.git based on kernel 2.6.17.4 on ML403 successfully.
Then I used a temac patch from mvista (PAULUS)
The system hung while initializing from ramdisk after patched.
I use plb-temac v3.00a and hard_temac v3.00b, with EDK 9.1
The message printed is as follow. Any help would be appreciated.
--------------------------------------------------------------------------------------
loaded at: 00400000 0069013C
board data at: 0068E124 0068E13C
relocated to: 004050E8 00405100
zimage at: 004058B9 00527794
initrd at: 00528000 0068DE1A
avail ram: 00691000 04000000
Linux/PPC load: console=ttyS0,9600 root=/dev/ram rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.17-rc4-smp (linyao@linux-177) (gcc version 3.3.1 (MontaVista 3
.3.1-3.0.10.0300532 2003-12-24)) #17 Wed Aug 29 16:36:51 CS
Xilinx ML403 Reference System (Virtex-4 FX)
Built 1 zonelists
Kernel command line: console=ttyS0,9600 root=/dev/ram rw
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 60604k available (1428k kernel code, 1352k data, 84k init, 0k highmem)
Security Framework v1.0.0 initialized
Capability LSM initial
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1431k freed
seclvl: seclvl_init: seclvl: Failure registering with the kernel.
seclvl: seclvl_init: seclvl: Failure registering with primary security module.
seclvl: Error during initialization: rc = [-22]
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Macintosh non-volatile memory driver v1.1
Linux agpgart interface v0.101 (c) Dave Jones
SyncLink PC Card driver $Revision: 4.34 $
SyncLink PC Card driver $Revision: 4.34 $, tty major#253
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 2) is a 16450
RAMDISK driver initialized: 1 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
oprofile: using timer interrupt.
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 84k init
-----------------------------------------------------------------------------------
System hung here.
linyao
^ permalink raw reply
* Re: [PATCH, RFC] linkstation: implement standby
From: Johannes Berg @ 2007-08-29 10:32 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Stephen Rothwell, linuxppc-dev, Pavel Machek, linux-pm
In-Reply-To: <Pine.LNX.4.60.0708290015580.3552@poirot.grange>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
On Wed, 2007-08-29 at 00:30 +0200, Guennadi Liakhovetski wrote:
> > > +#ifdef CONFIG_PM
> >
> > some of those probably want to be CONFIG_PM_SLEEP now.
>
> Well, I wasn't sure when PM can be used not meaning PM_SLEEP, so, I left
> PM for now. Can certainly change, if it really matters.
You end up compiling more code than necessary if PM_SLEEP is disabled
but PM is enabled (i.e. runtime powermanagement enabled but no sleep
states)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-29 9:29 UTC (permalink / raw)
To: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280744g29cb8e17r6153271cd67117ed@mail.gmail.com>
Step by step i becomes running :)
kernel is booting, root-fs is mounting on systemace, busybox compiled
and rootfs installed (i used klingauf's mkrootfs)
but now it says:
[ 2.964978] Freeing unused kernel memory: 92k init
[ 3.081332] Warning: unable to open an initial console.
[ 3.306406] request_module: runaway loop modprobe binfmt-4c46
[ 3.375612] request_module: runaway loop modprobe binfmt-4c46
[ 3.446800] request_module: runaway loop modprobe binfmt-4c46
and i don't know what this is :(
Can give me a hint, where to look ?
thx
Georg
Grant Likely wrote:
> 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.
>
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
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: ppc_8xx-gcc from eldk strange behaviour
From: DI BACCO ANTONIO - technolabs @ 2007-08-29 9:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20070828190158.GA21155@ld0162-tx32.am.freescale.net>
> C does not specify the signedness of char. If you care, you need to
> explicitly specify.
Sorry, I didn't know this. Anyway I would expect the same behaviour from
both host gcc and ppc_8xx-gcc. In this case host gcc is wrong.=20
Bye,
Antonio.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 1/5] spu_manage: use newer physical-id
From: Ishizaki Kou @ 2007-08-29 8:56 UTC (permalink / raw)
To: krafft; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel, arnd, jk
In-Reply-To: <20070828162011.5356afaa@localhost>
Christian Krafft wrote:
> 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>
Acked-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
It works good on Celleb, thanks. Please apply it to 2.6.23.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: Domen Puncer @ 2007-08-29 8:43 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
In-Reply-To: <20070829061300.GF3206@localhost.localdomain>
On 29/08/07 16:13 +1000, David Gibson wrote:
<snip>
> static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
> {
> struct device_node *dp = dev->node;
> struct resource res;
> struct physmap_flash_info *info;
> - const char **probe_type;
> - const char *of_probe;
> + const char *probe_type = (const char *)match->data;
> const u32 *width;
> int err;
>
> + dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
> + "flash binding\n");
This is printed for new binding too :-)
Other than this, it works fine for me.
Domen
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-29 8:43 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: <46D52B14.8010508@katalix.com>
On Wednesday 29 August 2007 10:15, James Chapman wrote:
> Jan-Bernd Themann wrote:
> > What I'm trying to improve with this approach is interrupt
> > mitigation for NICs where the hardware support for interrupt
> > mitigation is limited. I'm not trying to improve this for NICs
> > that work well with the means their HW provides. I'm aware of
> > the fact that this scheme has it's tradeoffs and certainly
> > can not be as good as a HW approach.
> > So I'm grateful for any ideas that do have less tradeoffs and
> > provide a mechanism to reduce interrupts without depending on
> > HW support of the NIC.
> >
> > In the end I want to reduce the CPU utilization. And one way
> > to do that is LRO which also works only well if there are more
> > then just a very few packets to aggregate. So at least our
> > driver (eHEA) would benefit from a mix of timer based polling
> > and plain NAPI (depending on load situations).
>
> Wouldn't you achieve the same result by enabling hardware interrupt
> mitigation in eHEA in combination with NAPI? Presumably a 10G interface
> has hardware mitigation features?
Quote from above: "What I'm trying to improve with this approach
is interrupt mitigation for NICs where the hardware support for
interrupt mitigation is limited"
So guess why I'm doing that ;-)
>
> > If there is no need for a generic mechanism for this kind of
> > network adapters, then we can just leave this to each device
> > driver.
>
> I've been looking at this from a different angle. My goal is to optimize
> NAPI packet forwarding rates while minimizing packet latency. Using
> hardware interrupt mitigation hurts latency so I'm investigating ways to
> turn it off without risking NAPI poll on/off thrashing at certain packet
> rates.
>
> Jan-Bernd, I think I've found a solution to the issue that you
> highlighted with my scheme yesterday and it doesn't involve generating
> other interrupts using hrtimers etc. :) Initial results are very
> encouraging in my setups. Would you be willing to test it with eHEA? I
> don't have a 10G setup. If results are encouraging, I'll post an RFC to
> ask for review / feedback from the NAPI experts here. What do you think?
>
I'm not sure which solution you mean. If you post your RFC, please create
a new thread (other title)
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-29 8:41 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708280828h408ce7damf04b31a2048d40c4@mail.gmail.com>
Hi Grant,
My zImage.elf has 1.1 MB and uImage 968 KB.
Could you tell me please how to hook up GDB to debug u-boot?
I have examined the file in u-boot which does the bootelf:
cat common/cmd_elf.c:
int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
:
:
:
:
addr = load_elf_image (addr);
printf ("## Starting application at 0x%08lx ...\n", addr);
/*
* QNX images require the data cache is disabled.
* Data cache is already flushed, so just turn it off.
*/
if (dcache_status ())
dcache_disable ();
/*
* pass address parameter as argv[0] (aka command name),
* and all remaining args
*/
rc = ((ulong (*)(int, char *[])) addr) (--argc, &argv[1]);
:
:
}
and I have determined that the system hangs just after the command:
rc = ((ulong (*)(int, char *[])) addr) (--argc, &argv[1]);
This command starts executing the linux image from the location:
0x00400000
On the console it is printed the following stuff:
loaded at: 00400000 004F3138
board data at: 004F1120 004F1138
relocated to: 004040B4 004040CC
zimage at: 00404E59 004F003D
avail ram: 004F4000 01FFFFFF
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...
It seems to be that it is the Linux kernel which does the uncompression
and it hangs. The question remain why?
Maybe it is not enough space in RAM or the address in RAM where the
uncompression is done is wrong.
When I load the u-boot to ram via jtag it is placed under the address:
0x800000 as follows:
section, .text: 0x00800000-0x0081513c
section, .resetvec: 0x0081513c-0x00815140
section, .rodata: 0x00815140-0x00817ce0
section, .reloc: 0x00817d00-0x00818674
section, .data: 0x00818674-0x00818b08
section, .data.rel: 0x00818b08-0x00818b34
section, .data.rel.local: 0x00818b34-0x00818f6c
section, .u_boot_cmd: 0x00818f6c-0x008191dc
section, .bss: 0x00819200-0x0081dd04
Than I load the zImage.elf via tftp to the memory location
0xf00000.
When I issue the command bootelf 0xf00000 the zImage.elf is placed in the
memory:
0x400000 as follows:
section, .text: 0x00400000-0x004036cc
section, .data: 0x00404000-0x004f7000
section, .bss: 0x004f7000-0x004f9138
After that uncompression of zImage.elf starts. I am just wandering which
memory location is involved for that?
My evaluation board has 32 MB of SDRAM address range:
(0x00000000-0x01ffffff) DDR_SDRAM_1 plb
Any Idea?
Best Regards
Mirek
On Tue, 28 Aug 2007, Grant Likely wrote:
> On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> > This buffer refers to the kernel which I boot straight from jtag but not
> > u-boot.
>
> /me remembers something....
>
> How big is your kernel image? Seems to me I've had problems with
> kernel images that were too large not being uncompressed properly.
> Can you hook up GDB and debug u-boot? Find out where it is hanging?
>
> g.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-29 8:31 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070829.012916.02298847.davem@davemloft.net>
On Wednesday 29 August 2007 10:29, David Miller wrote:
> From: Jan-Bernd Themann <ossthema@de.ibm.com>
> Date: Wed, 29 Aug 2007 09:10:15 +0200
>
> > In the end I want to reduce the CPU utilization. And one way
> > to do that is LRO which also works only well if there are more
> > then just a very few packets to aggregate. So at least our
> > driver (eHEA) would benefit from a mix of timer based polling
> > and plain NAPI (depending on load situations).
> >
> > If there is no need for a generic mechanism for this kind of
> > network adapters, then we can just leave this to each device
> > driver.
>
> No objections from me either way, if something works then
> fine.
>
> Let's come back to this once you have a tested sample implementation
> that does what you want, ok?
Sounds good
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: David Miller @ 2007-08-29 8:29 UTC (permalink / raw)
To: ossthema
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <46D51BD7.6040904@de.ibm.com>
From: Jan-Bernd Themann <ossthema@de.ibm.com>
Date: Wed, 29 Aug 2007 09:10:15 +0200
> In the end I want to reduce the CPU utilization. And one way
> to do that is LRO which also works only well if there are more
> then just a very few packets to aggregate. So at least our
> driver (eHEA) would benefit from a mix of timer based polling
> and plain NAPI (depending on load situations).
>
> If there is no need for a generic mechanism for this kind of
> network adapters, then we can just leave this to each device
> driver.
No objections from me either way, if something works then
fine.
Let's come back to this once you have a tested sample implementation
that does what you want, ok?
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: James Chapman @ 2007-08-29 8:15 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: <46D51BD7.6040904@de.ibm.com>
Jan-Bernd Themann wrote:
> Hi David
>
> David Miller schrieb:
>> Interrupt mitigation only works if it helps you avoid interrupts.
>> This scheme potentially makes more of them happen.
>>
>> The hrtimer is just another interrupt, a cpu locally triggered one,
>> but it has much of the same costs nonetheless.
>>
>> So if you set this timer, it triggers, and no packets arrive, you are
>> taking more interrupts and doing more work than if you had disabled
>> NAPI.
>>
>> In fact, for certain packet rates, your scheme would result in
>> twice as many interrupts than the current scheme
>>
> That depends how smart the driver switches between timer
> polling and plain NAPI (depending on load situation).
>> This is one of several reasons why hardware is the only truly proper
>> place for this kind of logic. Only the hardware can see the packet
>> arrive, and do the interrupt deferral without any cpu intervention
>> whatsoever.
>>
> What I'm trying to improve with this approach is interrupt
> mitigation for NICs where the hardware support for interrupt
> mitigation is limited. I'm not trying to improve this for NICs
> that work well with the means their HW provides. I'm aware of
> the fact that this scheme has it's tradeoffs and certainly
> can not be as good as a HW approach.
> So I'm grateful for any ideas that do have less tradeoffs and
> provide a mechanism to reduce interrupts without depending on
> HW support of the NIC.
>
> In the end I want to reduce the CPU utilization. And one way
> to do that is LRO which also works only well if there are more
> then just a very few packets to aggregate. So at least our
> driver (eHEA) would benefit from a mix of timer based polling
> and plain NAPI (depending on load situations).
Wouldn't you achieve the same result by enabling hardware interrupt
mitigation in eHEA in combination with NAPI? Presumably a 10G interface
has hardware mitigation features?
> If there is no need for a generic mechanism for this kind of
> network adapters, then we can just leave this to each device
> driver.
I've been looking at this from a different angle. My goal is to optimize
NAPI packet forwarding rates while minimizing packet latency. Using
hardware interrupt mitigation hurts latency so I'm investigating ways to
turn it off without risking NAPI poll on/off thrashing at certain packet
rates.
Jan-Bernd, I think I've found a solution to the issue that you
highlighted with my scheme yesterday and it doesn't involve generating
other interrupts using hrtimers etc. :) Initial results are very
encouraging in my setups. Would you be willing to test it with eHEA? I
don't have a 10G setup. If results are encouraging, I'll post an RFC to
ask for review / feedback from the NAPI experts here. What do you think?
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Wolfgang Denk @ 2007-08-29 7:49 UTC (permalink / raw)
To: Oliver Rutsch, Mustafa Cayir; +Cc: linuxppc-embedded
In-Reply-To: <46D50C0B.80402@sympatec.com>
In message <46D50C0B.80402@sympatec.com> you wrote:
>
> > i build Linux-2.6.22-gbcfc8d37 kernel lastest kernel from denx git for
> > the board (STK5200 with TQM5200-AB).
> > ELDK 4.1 version is used.
> >
> > make mrproper
> > export ARCH=powerpc
> > make tqm5200_defconfig
> > make uImage
> >
> > It hangs on after following line
> > Uncompressing Kernel Image ... OK
Probably it does not hang, but you just don't see any console output.
Eventually you just forgot to set the correct console device
(/dev/ttyPSC0) or console speed.
Also, you need a recent version of U-Boot (for example 99c2fdab or
later).
Try something like this:
=> tftp 200000 /tftpboot/tqm5200/uImage
=> tftp 400000 /tftpboot/tqm5200/tqm5200.dtb
=> setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk/ppc_6xx ip=192.168.160.4:192.168.1.1:::tqm5200:eth0:off console=ttyPSC0,115200
=> bootm 200000 - 400000
## Booting image at 00200000 ...
Image Name: Linux-2.6.22-gab27a987
Created: 2007-08-05 8:24:43 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1454249 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
Using tqm5200 machine description
Linux version 2.6.22-gab27a987 (wd@pollux.denx.de) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sun Aug 5 10:24:37 MEST 2007
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk/ppc_6xx ip=192.168.160.4:192.168.1.1:::tqm5200:eth0:off panic=1 console=ttyPSC0,115200
MPC52xx PIC is up and running!
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 61704k/65536k available (2872k kernel code, 3772k reserved, 132k data, 142k bss, 156k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
MPC52xx BestComm inited
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
...
etc.
> I encountered exactly the same problem. Using U-Boot 1.2 with Kernel
> Linux-2.6.22-gef92f1d7 and a TQM5200S-BD module on the STK52000. I tried
> to modify some kernel settings but it always stopped booting at the
> "Uncompressing Kernel Image ... OK" line.
Please note that the device tree we have at the moment is for the
TQM5200 only and does not include support for the TQM5200S.
But probably you just had the same problem - missing or bad console
device specification.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
That's their goal, remember, a goal that's really contrary to that of
the programmer or administrator. We just want to get our jobs done.
$Bill just wants to become $$Bill. These aren't even marginallly
congruent.
-- Tom Christiansen in <6jhtqk$qls$1@csnews.cs.colorado.edu>
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-29 7:10 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070828.132152.38706038.davem@davemloft.net>
Hi David
David Miller schrieb:
> Interrupt mitigation only works if it helps you avoid interrupts.
> This scheme potentially makes more of them happen.
>
> The hrtimer is just another interrupt, a cpu locally triggered one,
> but it has much of the same costs nonetheless.
>
> So if you set this timer, it triggers, and no packets arrive, you are
> taking more interrupts and doing more work than if you had disabled
> NAPI.
>
> In fact, for certain packet rates, your scheme would result in
> twice as many interrupts than the current scheme
>
That depends how smart the driver switches between timer
polling and plain NAPI (depending on load situation).
> This is one of several reasons why hardware is the only truly proper
> place for this kind of logic. Only the hardware can see the packet
> arrive, and do the interrupt deferral without any cpu intervention
> whatsoever.
>
What I'm trying to improve with this approach is interrupt
mitigation for NICs where the hardware support for interrupt
mitigation is limited. I'm not trying to improve this for NICs
that work well with the means their HW provides. I'm aware of
the fact that this scheme has it's tradeoffs and certainly
can not be as good as a HW approach.
So I'm grateful for any ideas that do have less tradeoffs and
provide a mechanism to reduce interrupts without depending on
HW support of the NIC.
In the end I want to reduce the CPU utilization. And one way
to do that is LRO which also works only well if there are more
then just a very few packets to aggregate. So at least our
driver (eHEA) would benefit from a mix of timer based polling
and plain NAPI (depending on load situations).
If there is no need for a generic mechanism for this kind of
network adapters, then we can just leave this to each device
driver.
^ permalink raw reply
* Sorry - please ignore Re: Bill F wants to chat
From: Bill F @ 2007-08-29 6:57 UTC (permalink / raw)
To: linuxppc-embedded
On 8/29/07, Bill F <list.mail.for.bill@gmail.com> wrote:
> -----------------------------------------------------------------------
>
> Bill F wants to stay in better touch using some of Google's coolest new
> products.
Sorry about that.
Please ignore my previous message. I'm switching over to use gmail so
that I can bypass our company's Exhange Server.
Bill
^ permalink raw reply
* Bill F wants to chat
From: Bill F @ 2007-08-29 6:52 UTC (permalink / raw)
To: linuxppc-embedded
-----------------------------------------------------------------------
Bill F wants to stay in better touch using some of Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-786dedfe41-9ba528e872-9319a317c93199c9
You'll need to click this link to be able to chat with Bill F.
To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Bill F, visit:
http://mail.google.com/mail/a-786dedfe41-9ba528e872-8d8d2d59f9
Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
that are relevant to the content of your messages
All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:
http://www.google.com/talk/
Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
client
Gmail and Google Talk are still in beta. We're working hard to add new features
and make improvements, so we might also ask for your comments and suggestions
periodically. We appreciate your help in making our products even better!
Thanks,
The Google Team
To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html
(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).
^ permalink raw reply
* Re: [PATCH 1/4] PowerPC 440EPx: Sequoia bootwrapper
From: David Gibson @ 2007-08-29 6:33 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070828165610.GA1552@ru.mvista.com>
On Tue, Aug 28, 2007 at 08:56:10PM +0400, Valentine Barshak wrote:
> Bootwrapper code for AMCC PPC440EPx Sequoia.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
[snip]
> +static void sequoia_fixups(void)
> +{
> + unsigned long sysclk = 33333333;
> +
> + ibm440ep_fixup_clocks(sysclk, 11059200);
> + ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> + ibm4xx_denali_fixup_memsize();
> + dt_fixup_mac_addresses(sequoia_mac0, sequoia_mac1);
> +}
> +
> +static void sequoia_init(void *mac0, void *mac1)
No need to separate this function out, just drop it into
platform_init(). Also no need for the seqouia_mac* variables - they
were in ebony to handle the cuboot vs. openbios variants. For
sequoia, you can just pull the values straight from the bd_t in
sequoia_fixups()
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: David Gibson @ 2007-08-29 6:13 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
for powerpc (v3)
Reply-To:
This patch replaces the binding for flash chips in
booting-without-of.txt with an clarified and improved version. It
also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
Finally it revises the Ebony device tree source to use the new binding
as an example.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Third try at this...
Index: working-2.6/Documentation/powerpc/booting-without-of.txt
===================================================================
--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-08-29 15:56:19.000000000 +1000
+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-08-29 16:10:32.000000000 +1000
@@ -50,7 +50,7 @@
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
VII - Specifying interrupt information for devices
@@ -1757,45 +1757,61 @@
};
};
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
- Required properties:
-
- - device_type : has to be "rom"
- - compatible : Should specify what this flash device is compatible with.
- Currently, this is most likely to be "direct-mapped" (which
- corresponds to the MTD physmap mapping driver).
- - reg : Offset and length of the register set (or memory mapping) for
- the device.
- - bank-width : Width of the flash data bus in bytes. Required
- for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
-
- Recommended properties :
-
- - partitions : Several pairs of 32-bit values where the first value is
- partition's offset from the start of the device and the second one is
- partition size in bytes with LSB used to signify a read only
- partition (so, the partition size should always be an even number).
- - partition-names : The list of concatenated zero terminated strings
- representing the partition names.
- - probe-type : The type of probe which should be done for the chip
- (JEDEC vs CFI actually). Valid ONLY for NOR flashes.
+ - compatible : should contain the specific model of flash chip(s)
+ used, if known, followed by either "cfi-flash" or "jedec-flash"
+ - reg : Address range of the flash chip
+ - bank-width : Width (in bytes) of the flash bank. Equal to the
+ device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single flash chip. If
+ omitted, assumed to be equal to 'bank-width'.
+ - #address-cells, #size-cells : Must be present if the flash has
+ sub-nodes representing partitions (see below). In this case
+ both #address-cells and #size-cells must be equal to 1.
+
+ For JEDEC compatible devices, the following additional properties
+ are defined:
+
+ - vendor-id : Contains the flash chip's vendor id (1 byte).
+ - device-id : Contains the flash chip's device id (1 byte).
+
+ In addition to the information on the flash bank itself, the
+ device tree may optionally contain additional information
+ describing partitions of the flash address space. This can be
+ used on platforms which have strong conventions about which
+ portions of the flash are used for what purposes, but which don't
+ use an on-flash partition table such as RedBoot.
+
+ Each partition is represented as a sub-node of the flash device.
+ Each node's name represents the name of the corresponding
+ partition of the flash device.
+
+ Flash partitions
+ - reg : The partition's offset and size within the flash bank.
+ - read-only : (optional) This parameter, if present, is a hint to
+ Linux that this flash partition should only be mounted
+ read-only. This is usually used for flash partitions
+ containing early-boot firmware images or data which should not
+ be clobbered.
- Example:
+ Example:
- flash@ff000000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "CFI";
- reg = <ff000000 01000000>;
- bank-width = <4>;
- partitions = <00000000 00f80000
- 00f80000 00080001>;
- partition-names = "fs\0firmware";
- };
+ flash@ff000000 {
+ compatible = "amd,am29lv128ml", "cfi-flash";
+ reg = <ff000000 01000000>;
+ bank-width = <4>;
+ fs@0 {
+ reg = <0 f80000>;
+ };
+ firmware@f80000 {
+ reg = <f80000 80000>;
+ read-only;
+ };
+ };
k) Global Utilities Block
Index: working-2.6/drivers/mtd/maps/physmap_of.c
===================================================================
--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-08-29 15:56:18.000000000 +1000
+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-08-29 15:56:19.000000000 +1000
@@ -4,6 +4,9 @@
* Copyright (C) 2006 MontaVista Software Inc.
* Author: Vitaly Wool <vwool@ru.mvista.com>
*
+ * Revised to handle newer style flash binding by:
+ * Copyright (C) 2007 David Gibson, IBM Corporation.
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -30,56 +33,132 @@
struct map_info map;
struct resource *res;
#ifdef CONFIG_MTD_PARTITIONS
- int nr_parts;
struct mtd_partition *parts;
#endif
};
-static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
-#endif
-
#ifdef CONFIG_MTD_PARTITIONS
-static int parse_flash_partitions(struct device_node *node,
- struct mtd_partition **parts)
+static int parse_obsolete_partitions(struct of_device *dev,
+ struct physmap_flash_info *info,
+ struct device_node *dp)
{
- int i, plen, retval = -ENOMEM;
- const u32 *part;
- const char *name;
-
- part = of_get_property(node, "partitions", &plen);
- if (part == NULL)
- goto err;
-
- retval = plen / (2 * sizeof(u32));
- *parts = kzalloc(retval * sizeof(struct mtd_partition), GFP_KERNEL);
- if (*parts == NULL) {
+ int i, plen, nr_parts;
+ const struct {
+ u32 offset, len;
+ } *part;
+ const char *names;
+
+ part = of_get_property(dp, "partitions", &plen);
+ if (!part)
+ return -ENOENT;
+
+ dev_warn(&dev->dev, "Device tree uses obsolete partition map binding\n");
+
+ nr_parts = plen / sizeof(part[0]);
+
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition), GFP_KERNEL);
+ if (!info->parts) {
printk(KERN_ERR "Can't allocate the flash partition data!\n");
- goto err;
+ return -ENOMEM;
}
- name = of_get_property(node, "partition-names", &plen);
+ names = of_get_property(dp, "partition-names", &plen);
- for (i = 0; i < retval; i++) {
- (*parts)[i].offset = *part++;
- (*parts)[i].size = *part & ~1;
- if (*part++ & 1) /* bit 0 set signifies read only partition */
- (*parts)[i].mask_flags = MTD_WRITEABLE;
+ for (i = 0; i < nr_parts; i++) {
+ info->parts[i].offset = part->offset;
+ info->parts[i].size = part->len & ~1;
+ if (part->len & 1) /* bit 0 set signifies read only partition */
+ info->parts[i].mask_flags = MTD_WRITEABLE;
- if (name != NULL && plen > 0) {
- int len = strlen(name) + 1;
+ if (names && (plen > 0)) {
+ int len = strlen(names) + 1;
- (*parts)[i].name = (char *)name;
+ info->parts[i].name = (char *)names;
plen -= len;
- name += len;
- } else
- (*parts)[i].name = "unnamed";
+ names += len;
+ } else {
+ info->parts[i].name = "unnamed";
+ }
+
+ part++;
}
-err:
- return retval;
+
+ return nr_parts;
}
-#endif
+
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct of_device *dev)
+{
+ static const char *part_probe_types[]
+ = { "cmdlinepart", "RedBoot", NULL };
+ struct device_node *dp = dev->node, *pp;
+ int nr_parts, i, err;
+
+ /* First look for RedBoot table or partitions on the command
+ * line, these take precedence over device tree information */
+ nr_parts = parse_mtd_partitions(info->mtd, part_probe_types,
+ &info->parts, 0);
+ if (nr_parts > 0) {
+ add_mtd_partitions(info->mtd, info->parts, err);
+ return 0;
+ }
+
+ /* First count the subnodes */
+ nr_parts = 0;
+ for (pp = dp->child; pp; pp = pp->sibling)
+ nr_parts++;
+
+ if (nr_parts) {
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition),
+ GFP_KERNEL);
+ if (!info->parts) {
+ printk(KERN_ERR "Can't allocate the flash partition data!\n");
+ return -ENOMEM;
+ }
+
+ for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
+ const u32 *reg;
+ int len;
+
+ reg = of_get_property(pp, "reg", &len);
+ if (!reg || (len != 2*sizeof(u32))) {
+ dev_err(&dev->dev, "Invalid 'reg' on %s\n",
+ dp->full_name);
+ kfree(info->parts);
+ info->parts = NULL;
+ return -EINVAL;
+ }
+ info->parts[i].offset = reg[0];
+ info->parts[i].size = reg[1];
+
+ info->parts[i].name =
+ (char *)of_get_property(pp, "name", &len);
+
+ if (of_get_property(pp, "read-only", &len))
+ info->parts[i].mask_flags = MTD_WRITEABLE;
+ }
+ } else {
+ nr_parts = parse_obsolete_partitions(dev, info, dp);
+ }
+
+ if (nr_parts < 0)
+ return nr_parts;
+
+ if (nr_parts > 0)
+ add_mtd_partitions(info->mtd, info->parts, nr_parts);
+ else
+ add_mtd_device(info->mtd);
+
+ return 0;
+}
+#else /* MTD_PARTITIONS */
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct device_node *dev)
+{
+ add_mtd_device(info->mtd);
+ return 0;
+}
+#endif /* MTD_PARTITIONS */
static int of_physmap_remove(struct of_device *dev)
{
@@ -92,7 +171,7 @@
if (info->mtd != NULL) {
#ifdef CONFIG_MTD_PARTITIONS
- if (info->nr_parts) {
+ if (info->parts) {
del_mtd_partitions(info->mtd);
kfree(info->parts);
} else {
@@ -115,16 +194,50 @@
return 0;
}
+/* Helper function to handle probing of the obsolete "direct-mapped"
+ * compatible binding, which has an extra "probe-type" property
+ * describing the type of flash probe necessary. */
+static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
+ struct map_info *map)
+{
+ struct device_node *dp = dev->node;
+ const char *of_probe;
+ struct mtd_info *mtd;
+ static const char *rom_probe_types[]
+ = { "cfi_probe", "jedec_probe", "map_rom"};
+ int i;
+
+ of_probe = of_get_property(dp, "probe-type", NULL);
+ if (!of_probe) {
+ for (i = 0; i < ARRAY_SIZE(rom_probe_types); i++) {
+ mtd = do_map_probe(rom_probe_types[i], map);
+ if (mtd)
+ return mtd;
+ }
+ return NULL;
+ } else if (strcmp(of_probe, "CFI") == 0) {
+ return do_map_probe("cfi_probe", map);
+ } else if (strcmp(of_probe, "JEDEC") == 0) {
+ return do_map_probe("jedec_probe", map);
+ } else {
+ if (strcmp(of_probe, "ROM") != 0)
+ dev_dbg(&dev->dev, "obsolete_probe: don't know probe type "
+ "'%s', mapping as rom\n", of_probe);
+ return do_map_probe("mtd_rom", map);
+ }
+}
+
static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
{
struct device_node *dp = dev->node;
struct resource res;
struct physmap_flash_info *info;
- const char **probe_type;
- const char *of_probe;
+ const char *probe_type = (const char *)match->data;
const u32 *width;
int err;
+ dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
+ "flash binding\n");
if (of_address_to_resource(dp, 0, &res)) {
dev_err(&dev->dev, "Can't get the flash mapping!\n");
@@ -174,21 +287,11 @@
simple_map_init(&info->map);
- of_probe = of_get_property(dp, "probe-type", NULL);
- if (of_probe == NULL) {
- probe_type = rom_probe_types;
- for (; info->mtd == NULL && *probe_type != NULL; probe_type++)
- info->mtd = do_map_probe(*probe_type, &info->map);
- } else if (!strcmp(of_probe, "CFI"))
- info->mtd = do_map_probe("cfi_probe", &info->map);
- else if (!strcmp(of_probe, "JEDEC"))
- info->mtd = do_map_probe("jedec_probe", &info->map);
- else {
- if (strcmp(of_probe, "ROM"))
- dev_dbg(&dev->dev, "map_probe: don't know probe type "
- "'%s', mapping as rom\n", of_probe);
- info->mtd = do_map_probe("mtd_rom", &info->map);
- }
+ if (probe_type)
+ info->mtd = do_map_probe(probe_type, &info->map);
+ else
+ info->mtd = obsolete_probe(dev, &info->map);
+
if (info->mtd == NULL) {
dev_err(&dev->dev, "map_probe failed\n");
err = -ENXIO;
@@ -196,19 +299,7 @@
}
info->mtd->owner = THIS_MODULE;
-#ifdef CONFIG_MTD_PARTITIONS
- err = parse_mtd_partitions(info->mtd, part_probe_types, &info->parts, 0);
- if (err > 0) {
- add_mtd_partitions(info->mtd, info->parts, err);
- } else if ((err = parse_flash_partitions(dp, &info->parts)) > 0) {
- dev_info(&dev->dev, "Using OF partition information\n");
- add_mtd_partitions(info->mtd, info->parts, err);
- info->nr_parts = err;
- } else
-#endif
-
- add_mtd_device(info->mtd);
- return 0;
+ return process_partitions(info, dev);
err_out:
of_physmap_remove(dev);
@@ -221,6 +312,14 @@
static struct of_device_id of_physmap_match[] = {
{
+ .compatible = "cfi-flash",
+ .data = (void *)"cfi_probe",
+ },
+ {
+ .compatible = "jedec-flash",
+ .data = (void *)"jedec_probe",
+ },
+ {
.type = "rom",
.compatible = "direct-mapped"
},
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-08-29 15:56:18.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-08-29 15:56:19.000000000 +1000
@@ -142,13 +142,15 @@
interrupt-parent = <&UIC1>;
small-flash@0,80000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 80000>;
- partition-names = "OpenBIOS";
reg = <0 80000 80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ OpenBIOS@0 {
+ reg = <0 80000>;
+ read-only;
+ };
};
ds1743@1,0 {
@@ -158,14 +160,17 @@
};
large-flash@2,0 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 380000
- 380000 80000>;
- partition-names = "fs", "firmware";
reg = <2 0 400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fs@0 {
+ reg = <0 380000>;
+ };
+ firmware@380000 {
+ reg = <380000 80000>;
+ };
};
ir@3,0 {
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-29 6:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F070B9283@itri.bte.mam.gov.tr>
Hi Mustafa,
> Hi,
>
> i build Linux-2.6.22-gbcfc8d37 kernel lastest kernel from denx git for
> the board (STK5200 with TQM5200-AB).
> ELDK 4.1 version is used.
>
> make mrproper
> export ARCH=powerpc
> make tqm5200_defconfig
> make uImage
>
> It hangs on after following line
> Uncompressing Kernel Image ... OK
>
I encountered exactly the same problem. Using U-Boot 1.2 with Kernel
Linux-2.6.22-gef92f1d7 and a TQM5200S-BD module on the STK52000. I tried
to modify some kernel settings but it always stopped booting at the
"Uncompressing Kernel Image ... OK" line.
Bye,
--
Dipl. Ing. Oliver Rutsch
^ 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