Re: Device Tree setup for 8272-based board
Hi Scott,
On Wed, Jan 21, 2009 at 3:41 AM, Scott Wood wrote:
> On Tue, Jan 20, 2009 at 06:23:08PM +1100, Daniel Ng wrote:
>> PID hash table entries: 128 (order: 7, 512 bytes)
>> time_init: decrementer frequency = 16.50 MHz
>> time_init: processor frequency = 330.00 MHz
>> clocksource: timebase mult[f26c9b2] shift[22] registered
>> clockevent: decrementer mult[439] shift[16] cpu[0]
>> Console: colour dummy ü
>>
>> -at this point the board just reboots.
>
> Looks like something goes wrong when the real serial driver kicks in.
I've managed to enable more debug and see the following boot sequence:
cpm_uart_init_port()
OF: ** translation for device /s...@f000/c...@119c0/ser...@11a00 **
OF: bus is default (na=1, ns=1) on /s...@f000/c...@119c0
OF: translating address: 00011a00
OF: parent bus is default (na=1, ns=1) on /s...@f000
OF: no ranges, 1:1 translation
OF: parent translation for:
OF: with offset: 11a00
OF: one level translation: 00011a00
OF: parent bus is default (na=1, ns=1) on /
OF: walking ranges...
OF: default map, cp=0, s=53000, da=11a00
OF: parent translation for: f000
OF: with offset: 11a00
OF: one level translation: f0011a00
OF: reached root node
OF: ** translation for device /s...@f000/c...@119c0/ser...@11a00 **
OF: bus is default (na=1, ns=1) on /s...@f000/c...@119c0
OF: translating address: 8000
OF: parent bus is default (na=1, ns=1) on /s...@f000
OF: no ranges, 1:1 translation
OF: parent translation for:
OF: with offset: 8000
OF: one level translation: 8000
OF: parent bus is default (na=1, ns=1) on /
OF: walking ranges...
OF: default map, cp=0, s=53000, da=8000
OF: parent translation for: f000
OF: with offset: 8000
OF: one level translation: f0008000
OF: reached root node
of_irq_map_one: dev=/s...@f000/c...@119c0/ser...@11a00, index=0
intsize=2 intlen=2
of_irq_map_raw:
par=/s...@f000/interrupt-control...@10c00,intspec=[0x0028 0x
0008...],ointsize=2
of_irq_map_raw: ipar=/s...@f000/interrupt-control...@10c00, size=2
-> addrsize=1
-> got it !
irq: irq_create_mapping(0xc02d1320, 0x28)
irq: -> using host @c02d1320
irq: -> obtained virq 40
cpm2_pic_host_map(40, 0x28)
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
cpm_uart_request_port()
CPM uart[þ
I think the of_get_gpio() error messages are a result of the following
code in cpm_uart_init_port()-
for (i = 0; i < NUM_GPIOS; i++)
pinfo->gpios[i] = of_get_gpio(np, i);
-why is this code here? Is it for processing modem control lines? I
know our board doesn't make use of the modem control lines for
ttyCPM0. Therefore, have I misconfigured something in the Device Tree?
Here's the relevant part of the Device Tree-
c...@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <0x119c0 0x30>;
ranges;
mu...@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x1>;
d...@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x2000 0x9800 0x800>;
};
};
b...@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <0x119f0 0x10 0x115f0 0x10>;
};
ser...@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a00 0x20 0x8000 0x100>;
interrupts = <40 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x80>;
};
};
PIC: interrupt-control...@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x10c00 0x80>;
compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
};
Would you please explain what the following lines mean, so I can use
some more appropriate values for my particular board?-
1) In the ser...@11a00 node-
a) reg = <0x11a00 0x20 0x8000 0x100>;
b) interrupts = <40 8>;
c) fsl,cpm-brg = <1>;
d) fsl,cpm-command = <0x80>;
2) In the b...@119f0 node-
reg = <0x119f0 0x10 0x115f0 0x10>;
3) In the PIC: interrupt-control...@10c00 node-
reg = <0x10c00 0x80>;
I have read the relevant documentation under Documentation/powerpc and
Documentation/powerpc/dts-bindings, but these do not seem to go into
enough detail eg.
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt says the
following about the reg property-
- reg : There may be an arbitrary number of reg resources; BRG
numbers are assigned to these in order.
-> does this mean that each number represents a BRG register? So there
can be a maximum of 1+8=9 reg values, since there are 8 BRG registers?
As for Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt, there
is no e
Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Got a couple of these on a PowerBook running 2.6.29-rc2 either during suspend or resume -- it's hard to tell. (The suspend message is timestamped in syslog with the time I resumed, so I guess it was buffered along with the subsequent "Badness" messages.) Badness at kernel/time/timekeeping.c:98 NIP: c0053990 LR: c0053b10 CTR: c0348840 REGS: ee4fdba0 TRAP: 0700 Not tainted (2.6.29-rc2-1-g351549b) MSR: 02023032 CR: 2284 XER: 2000 TASK = ef2f7820[2700] 'pmud' THREAD: ee4fc000 GPR00: 0001 ee4fdc50 ef2f7820 ee4fdc88 0005 ef84a7fc GPR08: 0004 a9283f00 0001 22444224 1001e68c 0040 GPR16: 0001 0010 22444224 0001 c067c05c 0005 GPR24: c067c16d 0006 c067c16c 0005 ee4fdc88 ee4fdcb8 ef357400 NIP [c0053990] getnstimeofday+0x24/0x188 LR [c0053b10] do_gettimeofday+0x1c/0x58 Call Trace: [ee4fdc80] [c0053b10] do_gettimeofday+0x1c/0x58 [ee4fdcb0] [c0348868] evdev_event+0x28/0x158 [ee4fdce0] [c0340ce4] input_pass_event+0xac/0xb0 [ee4fdd00] [c0343a44] input_event+0x80/0x98 [ee4fdd20] [c02f6d24] via_pmu_event+0x88/0x8c [ee4fdd30] [c02f4f60] via_pmu_interrupt+0x6e0/0xb2c [ee4fdd90] [c02f5664] pmu_wait_complete+0x50/0x84 [ee4fddb0] [c02f6764] powerbook_sleep+0x9f0/0xb24 [ee4fde40] [c00607f8] suspend_devices_and_enter+0x10c/0x180 [ee4fde60] [c0060a1c] enter_state+0x11c/0x160 [ee4fde80] [c02f4404] pmu_ioctl+0x15c/0x24c [ee4fde90] [c00bab04] vfs_ioctl+0x8c/0x90 [ee4fdea0] [c00babb8] do_vfs_ioctl+0x8c/0x70c [ee4fdf10] [c00bb2d4] sys_ioctl+0x9c/0xa4 [ee4fdf40] [c0012eb8] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff59878 LR = 0xff597dc Instruction dump: 7f9c0040 40bdff90 4b48 9421ffd0 7c0802a6 3d20c05e 90010034 bf210014 7c7c1b78 816970a4 312b 7c095910 <0f00> 3d40c05f 3d20c05f 3d60c05f [ cut here ] Badness at kernel/time/timekeeping.c:98 NIP: c0053990 LR: c0053b10 CTR: c0348840 REGS: ee4fdba0 TRAP: 0700 Tainted: GW (2.6.29-rc2-1-g351549b) MSR: 02023032 CR: 4284 XER: 2000 TASK = ef2f7820[2700] 'pmud' THREAD: ee4fc000 GPR00: 0001 ee4fdc50 ef2f7820 ee4fdc88 GPR08: c062f520 efae6240 0001 4284 1001e68c 0040 GPR16: 0001 0010 22444224 0001 c067c05c 0005 GPR24: c067c16d 0006 c067c16c ee4fdc88 ee4fdcb8 ef357400 NIP [c0053990] getnstimeofday+0x24/0x188 LR [c0053b10] do_gettimeofday+0x1c/0x58 Call Trace: [ee4fdc50] [ee4fdd00] 0xee4fdd00 (unreliable) [ee4fdc80] [c0053b10] do_gettimeofday+0x1c/0x58 [ee4fdcb0] [c0348868] evdev_event+0x28/0x158 [ee4fdce0] [c0340ce4] input_pass_event+0xac/0xb0 [ee4fdd00] [c0343a44] input_event+0x80/0x98 [ee4fdd20] [c02f6cf0] via_pmu_event+0x54/0x8c [ee4fdd30] [c02f4f60] via_pmu_interrupt+0x6e0/0xb2c [ee4fdd90] [c02f5664] pmu_wait_complete+0x50/0x84 [ee4fddb0] [c02f6764] powerbook_sleep+0x9f0/0xb24 [ee4fde40] [c00607f8] suspend_devices_and_enter+0x10c/0x180 [ee4fde60] [c0060a1c] enter_state+0x11c/0x160 [ee4fde80] [c02f4404] pmu_ioctl+0x15c/0x24c [ee4fde90] [c00bab04] vfs_ioctl+0x8c/0x90 [ee4fdea0] [c00babb8] do_vfs_ioctl+0x8c/0x70c [ee4fdf10] [c00bb2d4] sys_ioctl+0x9c/0xa4 [ee4fdf40] [c0012eb8] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff59878 LR = 0xff597dc Instruction dump: 7f9c0040 40bdff90 4b48 9421ffd0 7c0802a6 3d20c05e 90010034 bf210014 7c7c1b78 816970a4 312b 7c095910 <0f00> 3d40c05f 3d20c05f 3d60c05f -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: more printing warning fixes for the l64 to ll64 conversion
On Wed, Jan 21, 2009 at 11:16:51AM +1100, Stephen Rothwell wrote: > These are all powerpc specific drivers. > > Signed-off-by: Stephen Rothwell pasemi_nand.c pieces: Acked-by: Olof Johansson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Defconfig support
On Tue, Jan 20, 2009 at 08:09:36PM -0500, Sean MacLennan wrote: >On Tue, 20 Jan 2009 06:29:30 -0500 >"Josh Boyer" wrote: > >> Since I'll be doing defconfig updates today, just tell me which >> options you need set or disabled. > >Let's try this patch and see how it goes. If it doesn't apply easily, I >will just give you a list. > >Note a few of the options will be disabled with the make oldconfig and >that is fine. > >The ones I know will be disabled are the PIKA_SD driver and the >PIKA_LEDS driver. Also I don't think it will let you disabled >SCSI_WAIT_SCAN :( You have to patch a Kconfig for that. OK, I'll work these in tonight and then send them Ben's way. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Defconfig support
On Tue, 20 Jan 2009 06:29:30 -0500 "Josh Boyer" wrote: > Since I'll be doing defconfig updates today, just tell me which > options you need set or disabled. Let's try this patch and see how it goes. If it doesn't apply easily, I will just give you a list. Note a few of the options will be disabled with the make oldconfig and that is fine. The ones I know will be disabled are the PIKA_SD driver and the PIKA_LEDS driver. Also I don't think it will let you disabled SCSI_WAIT_SCAN :( You have to patch a Kconfig for that. Cheers, Sean --- /tmp/orig-config2009-01-20 19:49:57.0 -0500 +++ arch/powerpc/configs/44x/warp_defconfig 2009-01-20 19:59:23.0 -0500 @@ -390,7 +390,7 @@ CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_TESTS is not set # CONFIG_MTD_REDBOOT_PARTS is not set -# CONFIG_MTD_CMDLINE_PARTS is not set +CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_OF_PARTS=y # CONFIG_MTD_AR7_PARTS is not set @@ -405,7 +405,7 @@ # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set -CONFIG_MTD_OOPS=m +# CONFIG_MTD_OOPS is not set # # RAM/ROM/Flash chip drivers @@ -459,7 +459,7 @@ CONFIG_MTD_NAND_ECC_SMC=y # CONFIG_MTD_NAND_MUSEUM_IDS is not set CONFIG_MTD_NAND_IDS=y -# CONFIG_MTD_NAND_NDFC is not set +CONFIG_MTD_NAND_NDFC=y # CONFIG_MTD_NAND_DISKONCHIP is not set # CONFIG_MTD_NAND_NANDSIM is not set # CONFIG_MTD_NAND_PLATFORM is not set @@ -529,7 +529,7 @@ # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set -CONFIG_SCSI_WAIT_SCAN=m +# CONFIG_SCSI_WAIT_SCAN is not set # # SCSI Transports @@ -663,7 +663,7 @@ # # I2C system bus drivers (mostly embedded / system-on-chip) # -# CONFIG_I2C_IBM_IIC is not set +CONFIG_I2C_IBM_IIC=y # CONFIG_I2C_MPC is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set @@ -685,8 +685,8 @@ # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set -# CONFIG_AT24 is not set -CONFIG_SENSORS_EEPROM=y +CONFIG_AT24=y +# CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCA9539 is not set @@ -704,7 +704,7 @@ # CONFIG_POWER_SUPPLY is not set CONFIG_HWMON=y # CONFIG_HWMON_VID is not set -# CONFIG_SENSORS_AD7414 is not set +CONFIG_SENSORS_AD7414=y # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set @@ -757,8 +757,21 @@ # CONFIG_SENSORS_W83627EHF is not set # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL=y -# CONFIG_THERMAL_HWMON is not set -# CONFIG_WATCHDOG is not set +CONFIG_THERMAL_HWMON=y +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +# CONFIG_SOFT_WATCHDOG is not set +CONFIG_PIKA_WDT=y +# CONFIG_BOOKE_WDT is not set + +# +# USB-based Watchdog Cards +# +# CONFIG_USBPCWATCHDOG is not set CONFIG_SSB_POSSIBLE=y # @@ -916,14 +929,14 @@ # # OTG and related infrastructure # -CONFIG_MMC=m +CONFIG_MMC=y # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # # MMC/SD/SDIO Card Drivers # -CONFIG_MMC_BLOCK=m +CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set # CONFIG_MMC_TEST is not set @@ -933,9 +946,21 @@ # # CONFIG_MMC_SDHCI is not set # CONFIG_MMC_WBSD is not set -# CONFIG_MMC_PIKASD is not set +CONFIG_MMC_PIKASD=y # CONFIG_MEMSTICK is not set -# CONFIG_NEW_LEDS is not set +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y + +# +# LED drivers +# +CONFIG_LEDS_WARP=y +# CONFIG_LEDS_PCA955X is not set + +# +# LED Triggers +# +# CONFIG_LEDS_TRIGGERS is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_EDAC is not set # CONFIG_RTC_CLASS is not set @@ -949,8 +974,11 @@ CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set -# CONFIG_EXT3_FS is not set +CONFIG_EXT3_FS=y +# CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4_FS is not set +CONFIG_JBD=y +# CONFIG_JBD_DEBUG is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set @@ -990,7 +1018,8 @@ CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y -# CONFIG_TMPFS is not set +CONFIG_TMPFS=y +# CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set CONFIG_MISC_FILESYSTEMS=y @@ -1178,7 +1207,7 @@ # CONFIG_FTR_FIXUP_SELFTEST is not set # CONFIG_MSI_BITMAP_SELFTEST is not set # CONFIG_XMON is not set -# CONFIG_IRQSTACKS is not set +CONFIG_IRQSTACKS=y # CONFIG_VIRQ_DEBUG is not set CONFIG_BDI_SWITCH=y # CONFIG_PPC_EARLY_DEBUG is not set ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] Possible fix for kexec-tools dynamic range allocation
On Wed, 2009-01-21 at 08:30 +1100, Simon Horman wrote: > On Wed, Jan 07, 2009 at 05:01:26PM +1100, Michael Ellerman wrote: > > Hi all, > > > > The patch to dynamically allocate memory regions for ppc64 kexec-tools, > > ie. "ppc64: kexec memory ranges dynamic allocation" (d182ce5), has never > > worked AFAICT. > > > > Chandru reported it as broken when it was posted: > > http://lists.infradead.org/pipermail/kexec/2008-October/002751.html > > > > Still, it's in now, and I'm trying to work out what's going wrong. > > > > The symptom is as reported by Chandru, we end up not being able to > > allocate any memory (in locate_hole()). This is caused by the list of > > memory_ranges being empty. > > > > The memory_ranges are empty because they have been realloc'ed (by the > > dynamic alloc code), and the generic code is still looking at the old > > version. > > > > What I'm not clear on is why the ppc64 code is even calling > > setup_memory_ranges() a second time (in elf_ppc64_load()). It's already > > been called by get_memory_ranges() from my_load(). Or is there another > > route into elf_ppc64_load() that I'm not seeing? > > > > And in fact if I just remove that call, then everything is peachy. > > > > The following patch makes it work for me at least. > > Hi Michael, > > I must confess that I don't have a complete understanding of this problem. > Does Bernhard's recent patch (sorry that I applied it even though > it came in after your patch) help this problem? Hi Horms, Well to be honest neither do I, I was hoping someone who'd written or helped write the original code would comment. Bernhard's patch will help, but I think mine is a better solution. > commit 95c74405638c786bc76fbca5e4e8427dfe26e907 > Author: Bernhard Walle > Date: Fri Jan 16 19:11:34 2009 +0100 > Subject: Fix memory corruption when using realloc_memory_ranges() > Because realloc_memory_ranges() makes the old memory invalid, and we return > a pointer to memory_range in get_memory_ranges(), we need to copy the contents > in get_memory_ranges(). > > Some code that calls realloc_memory_ranges() may be triggered by > get_base_ranges() which is called after get_memory_ranges(). > > Yes, the memory needs to be deleted somewhere, but I don't know currently > where it's the best, and since it's not in a loop and memory is deleted > anyway after program termination I don't want to introduce unneccessary > complexity. The problem is that get_base_ranges() gets called from > architecture independent code and that allocation is PPC64-specific here. I don't see where get_base_ranges() is called other than from PPC64 code, so I'm confused about this comment. What I see happening is: * get_memory_ranges() is called early in kexec.c and saves a pointer to the memory ranges in "info". * Any subsequent call which causes the memory ranges to be realloc'ed will screw that up, because now info will point at free'd memory. * Later on in elf_ppc64_load() we call setup_memory_ranges() (again). * That may cause the ranges to be realloc'ed, which would be bad. * But the second call to setup_memory_ranges() is useless, because it doesn't update info, and info is what we keep using for allocations. * So if setup_memory_ranges() found new ranges, they would never be used, even apart from the corruption issue. So we may as well not call it. * If there are /other/ code paths where we can realloc memory ranges then maybe we /also/ need Bernhard's patch. But that was only a 10 minute analysis, so maybe I'm wrong ;) cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: more printing warning fixes for the l64 to ll64 conversion
On Wednesday 21 January 2009, Stephen Rothwell wrote: > drivers/edac/cell_edac.c | 8 > drivers/mtd/nand/fsl_elbc_nand.c | 6 +++--- > drivers/mtd/nand/pasemi_nand.c | 4 ++-- > 3 files changed, 9 insertions(+), 9 deletions(-) > > If noone minds (seeing as how simple this patch is) we could just merge > it via the powerpc tree. Fine with me (cell_edac bits in particular). Acked-by: Arnd Bergmann ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/13] powerpc/ps3: printing fixups for l64 to ll64 convserion: drivers/net
Hi Ben, On Wed, 14 Jan 2009 14:54:34 -0800 Geoff Levand wrote: > > Stephen Rothwell wrote: > > Signed-off-by: Stephen Rothwell > > --- > > drivers/net/ps3_gelic_wireless.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > Acked-by: Geoff Levand >From Dave Miller: Please forward this ACK to Ben :-) Acked-by: David S. Miller -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgppSDWm8ODxF.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: more printing warning fixes for the l64 to ll64 conversion
These are all powerpc specific drivers.
Signed-off-by: Stephen Rothwell
---
drivers/edac/cell_edac.c |8
drivers/mtd/nand/fsl_elbc_nand.c |6 +++---
drivers/mtd/nand/pasemi_nand.c |4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
If noone minds (seeing as how simple this patch is) we could just merge
it via the powerpc tree.
diff --git a/drivers/edac/cell_edac.c b/drivers/edac/cell_edac.c
index cd2e3b8..24f3ca8 100644
--- a/drivers/edac/cell_edac.c
+++ b/drivers/edac/cell_edac.c
@@ -36,7 +36,7 @@ static void cell_edac_count_ce(struct mem_ctl_info *mci, int
chan, u64 ar)
struct csrow_info *csrow = &mci->csrows[0];
unsigned long address, pfn, offset, syndrome;
- dev_dbg(mci->dev, "ECC CE err on node %d, channel %d, ar = 0x%016lx\n",
+ dev_dbg(mci->dev, "ECC CE err on node %d, channel %d, ar = 0x%016llx\n",
priv->node, chan, ar);
/* Address decoding is likely a bit bogus, to dbl check */
@@ -58,7 +58,7 @@ static void cell_edac_count_ue(struct mem_ctl_info *mci, int
chan, u64 ar)
struct csrow_info *csrow = &mci->csrows[0];
unsigned long address, pfn, offset;
- dev_dbg(mci->dev, "ECC UE err on node %d, channel %d, ar = 0x%016lx\n",
+ dev_dbg(mci->dev, "ECC UE err on node %d, channel %d, ar = 0x%016llx\n",
priv->node, chan, ar);
/* Address decoding is likely a bit bogus, to dbl check */
@@ -169,7 +169,7 @@ static int __devinit cell_edac_probe(struct platform_device
*pdev)
/* Get channel population */
reg = in_be64(®s->mic_mnt_cfg);
- dev_dbg(&pdev->dev, "MIC_MNT_CFG = 0x%016lx\n", reg);
+ dev_dbg(&pdev->dev, "MIC_MNT_CFG = 0x%016llx\n", reg);
chanmask = 0;
if (reg & CBE_MIC_MNT_CFG_CHAN_0_POP)
chanmask |= 0x1;
@@ -180,7 +180,7 @@ static int __devinit cell_edac_probe(struct platform_device
*pdev)
"Yuck ! No channel populated ? Aborting !\n");
return -ENODEV;
}
- dev_dbg(&pdev->dev, "Initial FIR = 0x%016lx\n",
+ dev_dbg(&pdev->dev, "Initial FIR = 0x%016llx\n",
in_be64(®s->mic_fir));
/* Allocate & init EDAC MC data structure */
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 65929db..0f22e1a 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -676,7 +676,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
dev_dbg(ctrl->dev, "fsl_elbc_init: nand->numchips = %d\n",
chip->numchips);
- dev_dbg(ctrl->dev, "fsl_elbc_init: nand->chipsize = %ld\n",
+ dev_dbg(ctrl->dev, "fsl_elbc_init: nand->chipsize = %lld\n",
chip->chipsize);
dev_dbg(ctrl->dev, "fsl_elbc_init: nand->pagemask = %8x\n",
chip->pagemask);
@@ -703,7 +703,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
dev_dbg(ctrl->dev, "fsl_elbc_init: nand->ecc.layout = %p\n",
chip->ecc.layout);
dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->flags = %08x\n", mtd->flags);
- dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->size = %d\n", mtd->size);
+ dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->size = %lld\n", mtd->size);
dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->erasesize = %d\n",
mtd->erasesize);
dev_dbg(ctrl->dev, "fsl_elbc_init: mtd->writesize = %d\n",
@@ -932,7 +932,7 @@ static int __devinit fsl_elbc_chip_probe(struct
fsl_elbc_ctrl *ctrl,
#endif
add_mtd_device(&priv->mtd);
- printk(KERN_INFO "eLBC NAND device at 0x%zx, bank %d\n",
+ printk(KERN_INFO "eLBC NAND device at 0x%llx, bank %d\n",
res.start, priv->bank);
return 0;
diff --git a/drivers/mtd/nand/pasemi_nand.c b/drivers/mtd/nand/pasemi_nand.c
index 9bd6c9a..a8b9376 100644
--- a/drivers/mtd/nand/pasemi_nand.c
+++ b/drivers/mtd/nand/pasemi_nand.c
@@ -107,7 +107,7 @@ static int __devinit pasemi_nand_probe(struct of_device
*ofdev,
if (pasemi_nand_mtd)
return -ENODEV;
- pr_debug("pasemi_nand at %lx-%lx\n", res.start, res.end);
+ pr_debug("pasemi_nand at %llx-%llx\n", res.start, res.end);
/* Allocate memory for MTD device structure and private data */
pasemi_nand_mtd = kzalloc(sizeof(struct mtd_info) +
@@ -170,7 +170,7 @@ static int __devinit pasemi_nand_probe(struct of_device
*ofdev,
goto out_lpc;
}
- printk(KERN_INFO "PA Semi NAND flash at %08lx, control at I/O %x\n",
+ printk(KERN_INFO "PA Semi NAND flash at %08llx, control at I/O %x\n",
res.start, lpcctl);
return 0;
--
1.6.0.5
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Re: [patch] Possible fix for kexec-tools dynamic range allocation
On Wed, Jan 07, 2009 at 05:01:26PM +1100, Michael Ellerman wrote:
> Hi all,
>
> The patch to dynamically allocate memory regions for ppc64 kexec-tools,
> ie. "ppc64: kexec memory ranges dynamic allocation" (d182ce5), has never
> worked AFAICT.
>
> Chandru reported it as broken when it was posted:
> http://lists.infradead.org/pipermail/kexec/2008-October/002751.html
>
> Still, it's in now, and I'm trying to work out what's going wrong.
>
> The symptom is as reported by Chandru, we end up not being able to
> allocate any memory (in locate_hole()). This is caused by the list of
> memory_ranges being empty.
>
> The memory_ranges are empty because they have been realloc'ed (by the
> dynamic alloc code), and the generic code is still looking at the old
> version.
>
> What I'm not clear on is why the ppc64 code is even calling
> setup_memory_ranges() a second time (in elf_ppc64_load()). It's already
> been called by get_memory_ranges() from my_load(). Or is there another
> route into elf_ppc64_load() that I'm not seeing?
>
> And in fact if I just remove that call, then everything is peachy.
>
> The following patch makes it work for me at least.
Hi Michael,
I must confess that I don't have a complete understanding of this problem.
Does Bernhard's recent patch (sorry that I applied it even though
it came in after your patch) help this problem?
commit 95c74405638c786bc76fbca5e4e8427dfe26e907
Author: Bernhard Walle
Date: Fri Jan 16 19:11:34 2009 +0100
Subject: Fix memory corruption when using realloc_memory_ranges()
> >From 40958d8f957876ca612b666f40bebf28ea335314 Mon Sep 17 00:00:00 2001
> From: Michael Ellerman
> Date: Wed, 7 Jan 2009 16:57:05 +1100
> Subject: [PATCH] Don't call setup_memory_ranges() again
>
> There's no need to call setup_memory_ranges() again. Furthermore it can
> lead to the memory_ranges being realloc'ed, which results in the generic
> code (locate_hole() etc.) using the free'd memory_ranges.
>
> Signed-off-by: Michael Ellerman
> ---
> kexec/arch/ppc64/kexec-elf-ppc64.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c
> b/kexec/arch/ppc64/kexec-elf-ppc64.c
> index 21533cb..1e2d5a3 100644
> --- a/kexec/arch/ppc64/kexec-elf-ppc64.c
> +++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
> @@ -151,8 +151,6 @@ int elf_ppc64_load(int argc, char **argv, const char
> *buf, off_t len,
> if (ramdisk && reuse_initrd)
> die("Can't specify --ramdisk or --initrd with --reuseinitrd\n");
>
> - setup_memory_ranges(info->kexec_flags);
> -
> /* Need to append some command line parameters internally in case of
>* taking crash dumps.
>*/
> --
> 1.5.3.7.1.g4e596e
>
>
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] NULL pointer deref with corrupted squashfs image
On Tue, Jan 20, 2009 at 05:47:14PM +0100, Eric Sesterhenn wrote: > * Jörn Engel (jo...@logfs.org) wrote: > > On Fri, 16 January 2009 16:07:00 -0700, Tom Rini wrote: > > > > > > Sounds like a plan to me, except maybe zlib_inflate_unsafe() and a > > > comment above the wrapper saying what/why is going on? > > > > Eric, will you do the honors? Since you did all the hard work before, > > you derserve the fame as well. :) > > Since I am not sure either about xtensa I added chris to the cc list. How about we just change all callers from arch/*/boot to use the _unsafe version? Then.. > +/* > +These two wrappers decide wheter strm->next_out gets checked for NULL. > +The zlib_inflate_unsafe() version got added because the PPC zImage > +gets extracted to memory address 0 and therefore > +we avoid this check for zlib_inflate_unsafe() These two wrappers decide wheter strm->next_out gets checked for NULL. The zlib_inflate_unsafe() version is primarily used in the pre-Linux 'boot' directory code to allow for extraction to memory address 0 and therefore we avoid this check. -- Tom Rini ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH] "multifunc-device": fix IRQ assignment by also scanning dummy nodes
Hi,
Did anybody pick up on this patch necessary to have OF understand
so-called "multifunc-devices". I received no feedback on it.
I note that the problem persists with 2.6.28.1 (although it was
introduced by the PCI reorg for 2.6.20). File pci_32.c is unchanged in
the latest release.
Regards,
Tom Arbuckle
Homepage: http://www.ece.ul.ie/homepage/Tom_Arbuckle/
LinkedIn: http://www.linkedin.com/in/tomarbuckle
-- Original message --
Kernel: 2.6.28; function: scan_OF_pci_childs; file: arch/powerpc/kernel/pci_32.c
Quoting from line 206 : 'some OFs create a parent node "multifunc-device" as a
fake root for all functions of a multi-function device. we go down
them as well.'
Function scan_OF_for_pci_dev (line 225) also needs to be taught about
these dummy nodes to prevent misallocation/non-allocation of IRQs for
this class of devices.
Why RFC? I have chosen to scan all 'unusual' nodes as possible
multifunc-devices. Is this too many?
Bug seen when using a bt878 multimedia controller card on a G3 Powermac.
This PCI card has separate audio and video nodes and was not being properly
assigned interrupts. (Either 'cannot grab irq 0' or type of assigned
interrupt wrt 'edge/level' was incorrect).
Signed off by: Tom Arbuckle
--- linux-2.6.28/arch/powerpc/kernel/pci_32.c.orig 2008-12-27
16:32:48.0 +
+++ linux-2.6.28/arch/powerpc/kernel/pci_32.c 2008-12-27
16:36:15.0 +
@@ -226,15 +226,21 @@ static struct device_node *scan_OF_for_p
unsigned int devfn)
{
struct device_node *np;
+ struct device_node *np_sub = NULL;
const u32 *reg;
unsigned int psize;
for_each_child_of_node(parent, np) {
reg = of_get_property(np, "reg", &psize);
- if (reg == NULL || psize < 4)
- continue;
- if (((reg[0] >> 8) & 0xff) == devfn)
- return np;
+ if (reg && psize >= 4) {
+ if (((reg[0] >> 8) & 0xff) == devfn)
+ return np;
+ }
+ if (!strcmp(np->name, "multifunc-device")) {
+ np_sub = scan_OF_for_pci_dev(np, devfn);
+ if (np_sub)
+ return np_sub;
+ }
}
return NULL;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] NULL pointer deref with corrupted squashfs image
On Tue, 20 January 2009 17:47:14 +0100, Eric Sesterhenn wrote: > > Some callees of zlib_inflate() might accidentally pass a NULL s/callee/caller/ ? Apart from this, looks fine to me - modulo xtensa of course. Jörn -- Sometimes, asking the right question is already the answer. -- Unknown ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
On Tue, Jan 20, 2009 at 05:27:09PM +0100, Jean-Michel Hautbois wrote: > 2009/1/20 Jean-Michel Hautbois : > > OK, I just tried a cuImage and a ramdisk without a FDT. I am starting > > to boot, but it freezes. > [...] > > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 > > Kernel command line: root=/dev/ram rw > > PID hash table entries: 256 (order: 8, 1024 bytes) > > time_init: decrementer frequency = 25.00 MHz > > time_init: processor frequency = 400.00 MHz > > clocksource: timebase mult[a00] shift[22] registered > > clockevent: decrementer mult[666] sh� > > > > Having a look at the arch/powerpc/kernel/time.c file, where I am > getting halted, it seems that the kernel reads the CPU frequency. Here > is my question: My board has an OSC that is 100MHz (and not 400MHz !). > I think this could be my explanation, but I can't see how I could > solve this problem... A multiplier is applied to the crystal to get the CPU's internal frequency. Try printing out what the kernel thinks the BRG frequency is. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
Jean-Michel Hautbois wrote: OK... And is there anywhere a description of how I can do that :s. Hmm, if the old u-boot on my board is any indication, it doesn't use a single descriptor, so it's not compatible with the early debug. Just turn it off, and with the brg setting removed you should see output when the real serial driver starts. You should find out what's preventing the brg setting from working, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/20 Scott Wood : > Jean-Michel Hautbois wrote: >> >> It is *a lot* better ! >> I am finishing into a kernel panic, but it is a normal thing (bad >> initramfs). >> >> Well, that was using the cuImage. When I try to use the uImage and the >> FDT file, I am stopped here: >> Uncompressing Kernel Image ... OK >> Loading Ramdisk to 039d7000, end 03b7d996 ... OK >> Loading Device Tree to 007fa000, end 007f ... OK > > The early debug address is probably different when not using cuImage; you'll > need to set it to wherever u-boot puts the transmit descriptor. > > -Scott > OK... And is there anywhere a description of how I can do that :s. JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
Jean-Michel Hautbois wrote: It is *a lot* better ! I am finishing into a kernel panic, but it is a normal thing (bad initramfs). Well, that was using the cuImage. When I try to use the uImage and the FDT file, I am stopped here: Uncompressing Kernel Image ... OK Loading Ramdisk to 039d7000, end 03b7d996 ... OK Loading Device Tree to 007fa000, end 007f ... OK The early debug address is probably different when not using cuImage; you'll need to set it to wherever u-boot puts the transmit descriptor. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/20 Scott Wood : > On Tue, Jan 20, 2009 at 11:56:58AM +0100, Jean-Michel Hautbois wrote: >> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 >> Kernel command line: root=/dev/ram rw >> PID hash table entries: 256 (order: 8, 1024 bytes) >> time_init: decrementer frequency = 25.00 MHz >> time_init: processor frequency = 400.00 MHz >> clocksource: timebase mult[a00] shift[22] registered >> clockevent: decrementer mult[666] sh� > > That looks like something is failing when the real (as opposed to early > debug) serial driver starts. Try commenting out the call to cpm_setbrg > in drivers/serial/cpm_uart/cpm_uart_cpm2.h; if that makes a difference, > there's something wrong with the brg node in the device tree. > > -Scott > It is *a lot* better ! I am finishing into a kernel panic, but it is a normal thing (bad initramfs). Well, that was using the cuImage. When I try to use the uImage and the FDT file, I am stopped here: Uncompressing Kernel Image ... OK Loading Ramdisk to 039d7000, end 03b7d996 ... OK Loading Device Tree to 007fa000, end 007f ... OK JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] NULL pointer deref with corrupted squashfs image
* Jörn Engel (jo...@logfs.org) wrote:
> On Fri, 16 January 2009 16:07:00 -0700, Tom Rini wrote:
> >
> > Sounds like a plan to me, except maybe zlib_inflate_unsafe() and a
> > comment above the wrapper saying what/why is going on?
>
> Eric, will you do the honors? Since you did all the hard work before,
> you derserve the fame as well. :)
Since I am not sure either about xtensa I added chris to the cc list.
Some callees of zlib_inflate() might accidentally pass a NULL
pointer in strm->next_out which zlib_inflate() should catch.
Others like the powerpc gunzip_partial expect to be able
to extract a zImage to memory location 0. This introduces
zlib_inflate_usafe() for those and adds a check for the rest
Signed-off-by: Eric Sesterhenn
--- linux/arch/powerpc/boot/gunzip_util.c.orig 2009-01-20 10:23:11.0
+0100
+++ linux/arch/powerpc/boot/gunzip_util.c 2009-01-20 10:23:31.0
+0100
@@ -109,7 +109,7 @@ int gunzip_partial(struct gunzip_state *
state->s.next_out = dst;
state->s.avail_out = dstlen;
- r = zlib_inflate(&state->s, Z_FULL_FLUSH);
+ r = zlib_inflate_unsafe(&state->s, Z_FULL_FLUSH);
if (r != Z_OK && r != Z_STREAM_END)
fatal("inflate returned %d msg: %s\n\r", r,
state->s.msg);
len = state->s.next_out - (unsigned char *)dst;
--- linux/include/linux/zlib.h.orig 2009-01-20 10:11:33.0 +0100
+++ linux/include/linux/zlib.h 2009-01-20 10:19:56.0 +0100
@@ -329,7 +329,23 @@ extern int zlib_inflateInit (z_streamp s
*/
-extern int zlib_inflate (z_streamp strm, int flush);
+extern int __zlib_inflate (z_streamp strm, int flush, int check_out);
+/*
+These two wrappers decide wheter strm->next_out gets checked for NULL.
+The zlib_inflate_unsafe() version got added because the PPC zImage
+gets extracted to memory address 0 and therefore
+we avoid this check for zlib_inflate_unsafe()
+*/
+static inline int zlib_inflate(z_streamp strm, int flush)
+{
+ return __zlib_inflate(strm, flush, 1);
+}
+
+static inline int zlib_inflate_unsafe(z_streamp strm, int flush)
+{
+ return __zlib_inflate(strm, flush, 0);
+}
+
/*
inflate decompresses as much data as possible, and stops when the input
buffer becomes empty or the output buffer becomes full. It may introduce
--- linux/lib/zlib_inflate/inflate_syms.c.orig 2009-01-20 10:22:21.0
+0100
+++ linux/lib/zlib_inflate/inflate_syms.c 2009-01-20 10:22:32.0
+0100
@@ -11,7 +11,7 @@
#include
EXPORT_SYMBOL(zlib_inflate_workspacesize);
-EXPORT_SYMBOL(zlib_inflate);
+EXPORT_SYMBOL(__zlib_inflate);
EXPORT_SYMBOL(zlib_inflateInit2);
EXPORT_SYMBOL(zlib_inflateEnd);
EXPORT_SYMBOL(zlib_inflateReset);
--- linux/lib/zlib_inflate/inflate.c.orig 2009-01-20 10:20:14.0
+0100
+++ linux/lib/zlib_inflate/inflate.c2009-01-20 10:22:03.0 +0100
@@ -329,7 +329,7 @@ static int zlib_inflateSyncPacket(z_stre
will return Z_BUF_ERROR if it has not reached the end of the stream.
*/
-int zlib_inflate(z_streamp strm, int flush)
+int __zlib_inflate(z_streamp strm, int flush, int check_out)
{
struct inflate_state *state;
const unsigned char *next; /* next input */
@@ -347,8 +347,10 @@ int zlib_inflate(z_streamp strm, int flu
static const unsigned short order[19] = /* permutation of code lengths */
{16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15};
-/* Do not check for strm->next_out == NULL here as ppc zImage
- inflates to strm->next_out = 0 */
+/* We only check strm->next_out if the callee requests it,
+ since ppc extracts the ppc zImage to 0 */
+if (check_out && !strm->next_out)
+return Z_STREAM_ERROR;
if (strm == NULL || strm->state == NULL ||
(strm->next_in == NULL && strm->avail_in != 0))
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device Tree setup for 8272-based board
On Tue, Jan 20, 2009 at 06:23:08PM +1100, Daniel Ng wrote: > PID hash table entries: 128 (order: 7, 512 bytes) > time_init: decrementer frequency = 16.50 MHz > time_init: processor frequency = 330.00 MHz > clocksource: timebase mult[f26c9b2] shift[22] registered > clockevent: decrementer mult[439] shift[16] cpu[0] > Console: colour dummy ü > > -at this point the board just reboots. Looks like something goes wrong when the real serial driver kicks in. > I thought it might have been to do with: > > 'No hpxred-bcsr in device tree' > > If I add in a 'BCSR' node to my Device Tree I get the following: Don't add random nodes unless they correspond to hardware that's actually there. > Which leads me to think BCSR is irrelevant for my board. What is BCSR? Board control and status registers. > Another possibility might be that I have set the following in the kernel- > > CONFIG_HZ=250 > > -this is in contrast to the above reported 330Mhz. Those are two different things. CONFIG_HZ is the frequency of timer interrupts that Linux requests. > In the "2.6.14+old u-boot" setup, I had also configured u-boot such > that the memory was set to 64MB, but I told the kernel it was either > 32MB or 64MB depending on what was physically available. This was so I > could use the same u-boot for boards with either 32MB or 64MB. Is it > still possible to do this for the new u-boot and kernel 2.6.27? Yes, but it would be much better if u-boot could figure this out dynamically. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
On Tue, Jan 20, 2009 at 11:56:58AM +0100, Jean-Michel Hautbois wrote: > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 > Kernel command line: root=/dev/ram rw > PID hash table entries: 256 (order: 8, 1024 bytes) > time_init: decrementer frequency = 25.00 MHz > time_init: processor frequency = 400.00 MHz > clocksource: timebase mult[a00] shift[22] registered > clockevent: decrementer mult[666] sh� That looks like something is failing when the real (as opposed to early debug) serial driver starts. Try commenting out the call to cpm_setbrg in drivers/serial/cpm_uart/cpm_uart_cpm2.h; if that makes a difference, there's something wrong with the brg node in the device tree. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/20 Jean-Michel Hautbois : > OK, I just tried a cuImage and a ramdisk without a FDT. I am starting > to boot, but it freezes. [...] > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 > Kernel command line: root=/dev/ram rw > PID hash table entries: 256 (order: 8, 1024 bytes) > time_init: decrementer frequency = 25.00 MHz > time_init: processor frequency = 400.00 MHz > clocksource: timebase mult[a00] shift[22] registered > clockevent: decrementer mult[666] sh� > Having a look at the arch/powerpc/kernel/time.c file, where I am getting halted, it seems that the kernel reads the CPU frequency. Here is my question: My board has an OSC that is 100MHz (and not 400MHz !). I think this could be my explanation, but I can't see how I could solve this problem... Has anyone an idea ? Thx & Regards, JM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bestcomm tasks and interrupts on MPC5200(B)
On Tue, Jan 20, 2009 at 6:15 AM, Dave Best wrote: > I'm trying to write a driver which uses the Local Plus Bus on my MPC5200B and > therefore have to use BestComm DMA, which requires me to use a Gen_BD task > for data transfer with Local Plus. > I tried to follow the fec driver that is currently used and took a peek at > the mpc52xx-ac97 driver which at least uses the same kind of bus as I. > > Initialising the task, resetting and enabling works fine. Even request_irq > reports no error, but when I start a transfer it hangs and if I am lucky, an > interrupt occurs after quite some time. But it's always the BestComm ethernet > rx task which produces an RFIFO interrupt, presumably after the watchdog > catches on. > If this happens my interrupt occurs to. Are you using the LocalPlus fifo device for the transfer (you need to if you aren't)? I've attached a test driver that demonstrates how to do FIFO only and FIFO+DMA transfers over the localplus bus. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. From 23ca0c4b1fa01ace41720aaa0fb32bd4351d0afc Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Mon, 5 Jan 2009 00:53:51 -0700 Subject: [PATCH] Add Bestcomm/localplus test utility --- drivers/misc/Kconfig |4 + drivers/misc/Makefile |1 + drivers/misc/mpc5200-localplus-test.c | 937 + 3 files changed, 942 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/mpc5200-localplus-test.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index fee7304..edcab03 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -13,6 +13,10 @@ menuconfig MISC_DEVICES if MISC_DEVICES +config MPC5200_LOCALPLUS_PERF_TEST + tristate "MPC5200 LocalPlus Bus performance test module" + select PPC_BESTCOMM_GEN_BD + config ATMEL_PWM tristate "Atmel AT32/AT91 PWM support" depends on AVR32 || ARCH_AT91SAM9263 || ARCH_AT91SAM9RL || ARCH_AT91CAP9 diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 817f7f5..19a3d92 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -33,3 +33,4 @@ obj-$(CONFIG_SGI_XP) += sgi-xp/ obj-$(CONFIG_SGI_GRU) += sgi-gru/ obj-$(CONFIG_HP_ILO) += hpilo.o obj-$(CONFIG_C2PORT) += c2port/ +obj-$(CONFIG_MPC5200_LOCALPLUS_PERF_TEST) += mpc5200-localplus-test.o diff --git a/drivers/misc/mpc5200-localplus-test.c b/drivers/misc/mpc5200-localplus-test.c new file mode 100644 index 000..8ba98fc --- /dev/null +++ b/drivers/misc/mpc5200-localplus-test.c @@ -0,0 +1,937 @@ +/* + * LocalPlusBus performance tests. + * + * Copyright (C) Secret Lab Technologies Ltd. 2008-2009 + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + * + * This file implements a set of LocalPlus bus performance tests when using + * direct Programmed IO (PIO), the LocalPlus FIFO, and when using the + * Bestcomm DMA engine to transfer data. It can be compiled into the + * kernel or loaded as a module. + * + * The test module is controlled via files in the sysfs filesystem. Special + * control files are created in /sys/devices/platform/lpbtest.0 which + * control the tests and report the results. Test parameters are set by + * writing values into the parameter files (blocksize, blockcount, period, + * and type). The test is started and stopped with the 'action' file. + * Results are retrieved by reading the contents of the 'results' file. + * + * The following parameters can be modified: + * blocksize: number of bytes to transfer in each block. + * blockcount: number of blocks to transfer per timer tick. + * period: period of timer in microseconds. Every timer tick will start a + * new transfer of data blocks + * type: type of test; may be 'ram', 'fifo' or 'bcom'. + * chipselect: chipselect to use for transfer + * + * The first test type will copies contents of an LPB address range + * using a memcpy. + * Usage: + * $ echo ram > /sys/devices/platform/lpbtest.0/type + * $ echo start > /sys/devices/platform/lpbtest.0/action + * $ sleep 5s + * $ echo stop > /sys/devices/platform/lpbtest.0/action + * + * The second test copies contents of an LPB range to RAM using the + * LocalPlus FIFO. The FIFO ISR copies each packet from the FIFO to RAM. + * Usage: + * $ echo fifo > /sys/devices/platform/lpbtest.0/type + * $ echo start > /sys/devices/platform/lpbtest.0/action + * $ sleep 5s + * $ echo stop > /sys/devices/platform/lpbtest.0/action + * + * The third test copies contents of an LPB range to RAM using both the FIFO + * and the Bestcomm DMA engine. + * + * Usage: + * $ echo bcom > /sys/devices/platform/lpbtest.0/type + * $ echo start > /sys/devices/platform/lpbtest.0/action + * $ sleep 5s + * $ echo stop > /sys/devices/platform/lpbtest.0/action + * + * All sysfs entries can be read by using cat + * e.g. cat /sys/devices/platform/lpbtest.0/type
Re: Kernel Documentation MPC52xx Device Tree Bindings
On Tue, Jan 20, 2009 at 12:44 AM, Roman Fietze
wrote:
> Hello Grant,
>
> Sorry for mailing to you directly, but joining the appropriate mailing
> lists just for posting this one thing doesn't make too much sense.
You don't need to subscribe to post to the list. Just email the list
and CC: me. When I reply it will go to both you *and* the list.
>
> In
>
> Documentation/powerpc/mpc52xx-device-tree-bindings.txt
>
> you wrote or at least submitted:
>
> For example, PSC5 might be physically connected to the port labeled
> 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would have a
> "port-number = <0>" property, and PSC1 would have "port-number =
> <1>".
>
>
> Shouldn't this read 'COM0' instead of 'COM1' for PSC5?
Yes, you are right, but this description is wrong on another level
too. I need to rewrite it. Don't depend on the port-number property
sticking around forever. It was an ignorant hack and a better way of
choosing human friendly labels to devices is to add properties to the
'aliases' node. Something like this:
aliases {
serial0 = &PSC5;
serial1 = &PSC0;
};
where PSC5 and PSC0 are labels (used by the dtc compiler) on the psc5
and psc0 nodes. You can see lots of examples of this in
arch/powerpc/boot/dts/
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bestcomm tasks and interrupts on MPC5200(B)
Dave Best wrote:
I'm trying to write a driver which uses the Local Plus Bus on my MPC5200B and
therefore have to use BestComm DMA, which requires me to use a Gen_BD task for
data transfer with Local Plus.
I tried to follow the fec driver that is currently used and took a peek at the
mpc52xx-ac97 driver which at least uses the same kind of bus as I.
Initialising the task, resetting and enabling works fine. Even request_irq reports no error, but when I start a transfer it hangs and if I am lucky, an interrupt occurs after quite some time. But it's always the BestComm ethernet rx task which produces an RFIFO interrupt, presumably after the watchdog catches on.
If this happens my interrupt occurs to.
I tried to debug this situation but I am still clueless.
If I use the MPC5200 Interrupt emulation registers to force an interrupt for my
interface to occur, nothing happens except that it hangs.
Any hints, tips or help appreciated.
Below is a Disassembler I wrote a couple years ago. Just paste
the hex of interest in the array below, re-compile and run.
Cheers,
-Frank
Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
/*
* disasm.c - disassembler for MPC5200 Bestcomm DMA Firmware
*copy and paste task code into fw, compile a run
* by Frank bennett, 3/29/2006
*
* Based on Freescale pdf "SmartDMA Hand-Assembly Guides"
*
* TODO:
* o add inc[0:7] array (maybe var) to deternmine proper term condition (upper
3 bits)
* o need to review sheet 3 of the pdf
* o simulator would be nice
*
*/
// Task12 (TASK_GEN_TX_BD) : Start of TDT -> 0xf0008528
//
linuxppc_2_4_devel/arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/"dma_image.reloc.c
//
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7,
6, 5, 4| 3, 2, 1, 0
// 0 0 0 1 0 0| 0 0 0 0 0| 0 0| 0 0| 0| 0 0 0 1 0 0| 1| 1 0
0 0 0 1| 0 0 0
// 0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
// 1 0 0| 1 1 0 0 1 0| 0| 0| 1 1 0 0 1 0| 0 0| 0| 0 0 0 0 0
0| 1 1 0| 1 1 0
// 0x99190036, /* 002CLCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7,
6, 5, 4| 3, 2, 1, 0
// 1 0| 0 1 1 0, 0 1 0 1,1 0 0, 0 0 1| 1 0| 1 0 0 1 0 0
0 0 1 0 0 0 0
// 0x9950d210
/* Task12(TASK_GEN_TX_BD): Start of TDT -> 0xf0008528 */
unsigned long fw[] = {
0x800220e3, /* LCD: idx0 = var0, idx1 = var4; idx1 <= var3; idx0 +=
inc4, idx1 += inc3 */
0x13e01010, /* 0004DRD1A: var4 = var2; FN=0 MORE init=24 WS=0 RS=0 */
0xb8808264, /* 0008LCD: idx2 = *idx1, idx3 = var1; idx2 < var9; idx2 +=
inc4, idx3 += inc4 */
0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
0x60140002, /* 0010 DRD2A: EU0=0 EU1=0 EU2=0 EU3=2 EXT init=0 WS=2 RS=2
*/
0x0cccfcca, /* 0014 DRD2B1: *idx3 = EU3(); EU3(*idx3,var10) */
0xd9190300, /* 0018LCDEXT: idx2 = idx2; idx2 > var12; idx2 += inc0 */
0xb8c5e009, /* 001CLCD: idx3 = *(idx1 + var0015); ; idx3 += inc1 */
0x03fec398, /* 0020 DRD1A: *idx0 = *idx3; FN=0 init=24 WS=3 RS=2 */
0x9919826a, /* 0024LCD: idx2 = idx2, idx3 = idx3; idx2 > var9; idx2 +=
inc5, idx3 += inc2 */
0x0feac398, /* 0028 DRD1A: *idx0 = *idx3; FN=0 TFD INT init=24 WS=1
RS=2 */
0x99190036, /* 002CLCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
0x6005, /* 0030 DRD2A: EU0=0 EU1=0 EU2=0 EU3=5 EXT init=0 WS=0 RS=0
*/
0x0c4cf889, /* 0034 DRD2B1: *idx1 = EU3(); EU3(idx2,var9) */
0x01f8, /* 0038NOP */
0x9950d210,
0x2c4cf889,
0
};
union
{
unsigned long i;
struct
{
unsigned sb:3; // [02:00] increment #2
unsigned sa:3; // [05:03] increment #1
unsigned tc:6; // [11:06] variable to which idx is compared
unsigned drtc:1; //[12] dr ? *(tc) : (tc)
unsigned tu:2; // [14:13] term usage 00-idx_a, 01-idx_b, 10- lit
init 11-no cond
unsigned ib:6; // [20:15] init_b
unsigned drib:1; //[21] dr ? *(init_a) : (init_a)
unsigned p:1; //[22] indx plus offset
unsigned ia:6; // [28:23] init_a
unsigned dria:1; //[29] dr ? *(init_a) : (init_a)
unsigned ext:1;//[30] = 2 or 3 for LCD
unsigned op:1; //[31] = 2 or 3 for LCD
} lcd;
struct
{
unsigned ll:13;// [12:00] literal init low
unsigned tu:2; // [14:13] term usage == 2
unsigned lh:15;// [29:15] literal init hi
unsigned bas:1;//[30] = 2 or 3 for LCD
unsigned op:1; //[31] = 2 or 3 for LCD
} lcdl;
struct
{
unsigned fn:3; // [02:00]
unsigned src:6;// [08:03]
unsigned drs:1;//[09] deref src?
unsigned dst:6;// [
[PATCH] powerpc/85xx: Fix typo in mpc8572ds dts
The localbus node flash had a minor typo for a read-only property.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8572ds.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts
b/arch/powerpc/boot/dts/mpc8572ds.dts
index 3dcc001..359c3b7 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -89,7 +89,7 @@
ramd...@0 {
reg = <0x0 0x0300>;
- readl-only;
+ read-only;
};
diagnos...@300 {
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PS3 ps3av_set_video_mode() make id signed
>> make id signed so a negative id will get noticed
>
> Thanks for noticing! It looks OK, except...
> 1. You forgot to update the forward declaration of ps3av_set_video_mode() in
>arch/powerpc/include/asm/ps3av.h (did you compile this succesfully?)
fixed that (and no, sorry, I didn't compile test it, I have to focus a bit on
a biotechnology exam, maybe later).
> 2. You forgot to change `u32 id' in ps3av_probe().
ok, changed it. but I am not sure whether the last two hunks are ok. Should
we error out like this or just let the negative value be assigned to
ps3av->ps3av_mode? If not, is there more cleanup required?
> Can you please make these changes, too? Thx again!
No problem.
->8-8<
Make id signed so a negative id will get noticed. Error out if
ps3av_auto_videomode() fails.
Signed-off-by: Roel Kluin
---
arch/powerpc/include/asm/ps3av.h |2 +-
drivers/ps3/ps3av.c | 16
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3av.h b/arch/powerpc/include/asm/ps3av.h
index cd24ac1..0427b0b 100644
--- a/arch/powerpc/include/asm/ps3av.h
+++ b/arch/powerpc/include/asm/ps3av.h
@@ -730,7 +730,7 @@ extern int ps3av_cmd_av_get_hw_conf(struct
ps3av_pkt_av_get_hw_conf *);
extern int ps3av_cmd_video_get_monitor_info(struct
ps3av_pkt_av_get_monitor_info *,
u32);
-extern int ps3av_set_video_mode(u32);
+extern int ps3av_set_video_mode(int);
extern int ps3av_set_audio_mode(u32, u32, u32, u32, u32);
extern int ps3av_get_auto_mode(void);
extern int ps3av_get_mode(void);
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index 5324978..235e87f 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -838,7 +838,7 @@ static int ps3av_get_hw_conf(struct ps3av *ps3av)
}
/* set mode using id */
-int ps3av_set_video_mode(u32 id)
+int ps3av_set_video_mode(int id)
{
int size;
u32 option;
@@ -940,7 +940,7 @@ EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int ps3av_probe(struct ps3_system_bus_device *dev)
{
int res;
- u32 id;
+ int id;
dev_dbg(&dev->core, " -> %s:%d\n", __func__, __LINE__);
dev_dbg(&dev->core, " timeout=%d\n", timeout);
@@ -962,8 +962,10 @@ static int ps3av_probe(struct ps3_system_bus_device *dev)
init_completion(&ps3av->done);
complete(&ps3av->done);
ps3av->wq = create_singlethread_workqueue("ps3avd");
- if (!ps3av->wq)
+ if (!ps3av->wq) {
+ res = -ENOMEM;
goto fail;
+ }
switch (ps3_os_area_get_av_multi_out()) {
case PS3_PARAM_AV_MULTI_OUT_NTSC:
@@ -994,6 +996,12 @@ static int ps3av_probe(struct ps3_system_bus_device *dev)
safe_mode = 1;
#endif /* CONFIG_FB */
id = ps3av_auto_videomode(&ps3av->av_hw_conf);
+ if (id < 0) {
+ printk(KERN_ERR "%s: invalid id :%d\n", __func__, id);
+ res = -EINVAL;
+ goto fail;
+ }
+
safe_mode = 0;
mutex_lock(&ps3av->mutex);
@@ -1007,7 +1015,7 @@ static int ps3av_probe(struct ps3_system_bus_device *dev)
fail:
kfree(ps3av);
ps3av = NULL;
- return -ENOMEM;
+ return res;
}
static int ps3av_remove(struct ps3_system_bus_device *dev)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bestcomm tasks and interrupts on MPC5200(B)
Dave Best wrote: I'm trying to write a driver which uses the Local Plus Bus on my MPC5200B and therefore have to use BestComm DMA, which requires me to use a Gen_BD task for data transfer with Local Plus. I tried to follow the fec driver that is currently used and took a peek at the mpc52xx-ac97 driver which at least uses the same kind of bus as I. Find attached a Bestcomm instruction set summary sheet from the Freescale folks. Hope this helps. -Frank Initialising the task, resetting and enabling works fine. Even request_irq reports no error, but when I start a transfer it hangs and if I am lucky, an interrupt occurs after quite some time. But it's always the BestComm ethernet rx task which produces an RFIFO interrupt, presumably after the watchdog catches on. If this happens my interrupt occurs to. I tried to debug this situation but I am still clueless. If I use the MPC5200 Interrupt emulation registers to force an interrupt for my interface to occur, nothing happens except that it hangs. Any hints, tips or help appreciated. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev sdHandAssemblyLcdDrd.pdf Description: Adobe PDF document ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove arch/ppc cruft from Kconfig
On Jan 20, 2009, at 9:16 AM, Josh Boyer wrote: Remove some leftover cruft from the arch/ppc days Signed-off-by: Josh Boyer --- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e39b73b..74cc312 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -876,10 +876,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -# XXX source "arch/ppc/8xx_io/Kconfig" - -# XXX source "arch/ppc/8260_io/Kconfig" - source "arch/powerpc/sysdev/qe_lib/Kconfig" source "lib/Kconfig" Acked-by: Kumar Gala - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Remove arch/ppc cruft from Kconfig
Remove some leftover cruft from the arch/ppc days Signed-off-by: Josh Boyer --- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e39b73b..74cc312 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -876,10 +876,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -# XXX source "arch/ppc/8xx_io/Kconfig" - -# XXX source "arch/ppc/8260_io/Kconfig" - source "arch/powerpc/sysdev/qe_lib/Kconfig" source "lib/Kconfig" ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mb862xx: Restrict compliation of platform driver to PPC
Julian Calaby wrote: > mb862xx: Restrict compliation of platform driver to PPC > > The OpenFirmware part of this driver is uncompilable on SPARC due to it's > dependance on several PPC specific functions. > > Restricting this to PPC to prevent these build errors. > > This was found using randconfig builds. > > Signed-off-by: Julian Calaby Acked-by: Anatolij Gustschin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Bestcomm tasks and interrupts on MPC5200(B)
I'm trying to write a driver which uses the Local Plus Bus on my MPC5200B and therefore have to use BestComm DMA, which requires me to use a Gen_BD task for data transfer with Local Plus. I tried to follow the fec driver that is currently used and took a peek at the mpc52xx-ac97 driver which at least uses the same kind of bus as I. Initialising the task, resetting and enabling works fine. Even request_irq reports no error, but when I start a transfer it hangs and if I am lucky, an interrupt occurs after quite some time. But it's always the BestComm ethernet rx task which produces an RFIFO interrupt, presumably after the watchdog catches on. If this happens my interrupt occurs to. I tried to debug this situation but I am still clueless. If I use the MPC5200 Interrupt emulation registers to force an interrupt for my interface to occur, nothing happens except that it hangs. Any hints, tips or help appreciated. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Defconfig support
On Mon, Jan 19, 2009 at 11:21:36PM -0500, Sean MacLennan wrote: >Since the list seems quiet right now, thought I would ask a question. >Up till now I haven't really worried about the warp defconfig being up >to date since, realistically, the stock kernel was not usable on the >warp. Since it usually boots from NAND, the lack of an ndfc driver >made it unbootable in a production system. > >However, the 2.6.29 kernel will boot, so the defconfig problem becomes >more acute. The problem is keeping the changes that are required for >the warp while also handling the normal changes that happen every >release. > >For example, the current git diff shows CONFIG_SIMPLE_GPIO which is >just a new feature and can be safely left unset. But the watchdog made >it into the kernel, so CONFIG_PIKA_WDT should be set for a warp. > >Any ideas for a good way of handling this? You can certainly send me patches for defconfig updates. I go through and update them all (via make xxx_defconfig; make oldconfig) after -rc2 is available, but I might not set everything exactly as you would want to see it. If there's a chicken/egg problem in that there are drivers or changes that went upstream but aren't in the powerpc branches yet for one reason or another, you can poke me about getting things pulled in. Since I'll be doing defconfig updates today, just tell me which options you need set or disabled. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Warp patches for the new ndfc driver
On Mon, Jan 19, 2009 at 11:12:05PM -0500, Sean MacLennan wrote: >On Fri, 9 Jan 2009 23:20:11 -0500 >"Sean MacLennan" wrote: > >> Woo hoo! The ndfc driver finally got in the kernel! These patches >> update the warp to use the new driver. > >Just a bump and a comment to see who is reading this ;) > >2.6.29 is a very important release for the Warp because with the >ndfc driver, and assuming this patch or something like it is accepted, >you will be able to get a working kernel for the warp from kernel.org. >It will be missing SD support and LED support, but everything else will >work :) I have it queued up for today. I was waiting for Ben to bump his tree to include -rc2 so that I can send him the defconfig updates at the same time. >But it seems to me that otherwise, 2.6.29 seems to be a very quiet >release. Has anybody else noticed this? Yes. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards
Original-Nachricht > Datum: Mon, 19 Jan 2009 19:28:35 +0100 > Von: Bartlomiej Zolnierkiewicz > An: "Gerhard Pircher" > CC: Benjamin Herrenschmidt , > linux-...@vger.kernel.org, linuxppc-dev@ozlabs.org, grant.lik...@secretlab.ca > Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne > boards > The following patchset fixes core IDE PCI code to always use > pci_get_legacy_ide_irq() and ide_pci_is_in_compatibility_mode(): > > http://lkml.org/lkml/2009/1/19/163 > > so via82cxxx specific solution is no longer necessary. > > [ IOW I'll keep your previous patch and the #ifdef issue will > solve itself after the above patchset is merged. ] Thanks a lot! That's much better than the simple fix I had planned. Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Cannot start my Linux Kernel
2009/1/16 Scott Wood : > Jean-Michel Hautbois wrote: >> >> OK, I just tried a make of my kernel (already compiled yesterday), and >> it generated a cuImage.mpc8272ads kernel image (which it didn't do >> yesterday). >> I don't know why this image was generated, but I tried to reboot using >> this one. > > Use uImage if you are providing a device tree from u-boot. cuImage is for > older u-boots that don't support this, though you could still try using it > on a modern u-boot with a one- or two-argument bootm command to try to > isolate the problem. > > -Scott > OK, I just tried a cuImage and a ramdisk without a FDT. I am starting to boot, but it freezes. Following is the boot evolution. Thx & Regards, JM bootm 100 200 ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-2.6.29-rc1-01197-g5a7b6e7- Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1529877 Bytes = 1.5 MB Load Address: 0040 Entry Point: 00400b94 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: Sofrel RAM Disk Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:3130063 Bytes = 3 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Loading Ramdisk to 03882000, end 03b7e2cf ... OK Memory <- <0x0 0x400> (64MB) ENET0: local-mac-address <- 00:04:9f:11:22:33 ENET1: local-mac-address <- 00:00:00:00:00:00 CPU clock-frequency <- 0x17d78400 (400MHz) CPU timebase-frequency <- 0x17d7840 (25MHz) CPU bus-frequency <- 0x5f5e100 (100MHz) zImage starting: loaded at 0x0040 (sp: 0x03b7ebe8) Allocating 0x329908 bytes for kernel ... gunzipping (0x <- 0x0040d000:0x007591d8)...done 0x308b0c bytes Using loader supplied ramdisk at 0x3882000-0x3b7e2cf initrd head: 0x1f8b0800 Linux/PowerPC load: root=/dev/ram rw Finalizing device tree... flat tree at 0x767300 id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using Freescale MPC8272 ADS machine description Linux version 2.6.29-rc1-01197-g5a7b6e7-dirty (d...@gforge) (gcc version 4.2.2) #2 Thu Jan 15 18:31:04 CET 2009 Found initrd at 0xc3882000:0xc3b7e2cf console [udbg0] enabled setup_arch: bootmem mpc8272_ads_setup_arch() PCI host bridge /p...@f0010800 (primary) ranges: MEM 0x8000..0x9fff -> 0x8000 Prefetch MEM 0xa000..0xbfff -> 0xa000 IO 0xf600..0xf7ff -> 0x mpc8272_ads_setup_arch(), finish arch: exit Top of RAM: 0x400, Total RAM: 0x400 Memory hole size: 0MB Zone PFN ranges: DMA 0x -> 0x4000 Normal 0x4000 -> 0x4000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x4000 On node 0 totalpages: 16384 free_area_init_node: node 0, pgdat c02ffc90, node_mem_map c033 DMA zone: 128 pages used for memmap DMA zone: 0 pages reserved DMA zone: 16256 pages, LIFO batch:3 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/ram rw PID hash table entries: 256 (order: 8, 1024 bytes) time_init: decrementer frequency = 25.00 MHz time_init: processor frequency = 400.00 MHz clocksource: timebase mult[a00] shift[22] registered clockevent: decrementer mult[666] sh� ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PS3 ps3av_set_video_mode() make id signed
On Sat, 17 Jan 2009, Roel Kluin wrote:
> vi drivers/video/ps3fb.c +618
> static int ps3fb_set_par(struct fb_info *info)
> {
> struct ps3fb_par *par = info->par;
> ... [ and at line 660 ] ...
> if (ps3av_set_video_mode(par->new_mode_id))
>
> now new_mode_id is an int
>
> vi drivers/video/ps3fb.c +132
> struct ps3fb_par {
> ...
> int new_mode_id;
> ...
> };
>
> vi drivers/ps3/ps3av.c +844
> int ps3av_set_video_mode(u32 id)
>
> -^^^
>
> {
> ...
> if (... || id < 0) {
>
> ^^^
>
> dev_dbg(&ps3av->dev->core, "%s: error id :%d\n", __func__, id);
> return -EINVAL;
> }
> ...
> id = ps3av_auto_videomode(&ps3av->av_hw_conf);
> if (id < 1) {
> -^^^
> printk(KERN_ERR "%s: invalid id :%d\n", __func__, id);
> return -EINVAL;
> }
> ...
> ps3av->ps3av_mode = id;
>
> vi drivers/ps3/ps3av.c +763
> static int ps3av_auto_videomode()
>
> ---^^^
>
> +42
> static struct ps3av {
> ...
> int ps3av_mode;
> ...
> };
>
> ->8---8<---
> make id signed so a negative id will get noticed
Thanks for noticing! It looks OK, except...
> Signed-off-by: Roel Kluin
> ---
> diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
> index 5324978..7aa6d41 100644
> --- a/drivers/ps3/ps3av.c
> +++ b/drivers/ps3/ps3av.c
> @@ -838,7 +838,7 @@ static int ps3av_get_hw_conf(struct ps3av *ps3av)
> }
>
> /* set mode using id */
> -int ps3av_set_video_mode(u32 id)
> +int ps3av_set_video_mode(int id)
> {
> int size;
> u32 option;
1. You forgot to update the forward declaration of ps3av_set_video_mode() in
arch/powerpc/include/asm/ps3av.h (did you compile this succesfully?)
2. You forgot to change `u32 id' in ps3av_probe().
Can you please make these changes, too? Thx again!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc9 panics with crashkernel=256M while booting
Chandru wrote:
In case either physbase or reserve_size are not page aligned and in addition
if the following condition is also true
node_ar.end_pfn = node->node_end_pfn = PFN_DOWN(physbase+reserve_size).
we may hit the BUG_ON(end > bdata->node_low_pfn) in mark_bootmem_node() in
mm/bootmem.c Hence pass the pfn that the physbase is part of and align
reserve_size before calling reserve_bootmem_node().
Signed-off-by: Chandru S
Cc: Dave Hansen
---
arch/powerpc/mm/numa.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.29-rc2/arch/powerpc/mm/numa.c.orig2009-01-19
16:14:49.0 +0530
+++ linux-2.6.29-rc2/arch/powerpc/mm/numa.c 2009-01-19 16:36:38.0
+0530
@@ -901,7 +901,8 @@ static void mark_reserved_regions_for_ni
get_node_active_region(start_pfn, &node_ar);
while (start_pfn < end_pfn &&
node_ar.start_pfn < node_ar.end_pfn) {
- unsigned long reserve_size = size;
+ unsigned long reserve_size = (size >> PAGE_SHIFT) <<
+ PAGE_SHIFT;
/*
* if reserved region extends past active region
* then trim size to active region
@@ -917,7 +918,8 @@ static void mark_reserved_regions_for_ni
dbg("reserve_bootmem %lx %lx nid=%d\n",
physbase, reserve_size, node_ar.nid);
reserve_bootmem_node(NODE_DATA(node_ar.nid),
- physbase, reserve_size,
+ (start_pfn << PAGE_SHIFT),
+ reserve_size,
BOOTMEM_DEFAULT);
}
/*
does this patch look good ?, do you concur with it ?
thanks,
Chandru
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
