Re: device tree question
Ok, making progress on the ep8248 / devtrees, etc...
But I'm not getting any output on the serial and my log_buf is pretty
clean. Without console; what's the best way to figure out why I'm not
getting any output on my SMC1 serial port (using u-boot , not planetcore)?
-Alan
__log_buf:
Using Embedded Planet EP8248E machine description.
Linux version 2.6.23-rc6-g943401ab-dirty ([EMAIL PROTECTED]) (gcc version 3.4.5)
#3 Wed Sep 19 12:51:18 MDT 2007.
Entering add_active_range(0, 0, 32768) 0 entries of 256 used.
Top of RAM: 0x800, Total RAM: 0x800.
Memory hole size: 0MB.
Zone PFN ranges:.
DMA 0 ->32768.
Normal 32768 ->32768.
Movable zone start PFN for each node.
early_node_map[1] active PFN ranges.
0:0 ->32768.
On node 0 totalpages: 32768.
DMA zone: 256 pages used for memmap.
DMA zone: 0 pages reserved.
DMA zone: 32512 pages, LIFO batch:7.
Normal zone: 0 pages used for memmap.
Movable zone: 0 pages used for memmap.
Built 1 zonelists in Zone order. Total pages: 32512.
Kernel command line: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth1
nfsroot=192.168.10.5:/fh/rfs rw .
PID hash table entries: 512 (order: 9, 2048 bytes).
time_init: decrementer frequency = 16.50 MHz.
time_init: processor frequency = 231.00 MHz..
dts file:
/*
* Device Tree for the Embedded Planet EP8248E board.
*
* Copyright 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 = "EP8248E";
compatible = "fsl,ep8248e";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,[EMAIL PROTECTED] {
device_type = "cpu";
reg = <0>;
d-cache-line-size = ;
i-cache-line-size = ;
d-cache-size = ;
i-cache-size = ;
timebase-frequency = <0>;
clock-frequency = <0>;
};
};
CS: chipselect {
compatible = "fsl,ep8248e-chipselect",
"fsl,mpc8248-chipselect",
"fsl,pq2-chipselect";
#address-cells = <2>;
#size-cells = <1>;
fsl,ctrl = <&CSCTRL>;
ranges = <0 0 f800 07f0
0 1 fff0 0008
0 2 fff8 0008
1 0 e400 8000
2 0 d000 0800>;
/* F800_ -> FFF0_ */
[EMAIL PROTECTED],0 {
compatible = "cfi-flash";
reg = <0 0 7F0>;
probe-type = "CFI";
bank-width = <4>;
};
/* FFF0_ -> FFF7_ */
[EMAIL PROTECTED],1 {
device_type = "rom";
compatible = "direct-mapped";
reg = <0 0 8>;
probe-type = "CFI";
bank-width = <4>;
};
/* FFF8_ -> _ */
[EMAIL PROTECTED],2 {
compatible = "cfi-flash";
reg = <0 0 8>;
probe-type = "CFI";
bank-width = <4>;
};
/* F400_ */
[EMAIL PROTECTED],0 {
#address-cells = <2>;
#size-cells = <1>;
reg = <1 0 10>;
compatible = "fsl,ep8248e-bcsr";
ranges;
mdio {
device_type = "mdio";
compatible = "fsl,ep8248e-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
reg = <1 8 1>;
PHY0: [EMAIL PROTECTED] {
interrupt-parent = <&PIC>;
reg = <0>;
device_type = "ethernet-phy";
};
PHY1: [EMAIL PROTECTED] {
interrupt-parent = <&PIC>;
reg = <1>;
device_type = "ethernet-phy";
};
};
};
/* D000_ -> D7FF_ */
[EMAIL PR
Re: device tree question
Device Tree and BRG?
The SMC1 uses BRG7 and the SCC1 uses BRG1, should we have both BRGs
configured in the .dts? ( BRG1 is configured).
Device Tree and Chosen?
Adding a chosen block and I end up off in the weeds. removing the
chosen block and I die within cpm_uart_console_write
chosen {
linux,stdout-path = "/soc/cpm/[EMAIL PROTECTED]";
};
In arch/boot/ep8248e, there is a call to:
planetcore_set_stdout_path(table) is this why there is no
chosen/stdout-path element in the device tree?
Off to back out / replace the ep8248e + planetCore code to something
more u-boot friendly.
-Alan
__log_buf when hung with ~ cpm_uart_console_write
Using Embedded Planet EP8248E machine description.
Linux version 2.6.23-rc6-g943401ab-dirty ([EMAIL PROTECTED])
(gcc version 3.4.5) #8 Thu Sep 20 15:03:37 MDT 2007.
Entering add_active_range(0, 0, 32768) 0 entries of 256 used.
Top of RAM: 0x800, Total RAM: 0x800.
Memory hole size: 0MB.
Zone PFN ranges:.
DMA 0 ->32768.
Normal 32768 ->32768.
Movable zone start PFN for each node.
early_node_map[1] active PFN ranges.
0:0 ->32768.
On node 0 totalpages: 32768.
DMA zone: 256 pages used for memmap.
DMA zone: 0 pages reserved.
DMA zone: 32512 pages, LIFO batch:7.
Normal zone: 0 pages used for memmap.
Movable zone: 0 pages used for memmap.
Built 1 zonelists in Zone order. Total pages: 32512.
Kernel command line: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::
eth1 nfsroot=192.168.10.5:/fh/rfs rw .
PID hash table entries: 512 (order: 9, 2048 bytes).
time_init: decrementer frequency = 16.50 MHz.
time_init: processor frequency = 231.00 MHz.
console [ttyCPM0] enabled.
/*
* Device Tree for the Embedded Planet EP8248E board.
*
* Copyright 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 = "EP8248E";
compatible = "fsl,ep8248e";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,[EMAIL PROTECTED] {
device_type = "cpu";
reg = <0>;
d-cache-line-size = ;
i-cache-line-size = ;
d-cache-size = ;
i-cache-size = ;
timebase-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <0 0>;
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8248-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = ;
ranges = <0 0 f800 0800
2 0 e400 8000
4 0 d000 0800>;
/* CS0 F800_ -> _ */
[EMAIL PROTECTED],0 {
compatible = "cfi-flash";
reg = <0 0 0800>;
bank-width = <4>;
device-width = <2>;
};
/* CS2 E400_ -> E400_8000 */
[EMAIL PROTECTED],0 {
compatible = "fsl,ep8248e-bcsr";
reg = <2 0 10>;
#address-cells = <2>;
#size-cells = <1>;
ranges;
mdio {
device_type = "mdio";
compatible = "fsl,ep8248e-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
reg = <2 8 1>;
PHY0: [EMAIL PROTECTED] {
interrupt-parent = <&PIC>;
reg = <0>;
device_type = "ethernet-phy";
};
PHY1: [EMAIL PROTECTED] {
interrupt-parent = <&PIC>;
reg = <1>;
device_type = "ethernet-phy";
};
};
};
/* CS4 D000_ -> D7FF_ */
[EMAIL PROTECTED],0 {
compatible = "cfi-flash";
reg = <4 0 0800>;
bank-width = <4>;
Re: Problems compiling Linux for MPC8272ADS
I added this to my boot/Makefile near the other mcpu=440 lines. I
believe there may be a fix coming?
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=440
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
On 9/24/07, Manil Gaouar <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I am trying to compile the latest Linux from the git repos: git clone
> git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
> the code a few weeks ago and was able to build my uImage no problems. I
> did a git pull this morning and I can not compile anymore, here is the
> error message I have:
>
> BOOTCC arch/powerpc/boot/ps3.o
> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> {standard input}: Assembler messages:
> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
> make: *** [uImage] Error 2
>
> here are the commands I am using:
>
> make mrproper
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mpc8272_ads_defconfig
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage
>
> Do you have any ideas, or I should check out the 2.6.22 stable release
> instead and try again???
>
> Thx
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Console handover: tty0 instead of ttyCPM0?
Do you know what would cause this? I've configured a board to console off of SMC1 (ttyCPM0) and on 1 board it works fine, however a new revision of the board I get the following result and lose the console. Both boards have "exact" versions of the kernel and u-boot. BAD: console handover: boot [udbg0] -> real [tty0] GOOD: console handover: boot [udbg0] -> real [ttyCPM0] IMMRBASE is e000 CONFIG_PPC_EARLY_DEBUG_CPM=y CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xe888 doesn't WORK: == zImage starting: loaded at 0x0040 (sp: 0x07bc19a0) Allocating 0x309670 bytes for kernel ... gunzipping (0x <- 0x0040c000:0x00710448)...done 0x2f0ad4 bytes Linux/PowerPC load: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsroow Finalizing device tree... flat tree at 0x71e3a0 id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using Embedded Planet EP8248E machine description Linux version 2.6.23-rc6-VTM-0007-1763 ([EMAIL PROTECTED]) (gcc version 3.4.5) #5 Th7 console [udbg0] enabled setup_arch: bootmem ep8248_setup_arch() ep8248_setup_arch(), finish arch: exit Zone PFN ranges: DMA 0 ->32768 Normal 32768 ->32768 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 ->32768 Built 1 zonelists in Zone order. Total pages: 32512 Kernel command line: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsrow PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x25 console handover: boot [udbg0] -> real [tty0] BOARD THAT WORKS: == zImage starting: loaded at 0x0040 (sp: 0x07bc19a0) Allocating 0x309670 bytes for kernel ... gunzipping (0x <- 0x0040c000:0x00710448)...done 0x2f0ad4 bytes Linux/PowerPC load: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::25 Finalizing device tree... flat tree at 0x71e3a0 id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using Embedded Planet EP8248E machine description Linux version 2.6.23-rc6-VTM-0007-1763 ([EMAIL PROTECTED]) (gcc version 3.4.5) #5 Th7 console [udbg0] enabled setup_arch: bootmem ep8248_setup_arch() ep8248_setup_arch(), finish arch: exit Zone PFN ranges: DMA 0 ->32768 Normal 32768 ->32768 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 ->32768 Built 1 zonelists in Zone order. Total pages: 32512 Kernel command line: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::2 PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x25Dentry cache hash table entries: 16384 (order) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 126660k/131072k available (2852k kernel code, 4264k reserved, 132k data) Mount-cache hash table entries: 512 NET: Registered protocol family 16 Generic PHY: Registered new driver ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Serial init / BRG
For some reason I'm unable to track down the right sequence to
initialize my serial ports. (note: my console is working, but
attempts to initialize SCC1 and SCC4 fail). My console has the luxury
of having uboot initialize it and its brg, but SCC1 / SCC4 aren't so
lucky.
A few questions: To use 3 brgs, should I have 1 brg entry and X reg
values or three brg entries in my device tree? what are the third and
fourth reg values of the brg item in the device tree. I'll need 3
separate baud rates on the serial lines. Should I just add code to
initialize the brg's in u-boot or figure out how to get the kernel to
do it?
boot sequence
===
CPM UART serial mem=e0011a80 pram=e000
ttyCPM0 at MMIO 0xe0011a80 (irq = 16) is a CPM UART
CPM UART serial mem=e0011a00 pram=e0008000
CPM uart[1]:init_scc - sup = e0008000
ttyCPM1 at MMIO 0xe0011a00 (irq = 40) is a CPM UART
CPM UART serial mem=e0011a60 pram=e0008300
CPM uart[2]:init_scc - sup = e0008300
ttyCPM2 at MMIO 0xe0011a60 (irq = 43) is a CPM UART
BRG Values after above
=
brgc1: 0x
brgc2: 0x
brgc3: 0x
brgc4: 0x
brgc5: 0x
brgc6: 0x
brgc7: 0x0001004e
brgc8: 0x
Device Tree:
[EMAIL PROTECTED] {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
/* Monitor port/SMC1 */
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8248-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 20 0 40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d00>;
};
/* "Serial" port/SCC1 */
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0080>;
};
/* "Serial" port/SCC4 */
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a60 20 8300 100>;
interrupts = <2B 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0CE0>;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Describing devices in the device tree
I'm using a modified ep8248e.dts to describe my hardware and I want to
enable the use of 3 standard interrupts.
1. irq5
2. timer1
3. timer2
How bad does this look?
soc --> cpm -->
timer {
device_type = "timer";
compatible = "fsl,mpc8248-timer";
interrupts = ;
interrupt-parent = <&PIC>;
};
irq5 {
device_type = "irq5";
compatible = "fsl,mpc8248-irq5";
interrupts = <17 8>;
interrupt-parent = <&PIC>;
};
-Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Serial init / BRG
The lockup is only the shell. I echo from ttyCPM0 console and it "locks" then I echo from an ssh session and the kernel messages still output from the ttyCPM0 console. NOTE: I found a severe issue that seems to have unlocked ttyCPM2. BUT ttyCPM1 still hangs. (a while back, we commented out the out_be in cpm_setbrg - oops (console debug left over)) with address / value in cpm_setbrg echo test > /dev/ttyCPM1 # * note still hang * CPM uart[1]:startup - port->irq 0028 CPM uart[1]:startup - port->irq 40 cpm_setbrg:107 - brg:0 baud:9600 cpm_setbrg:108 - addr:e00119f0 value:00010140 echo test > /dev/ttyCPM2 * note doesn't hang * CPM uart[2]:startup - port->irq 002b CPM uart[2]:startup - port->irq 43 cpm_setbrg:107 - brg:3 baud:9600 cpm_setbrg:108 - addr:e00119fc value:00010140 On 10/16/07, Scott Wood <[EMAIL PROTECTED]> wrote: > Alan Bennett wrote: > > I also verified that when I attempt to echo to the ports that I reach > > the appropriate driver > > i.e. > > echo "hello" > /dev/ttyCPM1 > >CPM uart[1]:startup - port->irq 40 > > echo "hello" > /dev/ttyCPM2 > >CPM uart[2]:startup - port->irq 43 > > but brg's stay 0x0 and my shell's lock up something fierce. > > Hmm... try putting a debugging printk in cpm_setbrg with the address > and value it's writing. > > Is it just the shell that locks up, or the console (i.e. can you still > get kernel messages)? > > > (note: my tree is still based off of one you provided a few weeks > > back. have the 82xx / ep8248e changes we went through been pushed > > into linus' git tree?) > > It should all be in Linus's tree except the actual ep8248e file, which > didn't make it this time around due to interdependencies on netdev. > Note that there are some small device tree changes from the tree you're > currently using (in particular, muram is now in a node of its own). > > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Freescale Interrupt enabling
We were developing with Linux 2.6.10 and a Planetcore boot loader,
however, recent work has us up and running with 2.6.23+ and U-boot
1.2.0. However, we are now running into a few challenges regarding
the differences.
Our driver writer's code isn't functioning, but it was with 2.6.10 and
planet core. The best I can tell is that the default interrupt
controller configuration isn't where it was in the planetcore/2.6.10
version.
for example, let's look at enabling timer1 / interrupt number 12
simple description.
timer1 {
name = "timer1";
compatible = "fsl,mpc8248_timer";
interrupts = ;
interrupt-parent = <&PIC>;
What should be done to consume the above description in the device
tree, program the SIU and configure the irq for request? I'm looking
through the existing drivers to get a feel, but both the enets and the
uarts are overly complex for the simple task of enabling a timer, as
our driver code already works with the irq on other linux
kernels/bootloaders.
-Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
driver using device trees, irqs, powerpc
Need help adding new driver to supports a custom FPGA. Is there a good driver that anyone would recommend I can look at that is fully functional, works with 2.6.23 (powerpc style) and is described within a device tree? Bonus points: uses freescale interrupts (timers/irq's from mpc 82xx/etc...) isn't enet / cpm_uart (I've already looked at these) -Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
re: Linux root file system with X window support for a powerpc board
debian: (on x86/fedora development system) (used on 82xx) 1. debootstrap with the --foreign i.e. debootstrap --arch powerpc etch http://mirrors.kernel.org/debian mannually create an inittab, create/copy some default /dev entries 2. boot 74xx target with above root filesystem, run /debootstrap/debootstrap --second-stage Now add in packages using apt-get (or add them initially in step 1) -Alan Hi all Can anybody help me how to create a Linux root file system with X window support for a powerpc 74xx based board ? Any documents/links related to that is also welcome Thanks in advance R.Mahendravarman ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
request_irq fails to get interrupt 12
Freescale experts. Why on earth can't I request the IRQ for Timer1?
static int __init
dvr_ph_init(void)
{
u32 rv;
int k;
//rv = driver_register(&dvr_ph_driver);
for (k=0;k<64;k++) {
rv = request_irq(k,dvrph_isr , 0, "dvr_ph", NULL);
if (rv!=-38) printkplus("request_irq for %d returns %d", k,rv);
}
return rv;
}
Results in:
dvr_ph_init145 - enter the routine
dvr_ph_init155 -
dvr_ph_init161 - request_irq for 16 returns -16 (vector 16 = TMCNT)
dvr_ph_init161 - request_irq for 32 returns 0 (vector 32 = FCC1)
dvr_ph_init161 - request_irq for 33 returns -16 (vector 33 = FCC2)
dvr_ph_init161 - request_irq for 40 returns 0 (vector 40 = SCC1)
dvr_ph_init161 - request_irq for 43 returns 0 (vector 43 = SCC4)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: request_irq fails to get interrupt 12
Ok, so what does it take to expose an interrupt vector on a pq2 PIC??
-Alan
Current:
/
localbus{
...
fundevice1 {
interrupts = ;
interrupt-parent = <&PIC>;
};
...
[EMAIL PROTECTED] {
PIC: [EMAIL PROTECTED] {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8248-pic", "fsl,pq2-pic";
};
Is the above device tree enough on its own?
Do I have to write some platform code beyond:
static void __init ep8248_pic_init(void)
{
struct device_node *np = of_find_compatible_node(NULL, NULL,
"fsl,pq2-pic");
if (!np) {
printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
return;
}
cpm2_pic_init(np);
of_node_put(np);
}
-Alan
Hello,
> Freescale experts. Why on earth can't I request the IRQ for Timer1?
Please consule my question on [1] and the answers.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042061.html
bye
Silvio Fricke
--
-- S. Fricke - MAILTO:[EMAIL PROTECTED] --
Diplom-Informatiker (FH)
Linux-Entwicklung
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Continued serial headaches
Well, now that I've got IRQs requestable, I'm back to battling SCC1 / SCC4
initialization,
I've verified the iop structures, and things look set-up correctly.
/* SCC1 */
{2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{3, 31, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
/* SCC4 */
{3, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
I've also verified that upon first use (echo "test" > /dev/ttyCPM[12] the
brgs are configured)
SCC1
cpm_uart_startup:417
CPM uart[1]:startup on IRQ: 40 - request returned 0
cpm_uart_startup:432 CPM uart[1] is scc
CPM uart[1]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119f0:00010140
CPM uart[1]:shutdown
SCC4
cpm_uart_startup:417
CPM uart[2]:startup on IRQ: 43 - request returned 0
cpm_uart_startup:432 CPM uart[2] is scc
CPM uart[2]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119fc:00010140
CPM uart[2]:shutdown
CPM uart[2]:initbd
However, SCC1 continues to get locked.
Am I missing something in the PRAM areas?
SMC1 (ttyCPM0...)
e0008000 : 00c000e0 30300020 eefe3e7a
e0008010 : 00c07331 11b6b05f 3044 07f4d082
e0008020 : 00e3 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001
e0008040 : fc9d d08a
e0008050 : 80008000 80008000 80008000 80008000
SCC1
e0008000 : 00c000e0 30300020 eefe3e7a
e0008010 : 00c07331 11b6b05f 3044 07f4d082
e0008020 : 00e3 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001
e0008040 : fc9d d08a
e0008050 : 80008000 80008000 80008000 80008000
SCC4
e0008300 : 01000120 30300020 30401000 07f4e001
e0008310 : 011f 993fb24d 30004000 07f4e0a2
e0008320 : 0130 0d0a8379 fedddfdc 94a967eb
e0008330 : 5d2b06bd 4708b3ce 0020001f 0001
e0008340 : 2804 e8a6
e0008350 : 80008000 80008000 80008000 80008000
-Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
I2C on mpc8248 / device tree
I've got four devices on i2c that I need to read. Simple thermal and
voltage monitors. I2c works fine in uboot, and now I'm trying to get things
to work in linux.
In the kernel .config I enable
I2C
and
I2C_MPC
During the platform boot code:
I init the IO ports for i2c, (same as ep8248e code)
{3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
__Do I need to configure a brg for the i2c along with the other devices ?
i.e. cpm2_clk_setup ?
Next, I'm sure my device tree needs work, but my first stab adds i2c onto
the SOC @ 11860 (immr+11860= I2c mode register) and interrupt 1.
[EMAIL PROTECTED] {
...
[EMAIL PROTECTED] {
...
[EMAIL PROTECTED] {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <11860 18>;
interrupts = <1 3>;
interrupt-parent = <&PIC>;
};
After Cleaning up these routines and descriptions, would I be expected to
continue using the /dev/i2c- entries?
-Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C on mpc8248 / device tree
Does this patch support the cpm2 as well?
I get conflicting thoughts looking over the latest postings.
-Alan
On 11/13/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> I am working on a patch for i2c and device tree. I attached the current
> version.
>
> DTC entry looks like this.
>
> [EMAIL PROTECTED] {
> compatible =
> "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
>
> [EMAIL PROTECTED] {
> compatible = "epson,rtc8564";
> reg = <51>;
> };
> };
>
>
>
> --
> Jon Smirl
> [EMAIL PROTECTED]
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C on mpc8248 / device tree
ERk.
So if I needed to read values from four i2c devices (raw access would be
fine) and I need to get this working in a few days, how would you suggest I
proceed? Kernel = 2.6.23+.
Do I need to start from scratch?
Start by using Jon's patch (or are the 5200 i2c and the cpm2 i2c
completely incompatible?)
What about other cpm2/i2c threads - Did they ever complete?
1) On Wednesday, November 23, 2005 8:01 AM Kumar Gala wrote: >* Can we
rename the driver from mpc8260 -> cpm2. The driver should work* >* on any
device that has a "CPM2" which includes a number of MPC82xx* >* and MPC85xx
processors <http://osdir.com/ml/ports.ppc.devel/2005-11/msg00153.html#>. So
calling it and its config options, etc* >* MPC8260 is going to be confusing
to users.* [PATCH] I2C: Add I2C Bus support for MPC with CPM2.
On 11/14/07, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> The patch is orthogonal to your issue.
>
> There is NOT a driver in the kernel tree for the i2c on CPM2 based
> parts like the 8248 (from what I can tell).
>
> - k
>
> On Nov 14, 2007, at 9:31 AM, Alan Bennett wrote:
>
> > Does this patch support the cpm2 as well?
> >
> > I get conflicting thoughts looking over the latest postings.
> >
> > -Alan
> >
> >
> > On 11/13/07, Jon Smirl < [EMAIL PROTECTED]> wrote:I am working on
> > a patch for i2c and device tree. I attached the current version.
> >
> > DTC entry looks like this.
> >
> > [EMAIL PROTECTED] {
> > compatible = "mpc5200b-i2c","mpc5200-
> > i2c","fsl-i2c";
> > reg = <3d40 40>;
> > interrupts = <2 10 0>;
> > interrupt-parent = <&mpc5200_pic>;
> > fsl5200-clocking;
> >
> > [EMAIL PROTECTED] {
> > compatible = "epson,rtc8564";
> > reg = <51>;
> > };
> > };
> >
> >
> >
> > --
> > Jon Smirl
> > [EMAIL PROTECTED]
> >
> >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
kernel update on mpc8248 muram definition?
Hello;
While working on i2c support, I've decided to update to a new kernel. In
the process of doing this, I'm not sure I've properly configured the MURAM
node to my device tree (i.e. serial is broken again). Also, does this, in
any way, change the way I offset the early debug transmit descriptor
address?
I tried looking at your cpm tree on git.buserror.net, but it seems you've
taken it down?
-Alan
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8248", "fsl,pq2-soc";
ranges = < e000 00053000>;
// Temporary -- will go away once kernel uses ranges for
get_immrbase().
reg = ;
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8248-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 1>;
[EMAIL PROTECTED] {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
/* Monitor port/SMC1 */
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8248-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 20 0 40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d00>;
};
/* "Serial" port/SCC1 */
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0080>;
};
/* "Serial" port/SCC4 */
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a60 20 8300 100>;
interrupts = <2B 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0CE0>;
};
[EMAIL PROTECTED] {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100 11390 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
[EMAIL PROTECTED] {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <21 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <16200300>;
};
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8248-usb",
"fsl,cpm2-usb";
reg = <11b60 18 8b00 100>;
interrupt-parent = <&PIC>;
interrupts = ;
fsl,cpm-command = <2e60>;
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8248-i2c",
"fsl,cpm2-i2c",
"fsl,cpm-i2c";
reg = <11860 20 3c80 30>;
interrupts = <1>;
Configuration of i2c on 8248 (cpm2) help
I'm working to adapt some work by Jochen Friedrich to support CPM2 i2c
devices. It appears I have the bus loaded and think I am configuring
it properly, but my results tell me different. I see no messages when
I attach a i2c monitor after u-boot loads.
Can anyone spot what is going wrong based on the following information
and the resulting output? Does this look proper for a successful
configuration of the cpm2 i2c bus?
i2c-cpm: iip e0008afc, dp_addr 0x240
i2c-cpm: iic_tbase 576, iic_rbase 608
Any insight would be greatly appreciated.
-Alan
My Device tree entry:
[EMAIL PROTECTED] {
compatible = "fsl,mpc8248-i2c",
"fsl,cpm2-i2c",
"fsl,cpm-i2c";
reg = <11860 20 8afc 30>;
interrupts = <1 8>;
interrupt-parent = <&PIC>;
fsl,cpm-command = <2960>;
};
... and then later:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 1>;
[EMAIL PROTECTED] {
compatible = "fsl,cpm-muram-data";
reg = <80 1f80 9800 800>;
};
};
dump of 0xe0008afc (my immr_base=0xe000) at boot
e0008afc : 02600240 10100201
e0008b0c : 0260
e0008b1c : 0240 78c7ebaf bdefeab1
Probe debug results:
i2c-cpm: cpm_iic_init()
i2c-cpm: iip e0008afc, dp_addr 0x240
i2c-cpm: iic_tbase 576, iic_rbase 608
Log after modprobe:
modprobe i2c-dev
Jan 1 00:08:02 192 kernel: i2c /dev entries driver
Jan 1 00:08:02 192 kernel: i2c-core: driver [dev_driver] registered
Jan 1 00:08:02 192 kernel: i2c-dev: adapter [i2c-cpm] registered as minor 0
Log entries after trying an i2cset: (NOTE: sometimes it hangs doing this)
i2cset 0 0x41 0x1 0xff b
cpm_xfer:478
cpm_parse_message:329
kernel: i2c-adapter i2c-0: ioctl, cmd=0x720, arg=0xbfecaa0c
kernel: i2c-adapter i2c-0: master_xfer[0] W, addr=0x41, len2
kernel: cpm_xfer:478
kernel: i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
kernel: cpm_parse_message:329
kernel: i2c-adapter i2c-0: cpm_iic_write(abyte=0x82)
kernel: i2c-adapter i2c-0: tx sc 0 bc00
kernel: i2c-adapter i2c-0: test ready.
kernel: i2c-adapter i2c-0: not ready.
cpm_xfer:478
cpm_parse_message:329
cpm_parse_message:329
kernel: i2c-adapter i2c-0: force_close()
kernel: i2c-adapter i2c-0: IIC read: timeout!
kernel: i2c-adapter i2c-0: ioctl, cmd=0x720, arg=0xbfecaa0c
kernel: i2c-adapter i2c-0: master_xfer[0] W, addr=0x41, len1
kernel: i2c-adapter i2c-0: master_xfer[1] R, addr=0x41, len1
kernel: cpm_xfer:478
kernel: i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
kernel: cpm_parse_message:329
kernel: i2c-adapter i2c-0: cpm_iic_write(abyte=0x82)
kernel: i2c-adapter i2c-0: tx sc 0 9400
kernel: i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 1
kernel: cpm_parse_message:329
kernel: i2c-adapter i2c-0: cpm_iic_read(abyte=0x83)
kernel: i2c-adapter i2c-0: test ready.
kernel: i2c-adapter i2c-0: not ready.
kernel: i2c-adapter i2c-0: force_close()
kernel: i2c-adapter i2c-0: IIC read: timeout!
/*
* Freescale CPM1/CPM2 I2C interface.
* Copyright (c) 1999 Dan Malek ([EMAIL PROTECTED]).
*
* moved into proper i2c interface;
* Brad Parker ([EMAIL PROTECTED])
*
* (C) 2007 Montavista Software, Inc.
* Vitaly Bordug <[EMAIL PROTECTED]>
*
* RPX lite specific parts of the i2c interface
* Update: There actually isn't anything RPXLite-specific about this module.
* This should work for most any CPM board. The console messages have been
* changed to eliminate RPXLite references.
*
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.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* moved into proper i2c interface; separated out platform specific
* parts into i2c-8xx.c
* Brad Parker ([EMAIL PROTECTED])
*
* Parts from dbox2_i2c.c (cvs.tuxbox.org)
* (C) 2000-200
Timers on mpc8248 etc...
I've got a routine that needs to delay for X microseconds, this is a must. The command after schedule_timeout must has to wait for the HW to complete a task that takes X microseconds. I would think that one way to do this is with a simple schedule_timeout. But in the example below, the time that passes from run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its ~ 800 micros according the a analyzer looking at points triggered in run1() and donrun(). Could this be a configuration problem with the timer/interrupt that generates the jiffies? run1(); delaytime = 3280; set_current_state(TASK_UNINTERRUPTIBLE) ; schedule_timeout(usecs_to_jiffies(delaytime)); //1HZ = 1 second 1/1000 second = 1 milli dontrun(); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Timers on mpc8248 etc...
It comes from uboot. Can you point me in the right direction to make
sure its right?
PowerPC,[EMAIL PROTECTED] {
device_type = "cpu";
reg = <0>;
d-cache-line-size = ;
i-cache-line-size = ;
d-cache-size = ;
i-cache-size = ;
timebase-frequency = <0>;
clock-frequency = <0>;
};
On 11/28/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Alan Bennett wrote:
> > I've got a routine that needs to delay for X microseconds, this is a
> > must. The command after schedule_timeout must has to wait for the HW
> > to complete a task that takes X microseconds.
> >
> > I would think that one way to do this is with a simple
> > schedule_timeout. But in the example below, the time that passes from
> > run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its
> > ~ 800 micros according the a analyzer looking at points triggered in
> > run1() and donrun(). Could this be a configuration problem with the
> > timer/interrupt that generates the jiffies?
>
> Are you sure the timebase frequency is set correctly in the device tree?
>
> -Scott
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Timers on mpc8248 etc...
My uboot is new-ish, but I don't have the fdt commands? U-Boot 1.3.0
g992742a5-dirty
u-boot:clock configuration
===
MPC8248 Clock Configuration
- Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq 100-300
- dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 5, pcidf 5
- vco_out 39600, scc_clk 9900, brg_clk 2475
- cpu_clk 23100, cpm_clk 19800, bus_clk 6600
Boot Wrapper Reporting
===
Memory <- <0x0 0x800> (128MB)
CPU clock-frequency <- 0xdc4c7c0 (231MHz)
CPU timebase-frequency <- 0xfbc520 (17MHz)
CPU bus-frequency <- 0x3ef1480 (66MHz)
Kernel reporting
===
clocksource: timebase mult[f26c9b2] shift[22] registered
device tree in kernel (hex= `od -x`:
===
/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/name
PowerPC,8248
/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/bus-frequency
000 03ef 1480
/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/clock-frequency
000 0dc4 c7c0
/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/timebase-frequency
000 00fb c520
/proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/i-cache-size
000 4000
On 11/29/07, Vitaly Bordug <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007 21:06:36 -0700
> Alan Bennett wrote:
>
> > It comes from uboot. Can you point me in the right direction to make
> > sure its right?
> >PowerPC,[EMAIL PROTECTED] {
> >device_type = "cpu";
> >reg = <0>;
> >d-cache-line-size = ;
> >i-cache-line-size = ;
> >d-cache-size = ;
> >i-cache-size = ;
> >timebase-frequency = <0>;
> >clock-frequency = <0>;
> >};
> >
> if your u-boot is up to date, it will have fdt command, and by
> fdt boardsetup
> fdt print /
>
> inspect what u-boot did. Of course you should have dtb preloaded to memory and
> fdt addr should be said to let u-boot know where dtb resides.
>
>
> >
> > On 11/28/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > > Alan Bennett wrote:
> > > > I've got a routine that needs to delay for X microseconds, this
> > > > is a must. The command after schedule_timeout must has to wait
> > > > for the HW to complete a task that takes X microseconds.
> > > >
> > > > I would think that one way to do this is with a simple
> > > > schedule_timeout. But in the example below, the time that passes
> > > > from run1() to dontrun() is far less than 3.2 msecs. Infact,
> > > > sometimes its ~ 800 micros according the a analyzer looking at
> > > > points triggered in run1() and donrun(). Could this be a
> > > > configuration problem with the timer/interrupt that generates the
> > > > jiffies?
> > >
> > > Are you sure the timebase frequency is set correctly in the device
> > > tree?
> > >
> > > -Scott
> > >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
> --
> Sincerely, Vitaly
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Timers on mpc8248 etc...
Though I'd like to move to a uboot fdt, I can't afford to port it yet,
maybe in January. But until then ...
It appears that a simple change in U-boot constant,
#define CONFIG_8260_CLKIN6600/* in Hz */
to
#define CONFIG_8260_CLKIN1 /* in Hz */
has fixed the speed mismatch, and I've verified that
schedule_timeout(HZ/10) produces a 100 millisecond delay. However, my
serial ports (brgs) are hosed.
-Alan
On 11/29/07, Alan Bennett <[EMAIL PROTECTED]> wrote:
> My uboot is new-ish, but I don't have the fdt commands? U-Boot 1.3.0
> g992742a5-dirty
>
> u-boot:clock configuration
> ===
> MPC8248 Clock Configuration
> - Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq 100-300
> - dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 5, pcidf 5
> - vco_out 39600, scc_clk 9900, brg_clk 2475
> - cpu_clk 23100, cpm_clk 19800, bus_clk 6600
>
> Boot Wrapper Reporting
> ===
> Memory <- <0x0 0x800> (128MB)
> CPU clock-frequency <- 0xdc4c7c0 (231MHz)
> CPU timebase-frequency <- 0xfbc520 (17MHz)
> CPU bus-frequency <- 0x3ef1480 (66MHz)
>
> Kernel reporting
> ===
> clocksource: timebase mult[f26c9b2] shift[22] registered
>
> device tree in kernel (hex= `od -x`:
> ===
> /proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/name
> PowerPC,8248
> /proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/bus-frequency
> 000 03ef 1480
> /proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/clock-frequency
> 000 0dc4 c7c0
> /proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/timebase-frequency
> 000 00fb c520
> /proc/device-tree/cpus/PowerPC,[EMAIL PROTECTED]/i-cache-size
> 000 4000
>
>
>
> On 11/29/07, Vitaly Bordug <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Nov 2007 21:06:36 -0700
> > Alan Bennett wrote:
> >
> > > It comes from uboot. Can you point me in the right direction to make
> > > sure its right?
> > >PowerPC,[EMAIL PROTECTED] {
> > >device_type = "cpu";
> > >reg = <0>;
> > >d-cache-line-size = ;
> > >i-cache-line-size = ;
> > >d-cache-size = ;
> > >i-cache-size = ;
> > >timebase-frequency = <0>;
> > >clock-frequency = <0>;
> > >};
> > >
> > if your u-boot is up to date, it will have fdt command, and by
> > fdt boardsetup
> > fdt print /
> >
> > inspect what u-boot did. Of course you should have dtb preloaded to memory
> > and
> > fdt addr should be said to let u-boot know where dtb resides.
> >
> >
> > >
> > > On 11/28/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > > > Alan Bennett wrote:
> > > > > I've got a routine that needs to delay for X microseconds, this
> > > > > is a must. The command after schedule_timeout must has to wait
> > > > > for the HW to complete a task that takes X microseconds.
> > > > >
> > > > > I would think that one way to do this is with a simple
> > > > > schedule_timeout. But in the example below, the time that passes
> > > > > from run1() to dontrun() is far less than 3.2 msecs. Infact,
> > > > > sometimes its ~ 800 micros according the a analyzer looking at
> > > > > points triggered in run1() and donrun(). Could this be a
> > > > > configuration problem with the timer/interrupt that generates the
> > > > > jiffies?
> > > >
> > > > Are you sure the timebase frequency is set correctly in the device
> > > > tree?
> > > >
> > > > -Scott
> > > >
> > > ___
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> > --
> > Sincerely, Vitaly
> >
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
