* Re: jffs2 file system on MPC8272ADS board
From: Vitaly Bordug @ 2007-09-27 19:01 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-dev
In-Reply-To: <12900017.post@talk.nabble.com>
Hello Nethra,
On Wed, 26 Sep 2007 05:34:14 -0700 (PDT)
Nethra wrote:
>
>
> Hello ,
>
> >>
> >> hi everyone,
> >>
> >> I m using custom board similar to MPC8272ADS board...
> >>
> >> 1) For the first time it boots up properly in case if we overwrite any
> >> existing binaries using nfs mounted file system on the board, after
> >> rebooting it displays fallowing message...
> >>
> >> Further such events for this erase block will not be printed
> >> Eep. Child "null" (ino #1346) of dir ino #3 doesn't exist!
> >> Eep. Child "autocomm" (ino #463) of dir ino #461 doesn't exist!
> >> Eep. Child "calibration" (ino #464) of dir ino #461 doesn't exist!
> >> Eep. Child "coredsp_driver.ko" (ino #939) of dir ino #336 doesn't exist!
> >> Inode #1307 was a directory with children - removing those too...
> >> Inode #564 was a directory with children - removing those too...
> >> Inode #565 was a directory with children - removing those too...
> >> Inode #1112 was a directory with children - removing those too...
> >> Inode #1115 was a directory with children - removing those too...
> >> Inode #1118 was a directory with children - removing those too...
> >> Inode #1123 was a directory with children - removing those too...
> >>
> >> after this board boots up properly....but it not be having overwritten
> >> files
> >>
>
> >Have you created jffs2 file system on flash prior to mounting it?
>
> Yes I created jffs2 filesytem using mkfs.jffs2 prior to mounting and then I
> am over-writing some of the binaries. In case of overwrites from NFS after
> reboot
> I see the above errors & the binaries/directories gets deleted from the
> jffs2 partition.
>
> >> 3) when board is running properly in between it starts printing on
> >> console
> >> repeatedly...
> >>
>
> >Do the proper MTD partitions setup, erase the partition and create jffs2
> filesystem on it.
> >If after all those steps you're still getting output, that is prolly flakey
> flash.
>
> >> Header CRC failed on REF_PRISTINE node at 0x00638a6c: Read 0xffffffff,
> >> calculated 0x44660075
> >> Node totlen on flash (0xffffffff) != totlen from node ref (0x00000254)
> >> Header CRC failed on REF_PRISTINE node at 0x00638cc0: Read 0xffffffff,
> >> calculated 0x44660075
> [...]
> >> and
> >>
> >> file system is created using fallowing command..
> >>
> >> mkfs.jffs2 -r RFS_NEW/ -e 0x20000 -o /tftpboot/jffs2_img -b
> >>
> >I am recalling playing with the options upper also cured the jffs2 warnings
> (not as many as yours but anyway)
>
> The other options I am wondering about,
> -c, --cleanmarker=SIZE Size of cleanmarker (default 12)
> -n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock
> cleanmaker size will it help the cause?
well, try to get rid of padding first.
are you sure about -e? please try
mkfs.jffs2 -e 128 -d ./myimage -b -o out.jffs2 instead.
--
Sincerely, Vitaly
^ permalink raw reply
* 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 19:12 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Hi,
I'm working on a 2.6.23 kernel for the AmigaOne. I implemented the device
tree and the platform setup code, which all compiles fine. I built a
cuImage target, loaded it on my target machine with TFTP and booted it.
The kernel passes the platform setup code and then dies somewhere in the
driver init code (AFAICT), but before the keyboard driver is initialized
(thus magic sysrq key doesn't work). Can somebody help me to track down
this problem?
I tried to recover the kernel log buffer and attached it to this e-mail.
regards,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
[-- Attachment #2: amigaone.dts --]
[-- Type: application/octet-stream, Size: 6146 bytes --]
/*
* AmigaOne Device Tree Source
*
* Copyright 2007 Gerhard Pircher (gerhard_pircher@gmx.net)
*
* 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
* option) any later version.
*/
/ {
model = "AmigaOne";
compatible = "eyetech,amigaone","mai-logic,teron";
coherency-off;
#address-cells = <1>;
#size-cells = <1>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33.3 MHz, from U-boot
clock-frequency = <0>; // From U-boot
bus-frequency = <0>; // From U-boot
32-bit;
};
};
memory {
device_type = "memory";
reg = <0 0>; // From U-boot
};
pci@80000000 {
device_type = "pci";
compatible = "mai-logic,articia-s";
bus-frequency = <01fca055>; // 33.3MHz
bus-range = <0 ff>;
ranges = <01000000 0 00000000 fe000000 0 00c00000 // PCI I/O
02000000 0 80000000 80000000 0 7d000000 // PCI memory
02000000 0 fd000000 fd000000 0 01000000>; // PCI alias memory
interrupt-parent = <&i8259>;
8259-interrupt-acknowledge = <fef00000>;
#interrupt-cells = <1>;
#address-cells = <3>;
#size-cells = <2>;
host@0 {
compatible = "pciclass,0600";
vendor-id = <000010cc>;
device-id = <00000660>;
revision-id = <00000001>;
class-code = <00060000>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <00000001>;
66mhz-capable;
min-grant = <0>;
max-latency = <0>;
// AGP aperture is unset.
reg = <42000010 0 00000000 0 00400000>;
assigned-addresses = <42000010 0 00000000 0 00400000>;
};
isa@7 {
device_type = "isa";
compatible = "pciclass,0601";
vendor-id = <00001106>;
device-id = <00000686>;
revision-id = <00000010>;
class-code = <00060100>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <00000001>;
min-grant = <0>;
max-latency = <0>;
/* First 64k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */
ranges = <00000001 0 01000000 0 00000000 00010000>;
interrupt-parent = <&i8259>;
#interrupt-cells = <2>;
#address-cells = <2>;
#size-cells = <1>;
dma-controller@0 {
device_type = "dma-controller";
compatible = "pnpPNP,200";
reg = <00000001 00000000 00000020
00000001 00000080 00000010
00000001 000000c0 00000020>;
/* Channel 4 reserverd, cascade mode, 2x32k transfer/counter
* widths and bus master capability. Is this really necessary?
*/
/* dma = <4 4 20 20 1>; */
};
i8259: interrupt-controller@20 {
device_type = "interrupt-controller";
compatible = "pnpPNP,000";
interrupt-controller;
reg = <00000001 00000020 00000002
00000001 000000a0 00000002
00000001 000004d0 00000002>;
reserved-interrupts = <2>;
};
timer@40 {
/* device_type = "timer"; */ // No device type binding for now.
compatibe = "pnpPNP,100"; // Also add pcspkr to platform devices.
reg = <00000001 00000040 00000020>;
};
8042@60 {
device_type = "8042";
reg = <00000001 00000060 00000001
00000001 00000064 00000001>;
interrupts = <1 3 c 3>; // IRQ1, IRQ12 (rising edge)
#address-cells = <1>;
#size-cells = <0>;
keyboard@0 {
device_type = "keyboard";
compatible = "pnpPNP,303";
reg = <0>;
};
mouse@1 {
device_type = "mouse";
compatible = "pnpPNP,f03";
reg = <1>;
};
};
rtc@70 {
device_type = "rtc";
compatible = "pnpPNP,b00";
reg = <00000001 00000070 00000002>;
interrupts = <8 3>;
};
serial@2f8 {
device_type = "serial";
compatible = "pnpPNP,501","pnpPNP,500"; // "ns16550"; add property check to OF serial code.
reg = <00000001 000002f8 00000008>;
interrupts = <3 3>; // IRQ3 (rising edge)
clock-frequency = <0>; // Not necessary?
};
serial@3f8 {
device_type = "serial";
compatible = "pnpPNP,501","pnpPNP,500"; // "ns16550"; add property check to OF serial code.
reg = <00000001 000003f8 00000008>;
interrupts = <4 3>; // IRQ4 (rising edge)
clock-frequency = <0>; // Not necessary?
};
parallel@378 {
device_type = "parallel";
compatible = "pnpPNP,400"; // "pnpPNP,401" // No ECP support for now.
reg = <00000001 00000378 00000003
00000001 00000778 00000003>;
/* interrupts = <7>; */
/* dma = <3 0 0 0>; */ // Parallel port DMA mode?
};
fdc@3f0 {
device_type = "fdc";
compatible = "pnpPNP,700";
reg = <00000001 000003f0 00000008>;
interrupts = <6 3>; // IRQ6 (rising edge)
/* dma = < >; */ // Floppy DMA mode?
#address-cells = <1>;
#size-cells = <0>;
disk@0 {
device_type = "block";
reg = <0>;
};
};
};
ide@7,1 {
compatible = "pciclass,01018f";
vendor-id = <00001106>;
device-id = <00000571>;
revision-id = <00000006>;
// Class code with PCI IDE programming interface indicator.
class-code = <0001018f>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <00000001>;
min-grant = <0>;
max-latency = <0>;
fast-back-to-back;
// Assume base addresses are relocateable, even if
// controller operates in compatibility mode.
reg = <21003910 0 00000000 0 00000000
21003914 0 00000000 0 00000000
21003918 0 00000000 0 00000000
2100391c 0 00000000 0 00000000
21003920 0 00000000 0 00000000>;
assigned-addresses = <01003910 0 000001f0 0 00000008
01003914 0 000003f4 0 00000004
01003918 0 00000170 0 00000008
0100391c 0 00000374 0 00000004
01003920 0 0000cc00 0 00000010>;
interrupt-parent = <&i8259>;
interrupts = <e 3 f 3>;
#interrupt-cells = <2>;
};
};
chosen {
linux,stdout-path = "/pci@80000000/isa@7/serial@2f8";
};
};
[-- Attachment #3: setup.c --]
[-- Type: text/x-csrc, Size: 6285 bytes --]
/*
* AmigaOne platform setup
*
* Copyright 2007 Gerhard Pircher (gerhard_pircher@gmx.net)
*
* Based on original amigaone_setup.c source code
* Copyright 2003 by Hans-Jörg and Thomas Frieden
* and chrp/setup.c
* Copyright 1995 by Linus Torvalds
*
* 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
* option) any later version.
*/
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/stddef.h>
#include <linux/unistd.h>
#include <linux/ptrace.h>
#include <linux/slab.h>
#include <linux/user.h>
#include <linux/tty.h>
#include <linux/major.h>
#include <linux/interrupt.h>
#include <linux/reboot.h>
#include <linux/init.h>
#include <linux/ide.h>
#include <linux/pci.h>
#include <linux/utsrelease.h>
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/console.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/initrd.h>
#include <linux/module.h>
#include <linux/timer.h>
#include <asm/cputable.h>
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/pci-bridge.h>
#include <asm/dma.h>
#include <asm/machdep.h>
#include <asm/irq.h>
#include <asm/sections.h>
#include <asm/time.h>
#include <asm/i8259.h>
#include <asm/system.h>
#include <asm/udbg.h>
#include <asm/vga.h>
extern void amigaone_find_bridges(void);
void amigaone_set_l2cr(void)
{
/* This disables the L2 hardware prefetch. It is normally disabled and
* enabled again within _set_L2CR(), but the L2 prefetch enable is not
* compiled in for the AmigaOne.
*/
_set_L2CR(_get_L2CR());
if(((_get_L2CR() & L2CR_L2E) == 0) && (strstr(cmd_line, "l2cr=") == NULL))
{
printk("AmigaOne l2cr : L2 cache was not active, activating.\n");
_set_L2CR(0);
_set_L2CR(L2CR_L2E | L2CR_L2PE);
}
}
int amigaone_show_cpuinfo(struct seq_file *m)
{
struct device_node *root;
const char *model = "";
root = of_find_node_by_path("/");
if (root)
model = of_get_property(root, "model", NULL);
seq_printf(m, "machine\t\t: %s\n", model);
of_node_put(root);
seq_printf(m, "msscr0\t\t: 0x%08lX\n", mfspr(SPRN_MSSCR0));
return 0;
}
void __init amigaone_setup_arch(void)
{
/* init to some ~sane value until calibrate_delay() runs */
loops_per_jiffy = 50000000/HZ;
#ifdef CONFIG_BLK_DEV_INITRD
/* this is fine for chrp */
initrd_below_start_ok = 1;
if (initrd_start)
ROOT_DEV = Root_RAM0;
else
#endif
ROOT_DEV = Root_SDA2; /* sda2 (sda1 is for the kernel or OS4) */
/* Enable the L2 cache. */
amigaone_set_l2cr();
/* Lookup PCI host bridges */
/* setup PCI host bridge */
#ifdef CONFIG_PCI_HOST_DRIVER
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
articias_setup_pci(np);
#else
amigaone_find_bridges();
#endif
/* Uncomment, when U-boot was updated. */
// pci_create_OF_bus_map();
/* vgacon.c needs to know where VGA memory is mapped. */
// vgacon_remap_base = (unsigned long) ioremap(0xfd000000, 0x01000000);
// conswitchp = &vga_con;
if (ppc_md.progress)
ppc_md.progress("Linux/PPC "UTS_RELEASE"\n", 0x0);
}
void __init amigaone_init_IRQ(void)
{
struct device_node *np, *pic = NULL;
unsigned long amigaone_int_ack = 0;
/* Search for ISA interrupt controller. */
for_each_node_by_type(np, "interrupt-controller")
if (of_device_is_compatible(np, "pnpPNP,000")) {
pic = np;
break;
}
BUG_ON(pic == NULL);
/* Look for interrupt acknowledge address in the PCI root node. */
for_each_node_by_name(np, "pci") {
const unsigned int *addrp = of_get_property(np,
"8259-interrupt-acknowledge", NULL);
if (addrp == NULL)
continue;
amigaone_int_ack = addrp[of_n_addr_cells(np)-1];
break;
}
of_node_put(np);
if (np == NULL)
printk(KERN_WARNING "Cannot find PCI interrupt acknowledge"
" address, polling\n");
i8259_init(pic, amigaone_int_ack);
ppc_md.get_irq = i8259_irq;
irq_set_default_host(i8259_get_host());
}
void __init amigaone_init(void)
{
#ifdef CONFIG_NVRAM
// amigaone_nvram_init();
#endif
request_region(0x20,0x20,"pic1");
request_region(0xa0,0x20,"pic2");
request_region(0x00,0x20,"dma1");
request_region(0x40,0x20,"timer");
request_region(0x80,0x10,"dma page reg");
request_region(0xc0,0x20,"dma2");
}
/* Copied from U-Boot. */
static inline void soft_restart(unsigned long addr)
{
/* SRR0 has system reset vector, SRR1 has default MSR value.
* rfi restores MSR from SRR1 and sets the PC to the SRR0 value.
*/
__asm__ __volatile__ ("mtspr 26, %0" :: "r" (addr));
__asm__ __volatile__ ("li 4, (1 << 6)" ::: "r4");
__asm__ __volatile__ ("mtspr 27, 4");
__asm__ __volatile__ ("rfi");
/* Not reached. */
while(1);
}
void amigaone_restart(char *cmd)
{
unsigned long addr;
local_irq_disable();
/* Flush and disable I/D cache. */
__asm__ __volatile__ ("mfspr 3, 1008" ::: "r3");
__asm__ __volatile__ ("ori 5, 5, 0xcc00" ::: "r5");
__asm__ __volatile__ ("ori 4, 3, 0xc00" ::: "r4");
__asm__ __volatile__ ("andc 5, 3, 5" ::: "r5");
__asm__ __volatile__ ("sync");
__asm__ __volatile__ ("mtspr 1008, 4");
__asm__ __volatile__ ("isync");
__asm__ __volatile__ ("sync");
__asm__ __volatile__ ("mtspr 1008, 5");
__asm__ __volatile__ ("isync");
__asm__ __volatile__ ("sync");
addr = 0xfff00100;
soft_restart(addr);
while(1);
}
static int __init amigaone_probe(void)
{
unsigned long root = of_get_flat_dt_root();
if (of_flat_dt_is_compatible(root, "eyetech,amigaone")) {
/* Coherent memory access cause complete system lockup! Thus
* remove it in any case, even if the CPU needs it. We'll
* disable the L2 cache prefetch later on.
*/
cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
ISA_DMA_THRESHOLD = 0x00FFFFFF;
DMA_MODE_READ = 0x44;
DMA_MODE_WRITE = 0x48;
return 1;
}
return 0;
}
define_machine(amigaone) {
.name = "AmigaOne",
.probe = amigaone_probe,
.setup_arch = amigaone_setup_arch,
.init = amigaone_init,
.show_cpuinfo = amigaone_show_cpuinfo,
.init_IRQ = amigaone_init_IRQ,
.restart = amigaone_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
.phys_mem_access_prot = pci_phys_mem_access_prot,
};
[-- Attachment #4: pci.c --]
[-- Type: text/x-csrc, Size: 1894 bytes --]
/*
* AmigaOne platform PCI setup
*
* Copyright 2007 Gerhard Pircher (gerhard_pircher@gmx.net)
*
* 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
* option) any later version.
*/
#include <linux/kernel.h>
#include <linux/pci.h>
#include <linux/delay.h>
#include <linux/string.h>
#include <linux/init.h>
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/irq.h>
#include <asm/machdep.h>
#include <asm/sections.h>
#include <asm/pci-bridge.h>
void __init
amigaone_find_bridges(void)
{
struct device_node *dev;
const int *bus_range;
int len, index = -1;
struct pci_controller *hose;
struct device_node *root = of_find_node_by_path("/");
for (dev = root->child; dev != NULL; dev = dev->sibling) {
if (dev->type == NULL || strcmp(dev->type, "pci") != 0)
continue;
++index;
bus_range = of_get_property(dev, "bus-range", &len);
if (bus_range == NULL || len < 2 * sizeof(int)) {
printk(KERN_WARNING "Can't get bus-range for %s\n",
dev->full_name);
continue;
}
/* if (bus_range[1] == bus_range[0])
printk(KERN_INFO "PCI bus %d", bus_range[0]);
else
printk(KERN_INFO "PCI buses %d..%d",
bus_range[0], bus_range[1]);
printk(" controlled by %s", dev->full_name); */
hose = pcibios_alloc_controller(dev);
if (!hose) {
printk("Can't allocate PCI controller structure for %s\n",
dev->full_name);
continue;
}
hose->arch_data = dev;
hose->first_busno = bus_range[0];
hose->last_busno = bus_range[1];
setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0);
/* Interpret the "ranges" property */
/* This also maps the I/O region and sets isa_io/mem_base. */
pci_process_bridge_OF_ranges(hose, dev, index == 0);
}
of_node_put(root);
}
[-- Attachment #5: syslog.log --]
[-- Type: text/x-log, Size: 3349 bytes --]
<6>Using AmigaOne machine description.
<4>Total memory = 1536MB; using 4096kB for hash table (at cfc00000).
<5>Linux version 2.6.23-rc8 (geri@earth) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #11 Wed Sep 26 22:35:58 CEST 2007.
<4> -> find_legacy_serial_port().
<4>stdout is /pci@80000000/isa@7/serial@2f8.
<4> -> add_legacy_isa_port(/pci@80000000/isa@7/serial@2f8).
<7>Found legacy serial port 0 for /pci@80000000/isa@7/serial@2f8.
<7> port=2f8, taddr=fe0002f8, irq=0, clk=1843200,speed=0.
<4> -> add_legacy_isa_port(/pci@80000000/isa@7/serial@3f8).
<7>Found legacy serial port 1 for /pci@80000000/isa@7/serial@3f8.
<7> port=3f8, taddr=fe0003f8, irq=0, clk=1843200, speed=0.
<4>legacy_serial_console = 0.
<4>default console speed = 115200.
<4> <- find_legacy_serial_port().
<6>console [udbg0] enabled.
<7>Entering add_active_range(0, 0, 393216) 0 entries of 256 used.
<4>AmigaOne l2cr : L2 cache was not active, activating..
<4>PCI: IO 0x0 -> 0xbfffff.
<4>PCI: MEM[0] 0x80000000 -> 0xfdffffff.
<7>Top of RAM: 0x60000000, Total RAM: 0x60000000.
<7>Memory hole size: 0MB.
<4>Zone PFN ranges:.
<4> DMA 0 -> 196608.
<4> Normal 196608 -> 196608.
<4> HighMem 196608 -> 393216.
<4>Movable zone start PFN for each node.
<4>early_node_map[1] active PFN ranges.
<4> 0: 0 -> 393216.
<7>On node 0 totalpages: 393216.
<7> DMA zone: 1536 pages used for memmap.
<7> DMA zone: 0 pages reserved.
<7> DMA zone: 195072 pages, LIFO batch:31.
<7> Normal zone: 0 pages used for memmap.
<7> HighMem zone: 1536 pages used for memmap.
<7> HighMem zone: 195072 pages, LIFO batch:31.
<7> Movable zone: 0 pages used for memmap.
<4>Built 1 zonelists in Zone order. Total pages: 390144.
<5>Kernel command line: root=/dev/hda11 console=udbg0 console=/dev/ttyS0,115200n8.
<7>i8259_host_map(1, 0x1).
<7>i8259_host_map(2, 0x2).
<7>i8259_host_map(3, 0x3).
<7>i8259_host_map(4, 0x4).
<7>i8259_host_map(5, 0x5).
<7>i8259_host_map(6, 0x6).
<7>i8259_host_map(7, 0x7).
<7>i8259_host_map(8, 0x8).
<7>i8259_host_map(9, 0x9).
<7>i8259_host_map(10, 0xa).
<7>i8259_host_map(11, 0xb).
<7>i8259_host_map(12, 0xc).
<7>i8259_host_map(13, 0xd).
<7>i8259_host_map(14, 0xe).
<7>i8259_host_map(15, 0xf).
<7>irq: Allocated host of type 0 @0xc04b5080.
<6>i8259 legacy interrupt controller initialized.
<7>irq: Default host set to @0xc04b5080.
<4>PID hash table entries: 4096 (order: 12, 16384 bytes).
<7>time_init: decrementer frequency = 33.333333 MHz.
<7>time_init: processor frequency = 800.000000 MHz.
<4> -> check_legacy_serial_console().
<4> console was specified !.
<4>Console: colour dummy device 80x25.
<6>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes).
<6>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes).
<7>High memory: 786432k.
<6>Memory: 1549564k/1572864k available (3416k kernel code, 808700k reserved, 152k data, 1182k bss, 176k init).
<7>Calibrating delay loop... 66.56 BogoMIPS (lpj=133120).
<6>Security Framework v1.0.0 initialized.
<6>SELinux: Disabled at boot..
<6>Capability LSM initialized.
<4>Mount-cache hash table entries: 512.
<4>khelper used greatest stack depth: 7316 bytes left.
<6>NET: Registered protocol family 16.
...
...4 bytes left.
<6>PCI: Probing PCI hardware.
<7>PCI: Scanning bus 0...
...00:00:07.0.
<7>PCI: Calling quirk...
...CI: Found 0000:00:07.2 [1106/303...
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 19:25 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927191233.201980@gmx.net>
On Thu, Sep 27, 2007 at 09:12:33PM +0200, Gerhard Pircher wrote:
> Hi,
>
> I'm working on a 2.6.23 kernel for the AmigaOne.
[...]
> <6>PCI: Probing PCI hardware.
> <7>PCI: Scanning bus 0...
> ...00:00:07.0.
> <7>PCI: Calling quirk...
> ...CI: Found 0000:00:07.2 [1106/303...
Any chance that this thing has an e100 ethernet card in it?
If so, edit drivers/pci/quirks.c and ifdef out the readb()
in the e100_quirk routine.
We're debating the proper fix on the pci mailing list now.
--linas
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 19:31 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927192551.GK7970@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 14:25:51 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 09:12:33PM +0200, Gerhard Pircher wrote:
> > Hi,
> >
> > I'm working on a 2.6.23 kernel for the AmigaOne.
>
> [...]
>
> > <6>PCI: Probing PCI hardware.
> > <7>PCI: Scanning bus 0...
> > ...00:00:07.0.
> > <7>PCI: Calling quirk...
> > ...CI: Found 0000:00:07.2 [1106/303...
>
>
> Any chance that this thing has an e100 ethernet card in it?
> If so, edit drivers/pci/quirks.c and ifdef out the readb()
> in the e100_quirk routine.
No, it has a 3Com 3c905C/3c920 10/100Mbit controller.
Gerhard
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
^ permalink raw reply
* RE: [PATCH] Add platform support for the MPC837x RDB board
From: D'Abbraccio Joe-ljd015 @ 2007-09-27 19:41 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20070927191036.GD7838@mag.az.mvista.com>
Thanks for the advice, but I was just basing the list to post to on the
MAINTAINERS file which states that this is the one for Embedded PPC83XX.
If you still think that I should post to linuxppc-dev, let me know.
> -----Original Message-----
> From: Mark A. Greer [mailto:mgreer@mvista.com]=20
> Sent: Thursday, September 27, 2007 3:11 PM
> To: D'Abbraccio Joe-ljd015
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] Add platform support for the MPC837x RDB board
>=20
> On Thu, Sep 27, 2007 at 02:22:31PM -0400, ljd015@freescale.com wrote:
> > From: Joe D'Abbraccio <ljd015@freescale.com>
> >=20
> > The MPC837x RDB is a new member of the Freescale MPC83xx reference=20
> > design boards.
>=20
> FYI, if you have patches for arch/powerpc, I recommend that=20
> you submit them to linuxppc-dev. linuxppc-embedded is not=20
> monitored by many important people including paulus.
>=20
> Since these are 8xxx patches, chances are Kumar will see them=20
> and take them but you're still better off submitting to linuxppc-dev.
>=20
> Mark
>=20
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Mark A. Greer @ 2007-09-27 19:53 UTC (permalink / raw)
To: D'Abbraccio Joe-ljd015; +Cc: linuxppc-embedded
In-Reply-To: <C908B0B881A6B949985D6BAA0D9469B402CD36A7@az33exm20.fsl.freescale.net>
On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> Thanks for the advice, but I was just basing the list to post to on the
> MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> If you still think that I should post to linuxppc-dev, let me know.
Yes, I think it would be better to repost to linuxppc-dev.
Does anyone have an objection to changing all of the:
"L: linuxppc-embedded@ozlabs.org"
in MAINTAINERS to:
"L: linuxppc-dev@ozlabs.org" ??
Kumar, Josh, Vitaly, et. al.?
Mark
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Mark A. Greer @ 2007-09-27 19:10 UTC (permalink / raw)
To: ljd015; +Cc: linuxppc-embedded
In-Reply-To: <11909173512321-git-send-email-ljd015@freescale.com>
On Thu, Sep 27, 2007 at 02:22:31PM -0400, ljd015@freescale.com wrote:
> From: Joe D'Abbraccio <ljd015@freescale.com>
>
> The MPC837x RDB is a new member of the Freescale MPC83xx reference design
> boards.
FYI, if you have patches for arch/powerpc, I recommend that you submit
them to linuxppc-dev. linuxppc-embedded is not monitored by many
important people including paulus.
Since these are 8xxx patches, chances are Kumar will see them and take
them but you're still better off submitting to linuxppc-dev.
Mark
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Josh Boyer @ 2007-09-27 20:03 UTC (permalink / raw)
To: Mark A. Greer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927195351.GE7838@mag.az.mvista.com>
On Thu, 27 Sep 2007 12:53:51 -0700
"Mark A. Greer" <mgreer@mvista.com> wrote:
> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> > Thanks for the advice, but I was just basing the list to post to on the
> > MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> > If you still think that I should post to linuxppc-dev, let me know.
>
> Yes, I think it would be better to repost to linuxppc-dev.
>
> Does anyone have an objection to changing all of the:
>
> "L: linuxppc-embedded@ozlabs.org"
>
> in MAINTAINERS to:
>
> "L: linuxppc-dev@ozlabs.org" ??
>
> Kumar, Josh, Vitaly, et. al.?
I personally don't care either way. I'm already subscribed to both
lists.
Makes sense to go to linuxppc-dev given the arch/powerpc migration.
josh
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 20:50 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927193131.201920@gmx.net>
On Thu, Sep 27, 2007 at 09:31:31PM +0200, Gerhard Pircher wrote:
>
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> > >
> > > I'm working on a 2.6.23 kernel for the AmigaOne.
Have you tried 2.6.22, or does that fail also?
--linas
^ permalink raw reply
* Re: changing the EDLK components
From: Wolfgang Denk @ 2007-09-27 21:16 UTC (permalink / raw)
To: Murat Artun; +Cc: linuxppc-embedded
In-Reply-To: <4e5a3720709270734k54016e93h68ae6606d959cee9@mail.gmail.com>
In message <4e5a3720709270734k54016e93h68ae6606d959cee9@mail.gmail.com> you wrote:
>
> Specifically, I have followed the procedure in section "3.7.
> Rebuilding ELDK Components". First I have installed source RPMs and
> then rebuilt the binary target RPM. However, as I have followed the
> compiler messages I recognized that host gcc is called instead of
> cross gcc.
>
> Considering that my PATH was set following the advice in section "3.7.
> Rebuilding ELDK Components" as "<ELDK_root>/usr/ppc-linux/bin"
> directory is before "/usr/bin" what could be the problem?
If you really followed that advice then please explain how the native
gcc could be called at all because the cross compiler will always be
found first in the PATH?
I recommend checking the documentation again and following it step by
step.
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
"This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?"
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 21:17 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927205012.GN7970@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 15:50:12 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 09:31:31PM +0200, Gerhard Pircher wrote:
> >
> > > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> > > >
> > > > I'm working on a 2.6.23 kernel for the AmigaOne.
>
> Have you tried 2.6.22, or does that fail also?
>
> --linas
No, not yet. The last kernel that is working on the AmigaOne is a 2.6.16.x
kernel (still arch/ppc). All further kernels (2.6.17 and 2.6.18) that I
compiled with the old platform code for arch/ppc showed a similar
behavior. I hoped that this would only be a side effect of the ppc ->
powerpc transition. I also tried to search through the changelog files
to find an indication for the problem.
Do you have an idea how to debug it?
I guess it would be possible with a JTAG debugger, but the AmigaOne is
a desktop system and I don't know, if the JTAG pins of the CPU are
accessible on the board.
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Olof Johansson @ 2007-09-27 21:28 UTC (permalink / raw)
To: Josh Boyer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927150312.4eea96fd@weaponx.rchland.ibm.com>
On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
> On Thu, 27 Sep 2007 12:53:51 -0700
> "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> > On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> > > Thanks for the advice, but I was just basing the list to post to on the
> > > MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> > > If you still think that I should post to linuxppc-dev, let me know.
> >
> > Yes, I think it would be better to repost to linuxppc-dev.
> >
> > Does anyone have an objection to changing all of the:
> >
> > "L: linuxppc-embedded@ozlabs.org"
> >
> > in MAINTAINERS to:
> >
> > "L: linuxppc-dev@ozlabs.org" ??
> >
> > Kumar, Josh, Vitaly, et. al.?
>
> I personally don't care either way. I'm already subscribed to both
> lists.
>
> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
I thought the -embedded list was created in the first place to keep some
of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
my custom <embedded eval board>-lookalike board, HELP!"). If people still
care about keeping that on a separate list, then we shouldn't change it.
I think the relevant people probably monitor this list (maybe not quite as
frequently) to catch things. I even caught the first PWRficient-related
question in a timely manner the other day. :-)
Still, that being said, patches will clearly get better exposure on -dev,
especially device tree crap.
-Olof
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Kumar Gala @ 2007-09-27 21:31 UTC (permalink / raw)
To: Mark A. Greer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927195351.GE7838@mag.az.mvista.com>
On Sep 27, 2007, at 2:53 PM, Mark A. Greer wrote:
> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015
> wrote:
>> Thanks for the advice, but I was just basing the list to post to
>> on the
>> MAINTAINERS file which states that this is the one for Embedded
>> PPC83XX.
>> If you still think that I should post to linuxppc-dev, let me know.
>
> Yes, I think it would be better to repost to linuxppc-dev.
>
> Does anyone have an objection to changing all of the:
>
> "L: linuxppc-embedded@ozlabs.org"
>
> in MAINTAINERS to:
>
> "L: linuxppc-dev@ozlabs.org" ??
>
> Kumar, Josh, Vitaly, et. al.?
I'm all for it, but we should see about killing linuxppc-embedded and
just move everyone to linuxppc-dev.
- k
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 21:35 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927211700.201970@gmx.net>
On Thu, Sep 27, 2007 at 11:17:00PM +0200, Gerhard Pircher wrote:
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
>
> Do you have an idea how to debug it?
Not particularly. What caught my eye was the failure right near the
PCI quirk stuff, as I was having problems there as well (but apearntly,
for very different reasons). Based on your boot messages, it looks
like you are failing somewhere in pci probe. My olde-fashioned, slow,
but-usually-works method is to sprinkle enough printk's into the code
to catch it in the act.
--linas
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Kumar Gala @ 2007-09-27 21:40 UTC (permalink / raw)
To: ljd015; +Cc: linuxppc-embedded
In-Reply-To: <11909173512321-git-send-email-ljd015@freescale.com>
On Sep 27, 2007, at 1:22 PM, ljd015@freescale.com wrote:
> From: Joe D'Abbraccio <ljd015@freescale.com>
>
> The MPC837x RDB is a new member of the Freescale MPC83xx reference
> design
> boards.
>
> Signed-off-by: Joe D'Abbraccio <ljd015@freescale.com>
Please base your patch against an external tree (like my for-2.6.24
branch).
See comments inline.
- k
> ---
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 306 ++++++++++
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 286 +++++++++
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 281 +++++++++
> arch/powerpc/configs/mpc837x_rdb_defconfig | 886 +++++++++++++++++
> +++++++++++
> arch/powerpc/platforms/83xx/Kconfig | 8 +-
> arch/powerpc/platforms/83xx/Makefile | 1 +
> arch/powerpc/platforms/83xx/mpc837x_rdb.c | 102 ++++
> 7 files changed, 1869 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8377_rdb.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8378_rdb.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8379_rdb.dts
> create mode 100644 arch/powerpc/configs/mpc837x_rdb_defconfig
> create mode 100644 arch/powerpc/platforms/83xx/mpc837x_rdb.c
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/
> boot/dts/mpc8377_rdb.dts
> new file mode 100644
> index 0000000..1ee2a06
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
> @@ -0,0 +1,306 @@
> +/*
> + * MPC8377E RDB Device Tree Source
> + *
> + * Copyright 2005, 2006, 2007 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +/ {
> + model = "fsl,mpc8377erdb";
> + compatible = "fsl,mpc8377erdb","fsl,mpc837xrdb";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,837x@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>;
> + i-cache-line-size = <20>;
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 10000000>; // 256MB at 0
> + };
> +
> + soc837x@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 e0000000 00100000>;
> + reg = <e0000000 00000200>;
> + bus-frequency = <0>;
> +
> + wdt@200 {
> + device_type = "watchdog";
> + compatible = "mpc83xx_wdt";
> + reg = <200 100>;
> + };
> +
> + i2c@3000 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3000 100>;
> + interrupts = <e 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
> + };
> +
> + i2c@3100 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3100 100>;
> + interrupts = <f 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
> + };
> +
> + spi@7000 {
> + device_type = "spi";
> + compatible = "mpc83xx_spi";
> + reg = <7000 1000>;
> + interrupts = <10 8>;
> + interrupt-parent = < &ipic >;
> + mode = <0>;
> + };
> +
> + /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
> + usb@23000 {
> + device_type = "usb";
> + compatible = "fsl-usb2-dr";
> + reg = <23000 1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupt-parent = < &ipic >;
> + interrupts = <26 8>;
> + phy_type = "utmi_wide";
> + };
> +
> + mdio@24520 {
> + device_type = "mdio";
> + compatible = "gianfar";
> + reg = <24520 20>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy2: ethernet-phy@2 {
> + interrupt-parent = < &ipic >;
> + interrupts = <11 8>;
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
> + phy3: ethernet-phy@3 {
> + interrupt-parent = < &ipic >;
> + interrupts = <12 8>;
> + reg = <3>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + ethernet@24000 {
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <24000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <20 8 21 8 22 8>;
> + phy-connection-type = "mii";
> + interrupt-parent = < &ipic >;
> + phy-handle = < &phy2 >;
> + };
> +
> + ethernet@25000 {
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <25000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <23 8 24 8 25 8>;
> + phy-connection-type = "mii";
> + interrupt-parent = < &ipic >;
> + phy-handle = < &phy3 >;
> + };
> +
> + serial@4500 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4500 100>;
> + clock-frequency = <0>;
> + interrupts = <9 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + serial@4600 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4600 100>;
> + clock-frequency = <0>;
> + interrupts = <a 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + pci@9000 {
> + device_type = "pci";
> + compatible = "fsl,mpc83xx-pex";
> + reg = <9000 1000>;
> + interrupt-parent = < &ipic >;
> + interrupts = <1 8>;
> + phy-handle = < &serdes2 >;
> + };
> +
> + pci@a000 {
> + device_type = "pci";
> + compatible = "fsl,mpc83xx-pex";
> + reg = <a000 1000>;
> + interrupt-parent = < &ipic >;
> + interrupts = <2 8>;
> + phy-handle = < &serdes2 >;
> + };
> +
remove these pci nodes since we don't have kernel support for pex on
83xx.
> + crypto@30000 {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
> + reg = <30000 7000>;
> + interrupts = <b 8>;
> + interrupt-parent = < &ipic >;
> + /* Rev. 2.2 */
> + num-channels = <1>;
> + channel-fifo-len = <18>;
> + exec-units-mask = <0000004c>;
> + descriptor-types-mask = <0122003f>;
> + };
> +
> + sdhc@2e000 {
> + model = "eSDHC";
> + compatible = "fsl,esdhc";
> + reg = <2e000 1000>;
> + interrupts = <2a 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + sata@18000 {
> + device_type = "sata";
> + model = "SATA-300";
> + compatible = "fsl,sata300";
> + reg = <18000 1000>;
> + interrupts = <2c 8>;
> + interrupt-parent = < &ipic >;
> + phy-handle = < &serdes1 >;
> + };
> +
> + sata@19000 {
> + device_type = "sata";
> + model = "SATA-300";
> + compatible = "fsl,sata300";
> + reg = <19000 1000>;
> + interrupts = <2d 8>;
> + interrupt-parent = < &ipic >;
> + phy-handle = < &serdes1 >;
> + };
> +
> + serdes1:serdes@e3000 {
> + compatible = "fsl,serdes";
> + reg = <e3000 100>;
> + vdd-1v;
> + protocol = "sata";
> + clock = <d#100>;
> + };
> +
> + serdes2:serdes@e3100 {
> + model = "SerDes";
> + compatible = "fsl,serdes";
> + reg = <e3100 100>;
> + vdd-1v;
> + protocol = "pex";
> + clock = <d#100>;
> + };
remove sata, sdhc, and serdes until the device binding patches that
describe these are posted.
> +
> + /* IPIC
> + * interrupts cell = <intr #, sense>
> + * sense values match linux IORESOURCE_IRQ_* defines:
> + * sense == 8: Level, low assertion
> + * sense == 2: Edge, high-to-low change
> + */
> + ipic: pic@700 {
> + compatible = "fsl,ipic";
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <700 100>;
> + };
> + };
> +
> + pci@e0008500 {
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> +
> + /* IDSEL 0x11 */
> + 8800 0 0 1 &ipic 14 8
> + 8800 0 0 2 &ipic 15 8
> + 8800 0 0 3 &ipic 16 8
> + 8800 0 0 4 &ipic 17 8
> +
> + /* IDSEL 0x12 */
> + 9000 0 0 1 &ipic 16 8
> + 9000 0 0 2 &ipic 17 8
> + 9000 0 0 3 &ipic 14 8
> + 9000 0 0 4 &ipic 15 8
> +
> + /* IDSEL 0x13 */
> + 9800 0 0 1 &ipic 17 8
> + 9800 0 0 2 &ipic 14 8
> + 9800 0 0 3 &ipic 15 8
> + 9800 0 0 4 &ipic 16 8
> +
> + /* IDSEL 0x15 */
> + a800 0 0 1 &ipic 14 8
> + a800 0 0 2 &ipic 15 8
> + a800 0 0 3 &ipic 16 8
> + a800 0 0 4 &ipic 17 8
> +
> + /* IDSEL 0x16 */
> + b000 0 0 1 &ipic 17 8
> + b000 0 0 2 &ipic 14 8
> + b000 0 0 3 &ipic 15 8
> + b000 0 0 4 &ipic 16 8
> +
> + /* IDSEL 0x17 */
> + b800 0 0 1 &ipic 16 8
> + b800 0 0 2 &ipic 17 8
> + b800 0 0 3 &ipic 14 8
> + b800 0 0 4 &ipic 15 8
> +
> + /* IDSEL 0x18 */
> + c000 0 0 1 &ipic 15 8
> + c000 0 0 2 &ipic 16 8
> + c000 0 0 3 &ipic 17 8
> + c000 0 0 4 &ipic 14 8>;
> + interrupt-parent = < &ipic >;
> + interrupts = <42 8>;
> + bus-range = <0 0>;
> + ranges = <02000000 0 90000000 90000000 0 10000000
> + 42000000 0 80000000 80000000 0 10000000
> + 01000000 0 00000000 e2000000 0 00100000>;
> + clock-frequency = <0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <e0008500 100>;
> + compatible = "fsl,mpc83xx-pci", "83xx";
> + device_type = "pci";
> + };
> +};
(above comments apply to other .dts)
[snip]
> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> platforms/83xx/Kconfig
> index 0c61e7a..76a623b 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -55,6 +55,12 @@ config MPC837x_MDS
> select DEFAULT_UIMAGE
> help
> This option enables support for the MPC837x MDS Processor Board.
> +
> +config MPC837x_RDB
> + bool "Freescale MPC837x RDB"
> + select DEFAULT_UIMAGE
> + help
> + This option enables support for the MPC837x RDB Board.
> endchoice
>
> config PPC_MPC831x
> @@ -86,4 +92,4 @@ config PPC_MPC837x
> select PPC_UDBG_16550
> select PPC_INDIRECT_PCI
> select FSL_SERDES
FSL_SERDES doesn't exist in any tree at this point.
> - default y if MPC837x_MDS
> + default y if MPC837x_MDS || MPC837x_RDB
> diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/
> platforms/83xx/Makefile
> index df46629..d64c0ad 100644
> --- a/arch/powerpc/platforms/83xx/Makefile
> +++ b/arch/powerpc/platforms/83xx/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
> obj-$(CONFIG_MPC836x_MDS) += mpc836x_mds.o
> obj-$(CONFIG_MPC832x_MDS) += mpc832x_mds.o
> obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
> +obj-$(CONFIG_MPC837x_RDB) += mpc837x_rdb.o
This patch will not apply since 837x_MDS doesn't exist.
> diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c b/arch/
> powerpc/platforms/83xx/mpc837x_rdb.c
> new file mode 100644
> index 0000000..132438f
> --- /dev/null
> +++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
> @@ -0,0 +1,102 @@
> +/*
> + * arch/powerpc/platforms/83xx/mpc837x_rdb.c
> + *
> + * Copyright (C) 2007 Freescale Semicondutor, Inc. All rights
> reserved.
> + *
> + * MPC837x RDB board specific routines
> + *
> + * 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
> + * option) any later version.
> + */
> +
> +#include <linux/of_platform.h>
> +
> +#include <asm/time.h>
> +#include <asm/ipic.h>
> +#include <asm/udbg.h>
> +
> +#include "mpc83xx.h"
> +
> +#ifndef CONFIG_PCI
> +unsigned long isa_io_base;
> +unsigned long isa_mem_base;
> +#endif
> +
> +/*
> **********************************************************************
> **
> + *
> + * Setup the architecture
> + *
> + */
> +static void __init mpc837x_rdb_setup_arch(void)
> +{
> +#ifdef CONFIG_PCI
> + struct device_node *np;
> +#endif
> +
> + if (ppc_md.progress)
> + ppc_md.progress("mpc837x_rdb_setup_arch()", 0);
> +
> +#ifdef CONFIG_PCI
> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> + add_bridge(np);
This should be somethine like:
for_each_node_by_type(np, "pci")
if (of_device_is_compatible(np, "fsl,mpc83xx-pci"))
add_bridge(np);
> +#endif
> +}
> +
> +static struct of_device_id mpc837x_ids[] = {
> + { .type = "soc", },
> + { .compatible = "soc", },
> + {},
> +};
> +
> +static int __init mpc837x_declare_of_platform_devices(void)
> +{
> + if (!machine_is(mpc837x_rdb))
> + return 0;
> +
> + /* Publish of_device */
> + of_platform_bus_probe(NULL, mpc837x_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(mpc837x_declare_of_platform_devices);
> +
> +static void __init mpc837x_rdb_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
> +
> + /* Initialize the default interrupt mapping priorities,
> + * in case the boot rom changed something on us.
> + */
> + ipic_set_default_priority();
> +}
> +
> +
> +/*
> + * Called very early, MMU is off, device-tree isn't unflattened
> + */
> +static int __init mpc837x_rdb_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,mpc837xrdb");
> +}
> +
> +define_machine(mpc837x_rdb) {
> + .name = "MPC837x RDB",
> + .probe = mpc837x_rdb_probe,
> + .setup_arch = mpc837x_rdb_setup_arch,
> + .init_IRQ = mpc837x_rdb_init_IRQ,
> + .get_irq = ipic_get_irq,
> + .restart = mpc83xx_restart,
> + .time_init = mpc83xx_time_init,
> + .calibrate_decr = generic_calibrate_decr,
> + .progress = udbg_progress,
> +};
> --
> 1.5.2.2
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 21:57 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927213503.GA18686@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 16:35:03 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 11:17:00PM +0200, Gerhard Pircher wrote:
> > > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> >
> > Do you have an idea how to debug it?
>
> Not particularly. What caught my eye was the failure right near the
> PCI quirk stuff, as I was having problems there as well (but apearntly,
> for very different reasons).
Yes, I also suspect the PCI code. The AmigaOne has a VIA southbridge.
AFAIK there were some changes in the PCI quirks for VIA chipsets, but so
far I couldn't see any significant changes in the code.
> Based on your boot messages, it looks like you are failing somewhere in
> pci probe. My olde-fashioned, slow, but-usually-works method is to
> sprinkle enough printk's into the code to catch it in the act.
I guess the code in arch/powerpc/pci*.c is the right place to sprinkle
some printk's into the code?
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-09-27 22:00 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070926150216.GH3899@parisc-linux.org>
On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote:
> On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote:
> > Implement the so-called "first failure data capture" (FFDC) for the
> > symbios PCI error recovery. After a PCI error event is reported,
> > the driver requests that MMIO be enabled. Once enabled, it
> > then reads and dumps assorted status registers, and concludes
> > by requesting the usual reset sequence.
>
> > + /* Request that MMIO be enabled, so register dump can be taken. */
> > + return PCI_ERS_RESULT_CAN_RECOVER;
> > +}
>
> I'm a little concerned by the mention of MMIO. It's entirely possible
> for the sym2 driver to be using ioports to access the card rather than
> MMIO. Is it simply that it can't on the platform you test on?
The comment is misleading. I've been in the bad habit of calling
it "mmio" whenever its not DMA.
The habit is because there are two distinct enable bits in the
pci-host bridge during error recovery: one to enable mmio/ioports,
and the other to enable DMA. If the adapter has gone crazy, I don't
want to enable DMA, so that it doesn't scribble to bad places. But,
by enabling mmio/ioports, perhaps it can be finessed back into a
semi-sane state, e.g. sane enough to perform a dump of its internal
state.
--linas
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:08 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070927.202207.-1300525707.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 20:22 +0900, Ishizaki Kou wrote:
> Ben-san,
>
> > On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
> >
> > > Celleb does not set get_paca()->kstack properly (I don't know which
> > > function should set it up), so we need to workaround.
> >
> > paca->kstack is set in asm (via the PACAKSAVE macro), from either
> > __secondary_start for non-boot CPUs or from start_here_common for the
> > boot CPU.
> >
> > slb_flush_and_rebolt() should not be called before that happens.
> >
> > How do you end up with kstack set to 0 ?
>
> I found r13 is not set before entering start_here_common for boot cpu.
> For non-boot threads, __secondary_start will set r13 properly.
>
> So the problem is to set r13 correct PACA address before entering
> start_here_common. Should it set before entering kernel or will some
> patch make sense?
That is scary... we seem to have lost an mfsprg r13,SPRN_SPRG3 somewhere
along the way, I'm surprised things boot at all, or maybe I'm missing
something here... Paul ?
Ben.
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Matthew Wilcox @ 2007-09-27 22:10 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927220022.GC18686@austin.ibm.com>
On Thu, Sep 27, 2007 at 05:00:22PM -0500, Linas Vepstas wrote:
> On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote:
> > I'm a little concerned by the mention of MMIO. It's entirely possible
> > for the sym2 driver to be using ioports to access the card rather than
> > MMIO. Is it simply that it can't on the platform you test on?
>
> The comment is misleading. I've been in the bad habit of calling
> it "mmio" whenever its not DMA.
OK, cool, thanks. I'll update the comment for you.
One last thing (sorry, I only just noticed):
In the error handler, we wait_for_completion(io_reset_wait).
In sym2_io_error_detected, we init_completion(io_reset_wait).
Isn't it possible that we hit the error handler before we hit the
io_error_detected path, and thus the completion wait is lost?
Since the completion is already initialised in sym_attach(), I don't
think we need to initialise it in sym2_io_error_detected().
Makes sense to just delete it?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 22:20 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927215735.201960@gmx.net>
On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
>
> > Based on your boot messages, it looks like you are failing somewhere in
> > pci probe. My olde-fashioned, slow, but-usually-works method is to
> > sprinkle enough printk's into the code to catch it in the act.
> I guess the code in arch/powerpc/pci*.c is the right place to sprinkle
> some printk's into the code?
The last identifiable message I was
<7>PCI: Calling quirk...
which is from drivers/pci/quirks.c
...CI: Found 0000:00:07.2 [1106/303...
and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
to see if pci_setup_device() ever returned, and then I'd look to see
what happened next.
--linas
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:20 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070927.202207.-1300525707.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 20:22 +0900, Ishizaki Kou wrote:
> Ben-san,
>
> > On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
> >
> > > Celleb does not set get_paca()->kstack properly (I don't know which
> > > function should set it up), so we need to workaround.
> >
> > paca->kstack is set in asm (via the PACAKSAVE macro), from either
> > __secondary_start for non-boot CPUs or from start_here_common for the
> > boot CPU.
> >
> > slb_flush_and_rebolt() should not be called before that happens.
> >
> > How do you end up with kstack set to 0 ?
>
> I found r13 is not set before entering start_here_common for boot cpu.
> For non-boot threads, __secondary_start will set r13 properly.
>
> So the problem is to set r13 correct PACA address before entering
> start_here_common. Should it set before entering kernel or will some
> patch make sense?
It should have been set in setup_64.c, in setup_paca() (which is called
twice) in that statement:
local_paca = &paca[cpu];
As local_paca is defined as being a variable held in register r13. Maybe
something bad's happening with the compiler ?
Ben.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 22:27 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927222007.GE18686@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 17:20:07 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
>
> The last identifiable message I was
>
> <7>PCI: Calling quirk...
>
> which is from drivers/pci/quirks.c
>
> ...CI: Found 0000:00:07.2 [1106/303...
>
> and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
> to see if pci_setup_device() ever returned, and then I'd look to see
> what happened next.
Ah, I thought probing is done in the architecture's PCI code. I'll take
a look at pci_setup_device() function.
Thanks!
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:37 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190931617.6158.29.camel@pasglop>
> It should have been set in setup_64.c, in setup_paca() (which is called
> twice) in that statement:
>
> local_paca = &paca[cpu];
>
> As local_paca is defined as being a variable held in register r13. Maybe
> something bad's happening with the compiler ?
Can you check early_setup disassembly, see if r13 is assigned (it should
be in two spots) and if it's clobbered by the compiler somewhere ?
Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
makefile and let us know if it makes a difference... r13 is marked
reserved by the ABI but segher seems to imply that gcc may decide to ues
it anyway (ouch !)
Ben.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Benjamin Herrenschmidt @ 2007-09-27 22:39 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927222733.201970@gmx.net>
On Fri, 2007-09-28 at 00:27 +0200, Gerhard Pircher wrote:
> -------- Original-Nachricht --------
> > Datum: Thu, 27 Sep 2007 17:20:07 -0500
> > Von: linas@austin.ibm.com
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > CC: linuxppc-dev@ozlabs.org
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
>
> > On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
> >
> > The last identifiable message I was
> >
> > <7>PCI: Calling quirk...
> >
> > which is from drivers/pci/quirks.c
> >
> > ...CI: Found 0000:00:07.2 [1106/303...
> >
> > and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
> > to see if pci_setup_device() ever returned, and then I'd look to see
> > what happened next.
> Ah, I thought probing is done in the architecture's PCI code. I'll take
> a look at pci_setup_device() function.
It's one of the quirks I suppose. Those are often full of x86 only
bogoziness that hurts everybody else if you happen to hit them.
The "late" quirks are called at pci_enable_device() time.
Ben
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS board
From: Detlev Zundel @ 2007-09-27 15:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <12900017.post@talk.nabble.com>
Hi Nethra,
> The other options I am wondering about,
> -c, --cleanmarker=SIZE Size of cleanmarker (default 12)
> -n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock
> cleanmaker size will it help the cause?
Skimming through the thread I cannot tell whether you use NAND or NOR,
but on NAND flash, the cleanmarkers are actually in the out-of-band
area and thus *should not* be in the image, so for NAND we need the -n
option.
I don't think you should have to adjust the size, at least I never
needed this.
Best wishes
Detlev
--
I've been examining the existing [linux] kernel configuration system, and I
have about concluded that the best favor we could do everybody involved with
it is to take it out behind the barn and shoot it through the head.
-- Eric S. Raymond on linux-kbuild Mar 2000
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox