Re: CONFIG_FEC is not good for mpc8xx ethernet?
Sorry for this delay response since I'm a bit busying recently:) No. Don't feel sorry about it. You're not obligated to answer any questions here. I believe it is the free and willing to help spirit that drive the open source community (linux particularly) to be such a success. We all benefit from and contribute to this. :) If you're sure that work well at the first time it may be issued from PIN. Are the PINs used to MDIO bus multiplexed? Maybe you miss something to re-configure PIN with the appropriate mode, OUT direction and some GPIO REGs to bind your PHY PINs. I means maybe other drivers also use same PINs and re-configure them, so they don't work properly as the first time. So you can try adding some codes to re-initial PINs as PHY expect on here to check this again. After the PIN assignment issue, the cause was simply an unnecessary reset in fs_init_phy() that was added in the beginning. And I forgot it. :-P Tiejun, Scott, many thanks to your kind help. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_FEC is not good for mpc8xx ethernet?
On MPC8xx you want drivers/net/fs_enet/mii-fec.c. This is just the
MDIO driver; it doesn't handle any particular PHY. I don't know if
there is a driver specifically for AM79C874, though the generic PHY
support may be good enough.
Maybe.
I can found one related patch for supporting PHY AM79C874 on 2.6.15,
--
http://lists.ozlabs.org/pipermail/linuxppc-embedded/2005-November/021043.html
But I don't see that on the latest kernel, and also I don't know the history
completely for that. Maybe its already merged into one generic PHY driver but
I'm not sure.
Thank Scott Tiejun for valuable information.
The problem for me is that the PHY failed to be probed. The related
error messages are shown below. I even tried the patch Tiejun pointed
out. But that doesn't help. The phy ID read from the bus was all Fs.
FEC MII Bus: probed
mdio_bus fa200e00: error probing PHY at address 0
I don't know if AM79C874 requires any special handling. But from the
comment in mdiobb_cmd() there seems to be something special.
/*
* Send a 32 bit preamble ('1's) with an extra '1' bit for good
* measure. The IEEE spec says this is a PHY optional
* requirement. The AMD 79C874 requires one after power up and
* one after a MII communications error. This means that we are
* doing more preambles than we need, but it is safer and will be
* much more robust.
*/
If there is any network action in u-boot, e.g., tftp or ping, the PHY
can be successfully probed after that. Any hints what went wrong with
the PHY?
Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_FEC is not good for mpc8xx ethernet?
The problem for me is that the PHY failed to be probed. The related error messages are shown below. I even tried the patch Tiejun pointed out. But that doesn't help. The phy ID read from the bus was all Fs. FEC MII Bus: probed mdio_bus fa200e00: error probing PHY at address 0 I think I figured out the probing failure. My board uses PortD bit8 as an input pin from phy's MDC. I didn't set up this pin assignment. When probing the PHY the fs_enet_fec_mii_read() is called to get phy id. The correct phy id was returned. However when I tried to set up the ip address using the command ifconfig eth0 192.168.0.4. The same function was called again. But this time the fecp-fec_r_cntrl mysteriously became 0 so the kernel reported bug for that. # ifconfig eth0 192.168.0.4 [ cut here ] kernel BUG at drivers/net/fs_enet/mii-fec.c:58! Oops: Exception in kernel mode, sig: 5 [#1] MyMPC870 NIP: c012b79c LR: c012963c CTR: c012b77c REGS: c7457c60 TRAP: 0700 Not tainted (2.6.33.5) MSR: 00029032 EE,ME,CE,IR,DR CR: 24020042 XER: 2000 TASK = c784[236] 'ifconfig' THREAD: c7456000 GPR00: 0001 c7457d10 c784 c7845400 0001 GPR08: c77c44fc c906ce00 c784806c 0b9f 84020042 100b986c 10096042 1009604f GPR16: 1009603b 10096030 10096001 100b188e c7457e18 8914 c742430c c740b000 GPR24: c7424300 c78443c0 0001 c7845428 c7845400 c7845600 c7845600 NIP [c012b79c] fs_enet_fec_mii_read+0x20/0x90 LR [c012963c] mdiobus_read+0x50/0x74 Call Trace: [c7457d10] [c0115744] driver_bound+0x60/0xa0 (unreliable) [c7457d30] [c0129094] genphy_config_init+0x24/0xd4 [c7457d40] [c0128920] phy_init_hw+0x4c/0x78 [c7457d50] [c0128a40] phy_connect_direct+0x24/0x88 [c7457d70] [c0133e50] of_phy_connect+0x48/0x6c [c7457d90] [c012ae10] fs_enet_open+0xf0/0x2cc [c7457db0] [c0148a54] dev_open+0x100/0x138 [c7457dd0] [c0146ca0] dev_change_flags+0x80/0x1a8 [c7457df0] [c018e104] devinet_ioctl+0x630/0x750 [c7457e60] [c018eb5c] inet_ioctl+0xcc/0xf8 [c7457e70] [c01370d8] sock_ioctl+0x60/0x28c [c7457e90] [c007dbcc] vfs_ioctl+0x38/0x9c [c7457ea0] [c007ddf0] do_vfs_ioctl+0x84/0x708 [c7457f10] [c007e4b4] sys_ioctl+0x40/0x74 [c7457f40] [c000de60] ret_from_syscall+0x0/0x38 Instruction dump: 80010014 7c0803a6 38210010 4e800020 81230018 8129 7c0004ac 80090144 0c00 4c00012c 6804 5400f7fe 0f00 5484b810 64846002 54a5925a ---[ end trace 41bf95259a68372e ]--- Trace/breakpoint trap I cannot find where the fec_r_cntrl would be reset to 0 after fs_enet_mdio_probe() sets it to FEC_RCNTRL_MII_MODE. Odd? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
CONFIG_FEC is not good for mpc8xx ethernet?
Hi, My target is a mpc875 based board and has FEC ethernet. The phy is AM79C874. I have the following configuration for the network support. CONFIG_PHYLIB=y CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_FS_ENET=y CONFIG_FS_ENET_HAS_FEC=y CONFIG_FS_ENET_MDIO_FEC=y However I found that the phy support (AM79C874) is actually in drivers/net/fec.c which is compiled only when CONFIG_FEC=y. However CONFIG_FEC is not on for mpc8xx targets, seen the dependency below. config FEC bool FEC ethernet controller (of ColdFire and some i.MX CPUs) depends on M523x || M527x || M5272 || M528x || M520x || M532x || MACH_MX27 || ARCH_MX35 || ARCH_MX25 help Say Y here if you want to use the built-in 10/100 Fast ethernet controller on some Motorola ColdFire and Freescale i.MX processors. Does it mean that the phy driver for AM79C874 doesn't exist for MPC8xx and I'll have to write one for myself? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [U-Boot] cuImage and multi image?
Can you paste the whole log from the u-boot prompt? In the previous run the ramdisk image was corrupted because the single image was loaded at 0x80. But the boot message showed that the initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB area. However after the load address was changed to 0x0400 (64MB), the ramdisk still seemed corrupted but with different error messages. = bootm ## Booting image at 0400 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 4424922 Bytes = 4.2 MB Load Address: 0040 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0040 (sp: 0x07d1cbd0) Allocating 0x22a1e1 bytes for kernel ... gunzipping (0x - 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes Attached initrd image at 0x0066c000-0x009ae825 initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x9bb300 Using my870 machine description Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #4 Tue Sep 21 09:23:51 PDT 2010 Found initrd at 0xc066c000:0xc09ae825 The following shows the boot message that the same kernel and the same ramdisk were loaded separately. The difference is that when boot from two separate images, the ramdisk is loaded to the top of RAM (0x79d9000-0x7d1b825). While when booting from the single image, the ramdisk is loaded to the place immediately after the uncompressed kernel image (0x0066c000-0x009ae825). I'm not familiar with how the kernel uses the memory. But it seems clear from this failure that the kernel overwrites to where the initrd locates. Anyone can shed some light on why the kernel would overwrite the initrd area? BTW, if the initrd is small enough, the single image method works well. Maybe we should have relocated the initrd to the top of available ram just like u-boot's bootm? = bootm 100 200 ## Booting image at 0100 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1040228 Bytes = 1015.8 kB Load Address: 0040 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0200 ... Image Name: 16MB Ramdisk Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:3418149 Bytes = 3.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 079d9000, end 07d1b825 ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0040 (sp: 0x07d1cbd0) Allocating 0x22a1e1 bytes for kernel ... gunzipping (0x - 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes Using loader supplied ramdisk at 0x79d9000-0x7d1b825 initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x678300 Using my870 machine description Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #4 Tue Sep 21 09:23:51 PDT 2010 Found initrd at 0xc79d9000:0xc7d1b825 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [U-Boot] cuImage and multi image?
I have a large ramdisk image. The size of the image itself (i.e. the
*.gz) is about 4MB. When the ramdisk was being decompressed
Did you try to change link_address on the file, arch/powerpc/boot/wrapper?
No. I don't have to. Right? The link_address is still 0x40.
Did you try boot the uImage and the ramdisk separately? For example, you can
boot this as the following command:
# bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}
Mine is a cuImage. I'm pretty sure that my ramdisk is valid when it's
a separate image. I used bootm kernel_addr ramdisk_addr to boot.
Can you paste the whole log from the u-boot prompt?
In the previous run the ramdisk image was corrupted because the single
image was loaded at 0x80. But the boot message showed that the
initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB
area.
However after the load address was changed to 0x0400 (64MB), the
ramdisk still seemed corrupted but with different error messages.
= bootm
## Booting image at 0400 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:4424922 Bytes = 4.2 MB
Load Address: 0040
Entry Point: 00400554
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory - 0x0 0x800 (128MB)
ENET0: local-mac-address - 00:09:9b:01:58:64
CPU clock-frequency - 0x7270e00 (120MHz)
CPU timebase-frequency - 0x7270e0 (8MHz)
CPU bus-frequency - 0x3938700 (60MHz)
zImage starting: loaded at 0x0040 (sp: 0x07d1cbd0)
Allocating 0x22a1e1 bytes for kernel ...
gunzipping (0x - 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes
Attached initrd image at 0x0066c000-0x009ae825
initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0x9bb300
Using my870 machine description
Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #4 Tue Sep
21 09:23:51 PDT 2010
Found initrd at 0xc066c000:0xc09ae825
Zone PFN ranges:
DMA 0x - 0x8000
Normal 0x8000 - 0x8000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x - 0x8000
MMU: Allocated 72 bytes of context maps for 16 contexts
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: root=/dev/ram
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 124072k/131072k available (2080k kernel code, 6836k reserved,
84k data, 52k bss, 104k init)
Kernel virtual memory layout:
* 0xfffdf000..0xf000 : fixmap
* 0xfde0..0xfe00 : consistent mem
* 0xfddfa000..0xfde0 : early ioremap
* 0xc900..0xfddfa000 : vmalloc ioremap
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
snipped
RAMDISK: gzip image found at block 0
uncompression error
VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
Freeing unused kernel memory: 104k init
EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: :
unaligned directory entry - offset=0, inode=74187384, rec_len=2081,
name_len=126
EXT2-fs (ram0): error: remounting filesystem read-only
attempt to access beyond end of device
ram0: rw=0, want=156831968, limit=32768
Buffer I/O error on device ram0, logical block 78415983
attempt to access beyond end of device
ram0: rw=0, want=112233212, limit=32768
Buffer I/O error on device ram0, logical block 56116605
attempt to access beyond end of device
ram0: rw=0, want=6626681482, limit=32768
Buffer I/O error on device ram0, logical block 3313340740
attempt to access beyond end of device
ram0: rw=0, want=184684282, limit=32768
Buffer I/O error on device ram0, logical block 92342140
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Call Trace:
[c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable)
[c7821f70] [c001cefc] panic+0x8c/0x178
[c7821fc0] [c00026d4] init_post+0xe4/0xf4
[c7821fd0] [c01ee224] kernel_init+0x108/0x130
[c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..
Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [U-Boot] cuImage and multi image?
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)? No. Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage). Unless you're talking about the (uncompressed)? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself. He should point the latter, the total image size, including ramdisk. But the link address should be limited for the boot Image, not for the attached ramdisk. Thanks for the clarification. Scott, so what are the things that the bootwrapper is decompressing? The kernel for sure. And anything else? I understand that the ramdisk image will be decompressed later when trying to boot it. I have a large ramdisk image. The size of the image itself (i.e. the *.gz) is about 4MB. When the ramdisk was being decompressed in the later stage. It had the following errors. It seems to me that the ramdisk image somehow was corrupted. Did the script wrapper mess up the image? Is there any known bug in the wrapper? My kernel is 2.6.33. BTW the ramdisk image can be mounted properly if it's separated from the kernel image. RAMDISK: gzip image found at block 0 uncompression error VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 104k init EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: : rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 EXT2-fs (ram0): error: remounting filesystem read-only Kernel panic - not syncing: No init found. Try passing init= option to kernel. Call Trace: [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable) [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4] init_post+0xe4/0xf4 [c7821fd0] [c01ee224] kernel_init+0x108/0x130 [c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68 Rebooting in 180 seconds.. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cuImage and multi image?
I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are separate and bootm $kernel $ramdisk is used. But I can not make it to work using a single multi image that contains the kernel and ramdisk images. Is it even technically possible to boot a multi-image with cuboot wrapper? Try the following steps: -- 1. cp your ramdisk.gz arch/powerpc/boot/ramdisk.image.gz 2. make cuImage.initrd.your target You can get one Image, cuImage.initrd.your target, including kernel and ramdisk. A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
cuImage and multi image?
Hi, I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are separate and bootm $kernel $ramdisk is used. But I can not make it to work using a single multi image that contains the kernel and ramdisk images. Is it even technically possible to boot a multi-image with cuboot wrapper? On the cuImage kernel I have load address set to 0x40 and the entry address set to 0x400554 due to the cuboot wrapper. But to make a multi image, both the load and the entry addresses should be set to zero. And u-boot (1.1.2) bootm takes the entry address of the multi image (i.e. 0x0) as the kernel entry address. 0x0 is certainly not the entry address for a cuImage kernel. Is there a possible workaround other than using two separate images? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cuImage and multi image?
Try the following steps: -- 1. cp your ramdisk.gz arch/powerpc/boot/ramdisk.image.gz 2. make cuImage.initrd.your target You can get one Image, cuImage.initrd.your target, including kernel and ramdisk. Cool! Thanks a lot, Tiejun. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to build the kernel without any optimization?
I already added the following to arch/powerpc/Makefile. # Prevent GDB from jumping around in the code when trying to single step ifeq ($(CONFIG_DEBUG_KERNEL),y) KBUILD_CFLAGS += -fno-schedule-insns -fno-schedule-insns2 endif much of the kernel can not be build without optimization - what you can do though is slectively try to disable optimization for specific files by putting CFLAGS_REMOVE_objfilenam.o = -SOME_OPT in the Makefile. I think that is safer than what you did above as this would always depend on the order of options that ultimately get passed to gcc. With this CLAGS_REMOVE, building the objfilenam.o uses only the -SOME_OPT instead of the default CFLAGS defined? The most I found for -SOME_OPT is the -pg. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
How to build the kernel without any optimization?
Hi, I'm tracing the execution of ds1307_probe() and find that some of variables or function arguments cannot be printed in gdb because they are optimized out or not in the current context. This really gives some headache. Is there a way to build the kernel without any optimization? What gcc option shall I disable or add? I already added the following to arch/powerpc/Makefile. # Prevent GDB from jumping around in the code when trying to single step ifeq ($(CONFIG_DEBUG_KERNEL),y) KBUILD_CFLAGS += -fno-schedule-insns -fno-schedule-insns2 endif Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
mpc8xx microcode patch?
Hi, The kernel supports three microcode patch: USB_SOF_UCODE_PATCH, I2C_SPI_UCODE_PATCH, and I2C_SPI_SMC1_UCODE_PATCH. However from the mpc8xxmc01.zip downloaded from freescale website, there are 4 combinations of microcode (I2C/SPI, SMC/SPI, SMC/I2C, and SMC). Also in the EB662.pdf it's mentioned that SMC relocation patch is applicable to all MPC8xx families and revisions. Surprisingly the SMC only relocation patch cannot be found in the kernel. My processor is MPC870 and I'm not sure what ucode patch I shall apply. What am I missing here? This EB662.pdf was published in Jan. 2006. It's hard to believe that the kernel hasn't incorporate what needs to be done. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
cpm_i2c: write OK but read fail
Hi, My system is MPC870 based and I'm enabling the I2C driver and the ds1339 RTC driver. When the kernel tries to probe the RTC chip (slave address 0x68), the first write seems OK but the subsequent read times out. I applied the I2C/SPI microcode patch, which doesn't seem necessary though. Below is the dmesg output and all I2C debug messages are enabled. i2c-core: driver [rtc-ds1307] registered i2c /dev entries driver i2c-core: driver [dev_driver] registered fsl-i2c-cpm fa200860.i2c: cpm_i2c_setup() alloc irq_desc for 21 on node 0 alloc kstat_irqs on node 0 irq: irq 16 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 21 fsl-i2c-cpm fa200860.i2c: i2c_ram 0xfddfa400, i2c_addr 0x0400, freq 6 fsl-i2c-cpm fa200860.i2c: tbase 0x0340, rbase 0x0360 i2c i2c-0: adapter [i2c-cpm] registered i2c-dev: adapter [i2c-cpm] registered as minor 0 fsl-i2c-cpm fa200860.i2c: hw routines for i2c-cpm registered. i2c 0-0068: uevent rtc-ds1307 0-0068: probe i2c i2c-0: master_xfer[0] W, addr=0x68, len=1 i2c i2c-0: master_xfer[1] R, addr=0x68, len=2 i2c i2c-0: R: 0 T: 0 i2c i2c-0: cpm_i2c_write(abyte=0xd0) i2c i2c-0: R: 0 T: 1 i2c i2c-0: cpm_i2c_read(abyte=0xd1) ^ The above shows there were two transfers being built (one write, one read). i2c i2c-0: test ready. i2c i2c-0: Interrupt: 2 i2c i2c-0: ready. i2c i2c-0: tx sc 0 0x1400 ^^^ This shows the write command went through successfully. i2c i2c-0: test ready. i2c i2c-0: I2C transfer: timeout ^ However the read timed out. :( i2c i2c-0: cpm_i2c_force_close() rtc-ds1307: probe of 0-0068 failed with error -5 i2c i2c-0: client [ds1339] registered with bus id 0-0068 The Tx/Rx BDs are dumped below. fa202340 : 1402 07b51000 ac03 07b53000 ..0. fa202350 : 9fc3f137 07b55000 9739a1d0 07b4f000 ...7..P..9.. fa202360 : 9000 07b5 b68fa19d 07b52000 .. . fa202370 : 1b85e6cc 07b54000 49df3090 07b4e000 ..@.i.0. What went wrong with read? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
kernel 2.6.33 fail to mount rootfs on ramdisk
Hi, The kernel 2.6.33 failed to mount the rootfs on the ramdisk. I enabled the ramdisk block device support and ext2 filesystem as shown below. CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_EXT2_FS=y Are these adequate configurations for kernel to support rootfs on ramdisk? What have I missed? The ramdisk image is from DENX's SELF. The boot message is shown below. = bootm 100 200 ## Booting image at 0100 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1070272 Bytes = 1 MB Load Address: 0040 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0200 ... Image Name: Simple Embedded Linux Framework Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:1459535 Bytes = 1.4 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 07bb7000, end 07d1b54f ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0040 (sp: 0x07d1cbd0) Allocating 0x23f554 bytes for kernel ... gunzipping (0x - 0x0040c000:0x0067d01c)...done 0x22e6ec bytes Using loader supplied ramdisk at 0x7bb7000-0x7d1b54f initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x68a300 ... NET: Registered protocol family 17 List of all partitions: No filesystem could mount root, tried: ext2 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Call Trace: [c781fed0] [c0006ce0] show_stack+0x40/0x168 (unreliable) [c781ff10] [c001cc5c] panic+0x8c/0x178 [c781ff60] [c0201dc0] mount_block_root+0x1d4/0x244 [c781ffb0] [c0201fa4] prepare_namespace+0x64/0x210 [c781ffd0] [c0201220] kernel_init+0x104/0x130 [c781fff0] [c000dcc8] kernel_thread+0x4c/0x68 Rebooting in 180 seconds.. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel 2.6.33 fail to mount rootfs on ramdisk
On Tue, Aug 10, 2010 at 11:55 PM, Shawn Jin shawnx...@gmail.com wrote: Hi, The kernel 2.6.33 failed to mount the rootfs on the ramdisk. I enabled the ramdisk block device support and ext2 filesystem as shown below. CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_EXT2_FS=y Are these adequate configurations for kernel to support rootfs on ramdisk? What have I missed? The ramdisk image is from DENX's SELF. The boot message is shown below. I figured that out. What I missed is CONFIG_BLK_DEV_INITRD. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc870: hctosys.c unable to open rtc device rtc0
Thanks Scott for the confirmation. I added that to my dts file and the driver did try to probe the device. But accessing the device timed out. There are some microcode patches related to I2C that I've not applied. I'll try the patch(es) later. But how can I find out which patch should be applied to my MPC870? :(, the I2C_SPI patch doesn't do any help. It still gets timeout when probing the device. The slave address of DS1339 is 0x68. Here are the debug messages. Before hooking up the oscilloscope, any quick hints for me to try? The 2.4 kernel worked OK, BTW. i2c-core: driver [rtc-ds1307] registered i2c /dev entries driver i2c-core: driver [dev_driver] registered fsl-i2c-cpm fa200860.i2c: cpm_i2c_setup() alloc irq_desc for 21 on node 0 alloc kstat_irqs on node 0 irq: irq 16 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 21 fsl-i2c-cpm fa200860.i2c: i2c_ram 0xfddfa500, i2c_addr 0x0500, freq 6 fsl-i2c-cpm fa200860.i2c: tbase 0x0340, rbase 0x0360 i2c i2c-0: adapter [i2c-cpm] registered i2c-dev: adapter [i2c-cpm] registered as minor 0 fsl-i2c-cpm fa200860.i2c: hw routines for i2c-cpm registered. i2c 0-0068: uevent rtc-ds1307 0-0068: probe i2c i2c-0: master_xfer[0] W, addr=0x68, len=1 i2c i2c-0: master_xfer[1] R, addr=0x68, len=2 i2c i2c-0: R: 0 T: 0 i2c i2c-0: cpm_i2c_write(abyte=0xd0) i2c i2c-0: R: 0 T: 1 i2c i2c-0: cpm_i2c_read(abyte=0xd1) i2c i2c-0: test ready. i2c i2c-0: Interrupt: 2 i2c i2c-0: ready. i2c i2c-0: tx sc 0 0x1400 i2c i2c-0: test ready. i2c i2c-0: I2C transfer: timeout i2c i2c-0: cpm_i2c_force_close() rtc-ds1307: probe of 0-0068 failed with error -5 i2c i2c-0: client [ds1339] registered with bus id 0-0068 i2c-core: driver [lm75] registered TCP cubic registered NET: Registered protocol family 17 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Freeing unused kernel memory: 1512k init Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
mpc870: hctosys.c unable to open rtc device rtc0
A DS1339 RTC is connected to the I2C bus (i2c-cpm in mpc870). The
dmesg below shows that the ds1037 driver was registered. But the
hctosys.c was not able to open the rtc device rtc0. The rtc doesn't
seem to be connected with I2C driver properly.
i2c-core: driver [rtc-ds1307] registered
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
fsl-i2c-cpm fa200860.i2c: cpm_i2c_setup()
alloc irq_desc for 21 on node 0
alloc kstat_irqs on node 0
irq: irq 16 on host /s...@fa20/c...@9c0/interrupt-control...@930
mapped to virtual irq 21
fsl-i2c-cpm fa200860.i2c: i2c_ram 0xfddfbc80, i2c_addr 0x1c80, freq 6
fsl-i2c-cpm fa200860.i2c: tbase 0x0340, rbase 0x0360
i2c i2c-0: adapter [i2c-cpm] registered
i2c-dev: adapter [i2c-cpm] registered as minor 0
fsl-i2c-cpm fa200860.i2c: hw routines for i2c-cpm registered.
i2c-core: driver [lm75] registered
TCP cubic registered
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
My I2C settings in the dts is as follows, same as the mpc885ads.
i...@860 {
compatible = fsl,mpc885-i2c,
fsl,cpm1-i2c;
reg = 0x860 0x20 0x3c80 0x30;
interrupts = 16;
interrupt-parent = CPM_PIC;
fsl,cpm-command = 0x10;
#address-cells = 1;
#size-cells = 0;
};
Reading the fsl i2c bindings in the documentation, I found an example
as follows.
27 i...@860 {
28compatible = fsl,mpc823-i2c,
29 fsl,cpm1-i2c;
30reg = 0x860 0x20 0x3c80 0x30;
31interrupts = 16;
32interrupt-parent = CPM_PIC;
33fsl,cpm-command = 0x10;
34#address-cells = 1;
35#size-cells = 0;
36
37r...@68 {
38compatible = dallas,ds1307;
39reg = 0x68;
40};
41};
42
In the above example the rtc was explicitly declared as a subnode of
the i2c node. Is this the way to connect (or bind) a RTC to the I2C
driver? If not how is an RTC driver (or hwmon driver) bound to the I2C
driver? What is the reg (0x68) under rtc node?
I set breakpoint at ds1037_probe() and was hoping that it might be hit
during the driver registration. But it didn't. Would the
ds1037_probe() be called during when the ds1037_driver was registered
as an I2C driver?
Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc870: hctosys.c unable to open rtc device rtc0
Reading the fsl i2c bindings in the documentation, I found an example
as follows.
27 ...@860 {
28 compatible = fsl,mpc823-i2c,
29 fsl,cpm1-i2c;
30 reg = 0x860 0x20 0x3c80 0x30;
31 interrupts = 16;
32 interrupt-parent = CPM_PIC;
33 fsl,cpm-command = 0x10;
34 #address-cells = 1;
35 #size-cells = 0;
36
37 ...@68 {
38 compatible = dallas,ds1307;
39 reg = 0x68;
40 };
41 };
42
In the above example the rtc was explicitly declared as a subnode of
the i2c node. Is this the way to connect (or bind) a RTC to the I2C
driver?
Yes.
Thanks Scott for the confirmation. I added that to my dts file and the
driver did try to probe the device. But accessing the device timed
out. There are some microcode patches related to I2C that I've not
applied. I'll try the patch(es) later. But how can I find out which
patch should be applied to my MPC870?
Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Relocating bootwrapper causes kernel panic
I think the cause is clear now. But how to fix it? Two questions: 2. If the DTLB miss exception handler is not the right guy to load a proper TLB entry, how can I set one entry based on the link_address and the address of the flat dt blob? Given how early in the boot process it is, it's probably going to need to be handled specially. What APIs can I use to set up DTLBs? I don't think there is one that works on 8xx. You'll could hack up initial_mmu, or else write some C code to insert an 8xx TLB entry. Yup, I think he just ends up getting out of the initial mapping which is smallish on 8xx, no ? Might be worth sticking in one more entry during boot... If CONFIG_PIN_TLB is on, two more entries are pinned down, which gives 16MB mappings. Just curious. Why is there only one entry by default? what's the trade-off to pin down all 4 entries? THanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Relocating bootwrapper causes kernel panic
The flat tree located at 0xbe4300 as the kerne message showed. Why cannot the kernel access this area? No TLB set for this area? 1Unable to handle kernel paging request for data at address 0xc0be4308 1Faulting instruction address: 0xc01fdabc 4Oops: Kernel access of bad area, sig: 11 [#1] Before the flat tree was accessed, I checked the DTLB and didn't find any entry related to 0xc0be4300. After the exception, I found the following DTLBs. 30 : 02 c0be4000 4KB -- - 31 : 00 fa00 8MB VI-S-M - fa00 The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this should be something like 00be4000? When the early_debug is enabled, the kernel can boot successfully. I checked the TLB settings and found the following. 28 : 00 c000 8MB V--S-M - 29 : 00 fa00 8MB VI-S-M - fa00 30 : 00 c080 8MB V--S-M - 0080 31 : 14 04919000 ?KB V---WM - 00e45000 So the kernel can access the dtb at 0xbe4300 because of the pinned down DTLB#30. I think the cause is clear now. But how to fix it? Two questions: 1. Should this DTLB miss exception properly set a new TLB entry for the new dtb address 0xbe4300? 2. If the DTLB miss exception handler is not the right guy to load a proper TLB entry, how can I set one entry based on the link_address and the address of the flat dt blob? Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Relocating bootwrapper causes kernel panic
Before the flat tree was accessed, I checked the DTLB and didn't find any entry related to 0xc0be4300. After the exception, I found the following DTLBs. 30 : 02 c0be4000 4KB -- - 31 : 00 fa00 8MB VI-S-M - fa00 The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this should be something like 00be4000? Note that the valid bit is clear -- it's not mapping to anything. Did the exception handler try to set a TLB here but the setting was not completed? I think the cause is clear now. But how to fix it? Two questions: 2. If the DTLB miss exception handler is not the right guy to load a proper TLB entry, how can I set one entry based on the link_address and the address of the flat dt blob? Given how early in the boot process it is, it's probably going to need to be handled specially. What APIs can I use to set up DTLBs? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
I did more debugging and something is really weird though. When the link address is changed to 0x80, when stepping through the kernel, I actually got the kernel boot successfully. However I let the kernel run through it would just crash. After crash the BDI2000 shows it stopped at __delay(). Well, actually it's nothing to do with gdb. When the link address is changed to 0x80, if the PPC_EARLY_DEBUG and PPC_EARLY_DEBUG_CPM are on, the built kernel can boot successfully. But without these EARLY_DEBUG, the kernel fails to boot. = bootm 500 ## Booting image at 0500 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1757354 Bytes = 1.7 MB Load Address: 0080 Entry Point: 00800554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0) Allocating 0x3a15a4 bytes for kernel ... gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0xbe4300 ^^The kernel stopped here. = bootm 500 ## Booting image at 0500 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1757742 Bytes = 1.7 MB Load Address: 0080 Entry Point: 00800554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0) Allocating 0x3a15a4 bytes for kernel ... gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0xbe4300 id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using My MPC870 machine description Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #5 Tue Aug 3 21:24:40 PDT 2010 bootconsole [udbg0] enabled ^The kernel continued booting. With the EARLY_DEBUG turned on, the link address is changed to 0x100, the built kernel can also boot successfully. However if the link address is changed to 0x200 or 0x400, the built kernel fails to boot. I think the kernel failure may be caused by some memory corruption. But will the bootwrapper relocation corrupt the kernel code? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Relocating bootwrapper causes kernel panic
Hi, I'm trying to relocate the bootwrapper from the default address (0x40) to a higher address (e.g. 0x80) in order to support a larger than 4MB initramfs. However the kernel panic when trying to access the device tree blob which was relocated accordingly to a higher address. The kernel message from __log_buf is shown below. The flat tree located at 0xbe4300 as the kerne message showed. Why cannot the kernel access this area? No TLB set for this area? 1Unable to handle kernel paging request for data at address 0xc0be4308 1Faulting instruction address: 0xc01fdabc 4Oops: Kernel access of bad area, sig: 11 [#1] 4 4NIP: c01fdabc LR: c01fdc38 CTR: 4REGS: c0383ee0 TRAP: 0300 Not tainted (2.6.33.5) 4MSR: 1032 ME,IR,DR CR: 28558922 XER: 0504 4DAR: c0be4308, DSISR: c000 4TASK = c0375328[0] 'swapper' THREAD: c0382000 4GPR00: c01fdc38 c0383f90 c0375328 c01fd4c8 00be4300 0010 4GPR08: c01dbd94 c0be4300 0400 07fff000 0001 4GPR16: 007fff0d 00800554 0001 007fff00 07ff9d78 07d5d2a0 4GPR24: 0891 c039 c01fd4c8 00be4300 00be4300 4NIP [c01fdabc] of_scan_flat_dt+0x20/0x174 4LR [c01fdc38] early_init_devtree+0x28/0x288 4Call Trace: 4[c0383fb0] [c01fdc38] early_init_devtree+0x28/0x288 4[c0383fd0] [c01fe9c0] machine_init+0x20/0x5c 4[c0383ff0] [c0002244] start_here+0x48/0xc4 4Instruction dump: 47fe5fb78 4bfff899 90610008 4bfffeb4 9421ffe0 7c0802a6 bf410008 90010024 47c7b1b78 7c9c2378 3f40c039 813a9070 80090008 7fe90214 3860 3ba0 4---[ end trace 31fd0ba7d8756001 ]--- 0Kernel panic - not syncing: Attempted to kill the idle task! 4Call Trace: 4[c0383dd0] [c0006c90] show_stack+0x40/0x168 (unreliable) 4[c0383e10] [c001cbfc] panic+0x8c/0x178 4[c0383e60] [c00209b0] do_exit+0x5c4/0x5d0 4[c0383ea0] [c000bb08] kernel_bad_stack+0x0/0x4c 4[c0383ec0] [c000ede8] bad_page_fault+0x90/0xd8 4[c0383ea0] [c000bb08] kernel_bad_stack+0x0/0x4c 4[c0383ec0] [c000ede8] bad_page_fault+0x90/0xd8 4[c0383ed0] [c000e2b8] handle_page_fault+0x7c/0x80 4[c0383f90] [] (null) 4[c0383fb0] [c01fdc38] early_init_devtree+0x28/0x288 4[c0383fd0] [c01fe9c0] machine_init+0x20/0x5c 4[c0383ff0] [c0002244] start_here+0x48/0xc4 The kernel message from uboot and the bootwrapper is shown below. = bootm 500 ## Booting image at 0500 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1757351 Bytes = 1.7 MB Load Address: 0080 Entry Point: 00800554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0) Allocating 0x3a15a4 bytes for kernel ... gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0xbe4300 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Relocating bootwrapper causes kernel panic
I'm trying to relocate the bootwrapper from the default address (0x40) to a higher address (e.g. 0x80) in order to support a larger than 4MB initramfs. However the kernel panic when trying to access the device tree blob which was relocated accordingly to a higher address. The kernel message from __log_buf is shown below. The flat tree located at 0xbe4300 as the kerne message showed. Why cannot the kernel access this area? No TLB set for this area? 1Unable to handle kernel paging request for data at address 0xc0be4308 1Faulting instruction address: 0xc01fdabc 4Oops: Kernel access of bad area, sig: 11 [#1] Before the flat tree was accessed, I checked the DTLB and didn't find any entry related to 0xc0be4300. After the exception, I found the following DTLBs. 30 : 02 c0be4000 4KB -- - 31 : 00 fa00 8MB VI-S-M - fa00 The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this should be something like 00be4000? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
I found the link_address in the wrapper shell script sets the _start address. But after changing it to 0x80, the kernel failed to boot, shown below. There must be something also needs proper adjustment. What would that be? I did more debugging and something is really weird though. When the link address is changed to 0x80, when stepping through the kernel, I actually got the kernel boot successfully. However I let the kernel run through it would just crash. After crash the BDI2000 shows it stopped at __delay(). I also changed the link address to 0x400. During the function of_scan_flat_dt(early_init_dt_scan_chosen, NULL) called in early_init_devtree(), gdb shows the program (i.e. kernel) received a signal SIGSTOP. Why would the kernel crash during that time? of_scan_flat_dt() doesn't seem to be the cause of SIGSTOP. What would that be then? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
It should be fine to just change it locally. It would be a problem to change it upstream for all boards, since some supported boards have only 16MB (or even 8MB) of RAM. I'll definitely try to change it locally first. Would a configurable base address for the bootwrapper an acceptable solution? I found the link_address in the wrapper shell script sets the _start address. But after changing it to 0x80, the kernel failed to boot, shown below. There must be something also needs proper adjustment. What would that be? = bootm 400 ## Booting image at 0400 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1757356 Bytes = 1.7 MB Load Address: 0080 Entry Point: 00800554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0) Allocating 0x3a15a4 bytes for kernel ... gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0xbe4300 Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Which microcode patch for MPC870?
Which microcode patch should be selected for MPC870? In the old 2.4 kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I believe USB microcode is irrelevant here. So it comes down the other two choices. Of course do I really need the patch? My board has I2C and SMC1, but no SPI. I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the following compilation error: These errors were fixed by http://patchwork.ozlabs.org/patch/58262/ and http://patchwork.ozlabs.org/patch/58263/ Thanks a lot for the info, Anton. Then the question is which patch should be selected. I don't enable any patch and the SMC UART works properly. Next I'm going to enable I2C but I don't know whether a microcode patch is required or not. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
One way to lift this limitation is to relocate the bootwrapper to somewhere else, say for example, 0x100 so that a 16MB initramfs can be loaded. If the bootwrapper is relocated, what else would be affected by this relocation? It should be fine to just change it locally. It would be a problem to change it upstream for all boards, since some supported boards have only 16MB (or even 8MB) of RAM. I'll definitely try to change it locally first. Would a configurable base address for the bootwrapper an acceptable solution? Another option is to provide a vmlinux_alloc callback to stick the kernel somewhere other than zero, at the cost of an extra image copy once the kernel runs to get itself back down to zero. This wasn't done in cuboot because it was considered better to adjust the bootwrapper link address at build time based on the kernel+ramfs image size, but that never got implemented. Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if the image fits there, and calls malloc otherwise? I'll look into this too. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Which microcode patch for MPC870?
Hi, Which microcode patch should be selected for MPC870? In the old 2.4 kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I believe USB microcode is irrelevant here. So it comes down the other two choices. Of course do I really need the patch? My board has I2C and SMC1, but no SPI. I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the following compilation error: CC arch/powerpc/sysdev/micropatch.o arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch': arch/powerpc/sysdev/micropatch.c:629: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token arch/powerpc/sysdev/micropatch.c:629: error: 'spp' undeclared (first use in this function) arch/powerpc/sysdev/micropatch.c:629: error: (Each undeclared identifier is reported only once arch/powerpc/sysdev/micropatch.c:629: error: for each function it appears in.) cc1: warnings being treated as errors arch/powerpc/sysdev/micropatch.c:630: warning: ISO C90 forbids mixed declarations and code arch/powerpc/sysdev/micropatch.c:671: error: 'spi_t' undeclared (first use in this function) arch/powerpc/sysdev/micropatch.c:671: error: expected expression before ')' token arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp' make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1 Obviously there is no spi_t declaration in 2.6.33.5. So where is this spi_t declared? Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ramdisk size is larger than 4MB
Hi, I have a ramdisk as RFS much larger than 4MB in a 2.4 kernel. In recent 2.6 kernels ramdisk is no longer supported so I decided to go with initramfs. However I found the initial RFS for initramfs is limited to 4MB since the bootwrapper locates at 0x40. One way to lift this limitation is to relocate the bootwrapper to somewhere else, say for example, 0x100 so that a 16MB initramfs can be loaded. If the bootwrapper is relocated, what else would be affected by this relocation? Another (better?) way may be to find a right file system for RFS such as JFFS2. My board has limited NOR flash (32MB) but larger RAM (128MB). There is not much space left in flash for RFS. Would you like to share some thoughts? Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
Why would the TxBD be filled with all 0xF? Would it be possible that the bdbase actually points somewhere else other than the TxBD? The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that the TxBD of my MPC870 may not start at 0xfa202020. I notice that for adder875, ep88xc and mpc885ads, the muram data's reg = 0 0x1c00 but for mgsuvd, its reg = 0x800 0x1800. How does the kernel use muram for 885 family SoCs? How much muram should be reserved for data? My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? After the muram data's reg is changed to 0x200 0x1a00, the cpm_uart driver works properly and the kernel messages are printed on the serial port. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? After the muram data's reg is changed to 0x200 0x1a00, the cpm_uart driver works properly and the kernel messages are printed on the serial port. The muram node is supposed to show the portions of DPRAM that are usable by the OS. If some portion has been taken up by microcode (or anything else not under the OS's control) before the OS has started, then it must be excluded from the muram node. It would be nicer that the initialization code could query the RCCR value and adjust the base address. It took me quite a while to understand the design. Without your help it could take much much longer. So thanks a lot for your help. My project hasn't been done yet, so I may bother you again. :) Thanks again, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
The problem is that after/when the kernel switches to the real console from the boot console, printk() calls cpm_uart_console_write() to print the first (?) message using the cpm_uart driver. But the transmitter buffer never becomes ready. It's shown below with the gdb session. Program received signal SIGSTOP, Stopped (signal). 0xc00f3510 in cpm_uart_console_write (co=value optimized out, s=0xc017703e console [ttyCPM0] enabled, bootconsole disabled\n, count=0x30) at /home/code/linux-2.6.33.5/arch/powerpc/include/asm/io.h:154 (gdb) next (gdb) x/4h bdbase 0xfddfa020: 0x 0x 0x 0x (gdb) Why would the TxBD be filled with all 0xF? Would it be possible that the bdbase actually points somewhere else other than the TxBD? The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that the TxBD of my MPC870 may not start at 0xfa202020. I notice that for adder875, ep88xc and mpc885ads, the muram data's reg = 0 0x1c00 but for mgsuvd, its reg = 0x800 0x1800. How does the kernel use muram for 885 family SoCs? How much muram should be reserved for data? My RCCR=0x1, meaning the first 512B is for microcode. So the data and the TxBD should really be starting at 0xfa202200? Then my muram data's reg should be 0x200 ?? What size shall I specify? Scott, you instructed (http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083788.html) me to change the buffer address to 0xfa203fb8 from 0xfa202008 for the bootwrapper's cpm-serial driver, assuming reg=0 0x1c00. If I need to change to the reg not starting at 0x0, how should I accordingly change this buffer address? Thanks a lot, -Shawn. I went back to 2.4.18 kernel and noticed that the ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
cpm_uart_console_write() stuck in waiting for transmitter fifo ready
Hi Gurus, Please give me some hints and directions to debug this problem. I've been scratching my head for quite a while. The problem is that after/when the kernel switches to the real console from the boot console, printk() calls cpm_uart_console_write() to print the first (?) message using the cpm_uart driver. But the transmitter buffer never becomes ready. It's shown below with the gdb session. Program received signal SIGSTOP, Stopped (signal). 0xc00f3510 in cpm_uart_console_write (co=value optimized out, s=0xc017703e console [ttyCPM0] enabled, bootconsole disabled\n, count=0x30) at /home/code/linux-2.6.33.5/arch/powerpc/include/asm/io.h:154 (gdb) next (gdb) x/4h bdbase 0xfddfa020: 0x 0x 0x 0x (gdb) Why would the TxBD be filled with all 0xF? Would it be possible that the bdbase actually points somewhere else other than the TxBD? The kernel boot messages are copied below. My target is MPC870, using SMC1 as UART. I'm porting the kernel based on adder875 board. = bootm 100 ## Booting image at 0100 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:706700 Bytes = 690.1 kB Load Address: 0040 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0040 (sp: 0x07d1cbd0) Allocating 0x186be5 bytes for kernel ... gunzipping (0x - 0x0040c000:0x005c1b78)...done 0x173b10 bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x5ce300 Probing machine type ... My MPC870 ... match ! id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using My MPC870 machine description Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #17 Wed Jul 14 01:24:03 PDT 2010 bootconsole [udbg0] enabled setup_arch: bootmem arch: exit Top of RAM: 0x800, Total RAM: 0x800 Memory hole size: 0MB Zone PFN ranges: DMA 0x - 0x8000 Normal 0x8000 - 0x8000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x8000 On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c016b5b0, node_mem_map c0189000 DMA zone: 256 pages used for memmap DMA zone: 0 pages reserved DMA zone: 32512 pages, LIFO batch:7 MMU: Allocated 72 bytes of context maps for 16 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/ram PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128096k/131072k available (1416k kernel code, 2836k reserved, 72k data, 74k bss, 76k init) Kernel virtual memory layout: * 0xfffdf000..0xf000 : fixmap * 0xfde0..0xfe00 : consistent mem * 0xfddfa000..0xfde0 : early ioremap * 0xc900..0xfddfa000 : vmalloc ioremap SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:512 nr_irqs:512 irq: Allocated host of type 2 @0xc7804000 irq: irq_create_mapping(0xc7804000, 0x5) irq: - using host @c7804000 alloc irq_desc for 16 on node 0 alloc kstat_irqs on node 0 irq: irq 5 on host /s...@fa20/interrupt-control...@0 mapped to virtual irq 16 irq: Allocated host of type 2 @0xc7804200 irq: irq_create_mapping(0xc7804200, 0x0) irq: - using host @c7804200 alloc irq_desc for 17 on node 0 alloc kstat_irqs on node 0 irq: irq 0 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 17 Decrementer Frequency = 0x7270e0 irq: irq_create_mapping(0xc7804000, 0xf) irq: - using host @c7804000 alloc irq_desc for 18 on node 0 alloc kstat_irqs on node 0 irq: irq 15 on host /s...@fa20/interrupt-control...@0 mapped to virtual irq 18 time_init: decrementer frequency = 7.50 MHz time_init: processor frequency = 120.00 MHz clocksource: timebase mult[2155] shift[22] registered clockevent: decrementer mult[1eb851e] shift[32] cpu[0] irq: irq_create_mapping(0xc7804200, 0x4) irq: - using host @c7804200 alloc irq_desc for 19 on node 0 alloc kstat_irqs on node 0 irq: irq 4 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 1� Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
You're probably getting to the point where udbg is disabled because the real serial driver is trying to take over -- and something's going wrong with the real serial port driver. Check to make sure the brg config is correct (both the input clock and the baud rate you're trying to switch to). Commenting out the call to cpm_set_brg can be a quick way of determining if that's the problem. It seems that the last CP command RESTART_TX never completes in the cpm_uart_console_setup(). I commented out the writes to brgc1 in cpm_setbrg() in cpm1.c so that the brgc1 value stays the same as previously set. The registers related to SMC1 are dumped below before the last RESTART_TX command. The CPCR was 0x0090. But after issuing the RESTART_TX command the CPCR kept at 0x0691. Is there any other obvious reason for CPM not completing the command? It got to be something related to the settings. BDIrd cpcr cpcr : 0x0090 144 BDIrd rccr rccr : 0x0001 1 BDIrd rmds rmds : 0x000 BDIrd rctr1 rctr1 : 0x 0 BDIrd rctr2 rctr2 : 0x 0 BDIrd rctr3 rctr3 : 0x802e -32722 BDIrd rctr4 rctr4 : 0x802c -32724 BDIrd rter rter : 0x 0 BDIrd rtmr rtmr : 0x 0 BDIrd brgc1 brgc1 : 0x00010618 67096 BDIrd smcmr1 smcmr1 : 0x4823 18467 BDIrd smce1 smce1 : 0x000 BDIrd smcm1 smcm1 : 0x000 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
For some reason. This email was rejected. Resending... On Sun, Jul 11, 2010 at 11:26 PM, Shawn Jin shawnx...@gmail.com wrote: You're probably getting to the point where udbg is disabled because the real serial driver is trying to take over -- and something's going wrong with the real serial port driver. Check to make sure the brg config is correct (both the input clock and the baud rate you're trying to switch to). Commenting out the call to cpm_set_brg can be a quick way of determining if that's the problem. It seems that the last CP command RESTART_TX never completes in the cpm_uart_console_setup(). I commented out the writes to brgc1 in cpm_setbrg() in cpm1.c so that the brgc1 value stays the same as previously set. The registers related to SMC1 are dumped below before the last RESTART_TX command. The CPCR was 0x0090. But after issuing the RESTART_TX command the CPCR kept at 0x0691. Is there any other obvious reason for CPM not completing the command? It got to be something related to the settings. BDIrd cpcr cpcr : 0x0090 144 BDIrd rccr rccr : 0x0001 1 BDIrd rmds rmds : 0x00 0 BDIrd rctr1 rctr1 : 0x 0 BDIrd rctr2 rctr2 : 0x 0 BDIrd rctr3 rctr3 : 0x802e -32722 BDIrd rctr4 rctr4 : 0x802c -32724 BDIrd rter rter : 0x 0 BDIrd rtmr rtmr : 0x 0 BDIrd brgc1 brgc1 : 0x00010618 67096 BDIrd smcmr1 smcmr1 : 0x4823 18467 BDIrd smce1 smce1 : 0x00 0 BDIrd smcm1 smcm1 : 0x00 0 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
I changed my toolchain and rebuilt the kernel image. This time all the
messages below magically displayed on the serial port. :-D Are all
these the early debugging messages?
Here is the kernel log buf dump. Anything suspicious?
6Using My MPC870 machine description
5Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.3.3 (GCC) )
#10 Mon Jul 5 22:58:30 PDT 2010
7Top of RAM: 0x800, Total RAM: 0x800
7Memory hole size: 0MB
4Zone PFN ranges:
...
snipped
...
7time_init: decrementer frequency = 3.75 MHz
7time_init: processor frequency = 120.00 MHz
6clocksource: timebase mult[42ab] shift[22] registered
7clockevent: decrementer mult[f5c28f] shift[32] cpu[0]
7 alloc irq_desc for 18 on node 0
7 alloc kstat_irqs on node 0
7irq: irq 4 on host /s...@fa20/c...@9c0/interrupt-control...@930
mapped to virtual irq 18
Now the kernel stuck at the while loop that waits for transmitter fifo
to be empty. It seems that the CPM UART stopped working in the middle
of printing a message. I'm using minicom to connect to the serial
port. I heard minicom is problematic. Will it be the cause here?
(gdb) target remote ppcbdi:2001
Remote debugging using ppcbdi:2001
0xc00f348c in cpm_uart_console_write (co=value optimized out,
s=0xc0174df3 console [ttyCPM0] enabled, bootconsole disabled\n, count=48)
at /home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/io.h:154
154 DEF_MMIO_IN_BE(in_be16, 16, lhz);
(gdb) next
1161while ((in_be16(bdp-cbd_sc) BD_SC_READY) != 0)
(gdb) next
154 DEF_MMIO_IN_BE(in_be16, 16, lhz);
(gdb) next
1161while ((in_be16(bdp-cbd_sc) BD_SC_READY) != 0)
(gdb) list
1156for (i = 0; i count; i++, s++) {
1157/* Wait for transmitter fifo to empty.
1158 * Ready indicates output is ready, and xmt is doing
1159 * that, not that it is ready for us to send.
1160 */
1161while ((in_be16(bdp-cbd_sc) BD_SC_READY) != 0)
1162;
1163
1164/* Send the character out.
1165 * If the buffer address is in the CPM DPRAM, don't
Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood scottw...@freescale.com wrote: Hmm... try 0xfa203bf8 (assuming your muram/data node has reg = 0 0x1c00). It looks like commit c2dd3529f35de9e2f51eba9bbf9969f5dc8382d4 changed the bootwrapper's cpm-serial driver to allocate from the end of MURAM instead of the beginning, but updated CONFIG_PPC_EARLY_DEBUG_CPM_ADDR to match only on CPM2, not CPM1. That was it. The value @0xfa203bf8 is 0x2001. The kernel certainly moved forward till it stuck at the new place cpm_uart_initbd() as shown below. I cannot get more info from gdb now since my BDI2000's fw is too old to get MMU translation work for 2.6.x kernel. I'm waiting for the new firmware upgrade. (gdb) target remote bdi:2001 Remote debugging using bdi:2001 cpm_uart_initbd (pinfo=0x1032) at /home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/io.h:161 161 DEF_MMIO_OUT_BE(out_be32, 32, stw); Could the kernel have crashed, and is waiting the 180 seconds to reboot? Try doing a stack trace, and/or dumping the kernel's log buffer. It sounds like that. gdb showed there was only one level of function in the stack, which was udelay(). Strange? How to dump the kernel log buffer? Thanks a lot for your continuous help! -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel boot stuck at udbg_putc_cpm()
That was it. The value @0xfa203bf8 is 0x2001. The kernel certainly moved forward till it stuck at the new place cpm_uart_initbd() as shown below. Do you get any output from the serial port? I'd have expected something by the time you get to cpm_uart_initbd() -- in fact, the early output will have been shut down by then to make room for the real serial driver. Nothing new on the serial port. :-( Is the interrupt enabled during the early debug stage? I'm not sure if the interrupt controller is set properly in DTS. The same MPC875 settings are copied from the adder875-uboot.dts. Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x393870 (4MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0040 (sp: 0x07d1ccd0) Allocating 0x186bdd bytes for kernel ... gunzipping (0x - 0x0040c000:0x00591c30)...done 0x173b18 bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x59e300 Here is the kernel log buf dump. Anything suspicious? 6Using My MPC870 machine description 5Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.3.3 (GCC) ) #10 Mon Jul 5 22:58:30 PDT 2010 7Top of RAM: 0x800, Total RAM: 0x800 7Memory hole size: 0MB 4Zone PFN ranges: 4 DMA 0x - 0x8000 4 Normal 0x8000 - 0x8000 4Movable zone start PFN for each node 4early_node_map[1] active PFN ranges 40: 0x - 0x8000 7On node 0 totalpages: 32768 7free_area_init_node: node 0, pgdat c016c5b0, node_mem_map c0189000 7 DMA zone: 256 pages used for memmap 7 DMA zone: 0 pages reserved 7 DMA zone: 32512 pages, LIFO batch:7 6MMU: Allocated 72 bytes of context maps for 16 contexts 4Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 5Kernel command line: root=/dev/ram 6PID hash table entries: 512 (order: -1, 2048 bytes) 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) 6Memory: 128096k/131072k available (1420k kernel code, 2836k reserved, 68k data, 74k bss, 76k init) 6Kernel virtual memory layout: 6 * 0xfffdf000..0xf000 : fixmap 6 * 0xfde0..0xfe00 : consistent mem 6 * 0xfddfa000..0xfde0 : early ioremap 6 * 0xc900..0xfddfa000 : vmalloc ioremap 6SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 6Hierarchical RCU implementation. 6NR_IRQS:512 nr_irqs:512 7 alloc irq_desc for 16 on node 0 7 alloc kstat_irqs on node 0 7irq: irq 5 on host /s...@fa20/interrupt-control...@0 mapped to virtual irq 16 7 alloc irq_desc for 17 on node 0 7 alloc kstat_irqs on node 0 7irq: irq 0 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 17 7time_init: decrementer frequency = 3.75 MHz 7time_init: processor frequency = 120.00 MHz 6clocksource: timebase mult[42ab] shift[22] registered 7clockevent: decrementer mult[f5c28f] shift[32] cpu[0] 7 alloc irq_desc for 18 on node 0 7 alloc kstat_irqs on node 0 7irq: irq 4 on host /s...@fa20/c...@9c0/interrupt-control...@930 mapped to virtual irq 18 Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
kernel boot stuck at udbg_putc_cpm()
Hi,
I'm debugging the kernel (2.6.33.5) ported for a MPC870 board. The
changes are mostly based on the board adder875. The first thing I want
to test is the serial port. So I enabled CONFIG_PPC_EARLY_DEBUG and
CONFIG_PPC_EARLY_DEBUG_CPM, and changed
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR to 0xfa202008. My IMMR is 0xfa20.
However the kernel seems to stuck at udbg_putc_cpm(). The most
significant bit at 0xfa202008 never changed to zero.
I did a few debugging sessions, observed some frustrating things.
Would anyone here more experienced shed some lights on potential
causes?
First I set breakpoint at machine_init(). Below is the debug session.
(gdb) target remote bdi:2001
Remote debugging using bdi:2001
machine_init (dt_ptr=5890816) at arch/powerpc/kernel/setup_32.c:121
121 {
(gdb) next
125 udbg_early_init();
(gdb) next
^C
Program received signal SIGSTOP, Stopped (signal).
udelay (usecs=value optimized out)
at
/home/rayan/wti/code/wti-linux-2.6.33.5/arch/powerpc/include/asm/time.h:78
78 return mftbl();
(gdb) li
73 #if defined(CONFIG_403GCX)
74 unsigned long tbl;
75 asm volatile(mfspr %0, 0x3dd : =r (tbl));
76 return tbl;
77 #else
78 return mftbl();
79 #endif
80 }
81
82 static inline unsigned int get_tbu(void)
(gdb) step
413 while (get_tbl() - start loops)
(gdb) step
414 HMT_low();
(gdb) print start
No symbol start in current context.
(gdb) print loops
No symbol loops in current context.
(gdb)
Several observations regarding to the above debugging session.
1. The kernel seems not able to pass udbg_early_init(). However if
breakpoint was set at functions being executed later such as
probe_machine() or start_kernel(), the udbg_early_init() was executed
properly.
2. When the execution was interrupted, it stopped at __delay(). And
the kernel seems not able to get out of this __delay() function. There
was even no symbols for local variables. Why?
Next I set the breakpoint at probe_machine(). The gdb session is shown
below. Again a couple of frustrating observations.
1. The kernel seems not able to get into the for loop. The breakpoint
set inside the for loop never got hit.
2. Once the execution was interrupted, it stopped at __delay() again,
same as the previous gdb session.
(gdb) target remote bdi:2001
Remote debugging using bdi:2001
probe_machine () at arch/powerpc/kernel/setup-common.c:525
525 {
(gdb) step
535 for (machine_id = __machine_desc_start;
(gdb) print __machine_desc_start
$1 = {name = 0xc013ea64 My MPC870, pci_dma_dev_setup = 0,
pci_dma_bus_setup = 0, probe = 0xc01544c4 my870_probe,
setup_arch = 0xc015442c my870_setup, init_early = 0, show_cpuinfo = 0,
show_percpuinfo = 0, init_IRQ = 0xc01541d4 mpc8xx_pics_init,
get_irq = 0xc001344c mpc8xx_get_irq, pcibios_fixup = 0,
pci_probe_mode = 0, pci_irq_fixup = 0, pci_setup_phb = 0,
restart = 0xc0013f0c mpc8xx_restart, power_off = 0, halt = 0, panic = 0,
cpu_die = 0, time_init = 0, set_rtc_time = 0xc0013fdc mpc8xx_set_rtc_time,
get_rtc_time = 0xc0013f78 mpc8xx_get_rtc_time, get_boot_time = 0,
rtc_read_val = 0, rtc_write_val = 0,
calibrate_decr = 0xc0151e70 generic_calibrate_decr,
progress = 0xc0153110 udbg_progress, log_error = 0, nvram_read_val = 0,
nvram_write_val = 0, nvram_write = 0, nvram_read = 0, nvram_size = 0,
nvram_sync = 0, system_reset_exception = 0, machine_check_exception = 0,
feature_call = 0, pci_get_legacy_ide_irq = 0, phys_mem_access_prot = 0,
idle_loop = 0, power_save = 0, enable_pmcs = 0, set_dabr = 0, init = 0,
kgdb_map_scc = 0, pcibios_after_init = 0, pci_exclude_device = 0,
pcibios_fixup_resources = 0, pcibios_fixup_bus = 0,
pcibios_enable_device_hook = 0, machine_shutdown = 0}
(gdb) print __machine_desc_end
$2 = {name = 0x0, pci_dma_dev_setup = 0, pci_dma_bus_setup = 0, probe = 0,
setup_arch = 0, init_early = 0, show_cpuinfo = 0, show_percpuinfo = 0,
init_IRQ = 0, get_irq = 0, pcibios_fixup = 0, pci_probe_mode = 0,
pci_irq_fixup = 0, pci_setup_phb = 0, restart = 0, power_off = 0, halt = 0,
panic = 0, cpu_die = 0, time_init = 0, set_rtc_time = 0, get_rtc_time = 0,
get_boot_time = 0, rtc_read_val = 0, rtc_write_val = 0, calibrate_decr = 0,
progress = 0, log_error = 0, nvram_read_val = 0, nvram_write_val = 0,
nvram_write = 0, nvram_read = 0, nvram_size = 0, nvram_sync = 0,
system_reset_exception = 0, machine_check_exception = 0, feature_call = 0,
pci_get_legacy_ide_irq = 0, phys_mem_access_prot = 0, idle_loop = 0,
power_save = 0, enable_pmcs = 0, set_dabr = 0, init = 0, kgdb_map_scc = 0,
pcibios_after_init = 0, pci_exclude_device = 0, pcibios_fixup_resources = 0,
pcibios_fixup_bus = 0, pcibios_enable_device_hook = 0, machine_shutdown = 0}
(gdb) step
536 machine_id __machine_desc_end;
(gdb) print machine_id
$3 = (struct machdep_calls *) 0x0
(gdb) step
525 {
(gdb) step
535
Re: machine check in kernel for a mpc870 board
local...@fa200100 {
compatible = fsl,mpc885-localbus, fsl,pq1-localbus,
simple-bus;
#address-cells =2;
#size-cells =1;
reg =0xfa200100 0x40;
ranges =
0 0 0xfe00 0x0100 // I'm not sure about
this?
;
};
Change 0xfe00 to wherever u-boot maps your flash, and 0x0100 to
whatever the size of the flash localbus mapping is.
Or more generally update this section to hold whatever is connected to the
localbus on your board. The first cell is the chipselect.
The chipselect? Isn't it just the child-bus-addr? BTW, do we have to
define the #address-cells to 2? 1 is not enough?
SDRAM uses CS0/6, each 64MB. BDI2000 configuration is as follows.
; init memory controller
WM320xFA200104 0xfe000ff6 ;;OR0: Flash 32MB
WM320xFA200100 0xfc01 ;;BR0: Flash at 0xFC00,
32bit, R/W, no parity, use GPCM
WM320xFA20010C 0xfc000e00 ;;OR1: SDRAM 64MB, all accesses
WM320xFA200108 0x0081 ;;BR1: SDRAM at 0x,
32bit, R/W, no parity, use UPMA
WM320xFA200134 0xfc000e00 ;;OR6: SDRAM 64MB, all accesses
WM320xFA200130 0x0481 ;;BR6: SDRAM at 0x0400, 32bit, R/W,
no parity, use UPMA
When defining memory's reg property, can a single pair 0 0x0800
be enough? Or must it be 0 0x0400 0x0400 0x0400?
Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
The chipselect? Isn't it just the child-bus-addr? BTW, do we have to
define the #address-cells to 2? 1 is not enough?
The first cell of the child bus address is the chip select, the second
cell is the offset into the chip select.
I see. So the #address-sells of 2 doesn't necessarily indicate the
address is 64 bits? Different processors can interpret it differently?
Where can I find such info? Is there any doc on this?
I have a question on the serial settings. Why does it locate at 0xa80?
According to MPC885RM.pdf, the SMC1's registers start from 0xa82. What
does the reg property specify here for SMC1, the first set of 0xa80
0x10 and the 2nd 0x3e80 0x40?
console: ser...@a80 {
device_type = serial;
compatible = fsl,mpc875-smc-uart,
fsl,cpm1-smc-uart;
reg = 0xa80 0x10 0x3e80 0x40;
interrupts = 4;
interrupt-parent = CPM_PIC;
fsl,cpm-brg = 1;
fsl,cpm-command = 0x0090;
current-speed = 115200;
Thanks a lot,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
Hi Scott,
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc
relate to IMMR? So my localbus and soc should be as follows?
local...@fa200100 {
compatible = fsl,mpc885-localbus, fsl,pq1-localbus,
simple-bus;
#address-cells = 2;
#size-cells = 1;
reg = 0xfa200100 0x40;
ranges =
0 0 0xfe00 0x0100 // I'm not sure about
this?
;
};
I managed to proceed a little bit further.
Memory - 0x0 0x800 (128MB)
ENET0: local-mac-address - 00:09:9b:01:58:64
CPU clock-frequency - 0x7270e00 (120MHz)
CPU timebase-frequency - 0x393870 (4MHz)
CPU bus-frequency - 0x3938700 (60MHz)
zImage starting: loaded at 0x0040 (sp: 0x07d1ccd0)
Allocating 0x186bdd bytes for kernel ...
gunzipping (0x - 0x0040c000:0x00591c30)...done 0x173b18 bytes
Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0x59e300
The gdb showed deadbeef.
(gdb) target remote ppcbdi:2001
Remote debugging using ppcbdi:2001
0xdeadbeef in ?? ()
(gdb)
The kernel doesn't seem to start. What could go wrong here?
Thanks a lot,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.?
If your CCSRBAR is 0xfa20, then pretty much anywhere you see 0xff0x
change it to 0xfa2x.
I'm not sure about the range settings of 0xfe00. How do you get this?
local...@fa200100 {
compatible = fsl,mpc885-localbus, fsl,pq1-localbus,
simple-bus;
#address-cells = 2;
#size-cells = 1;
reg = 0xfa200100 0x40;
ranges =
0 0 0xfe00 0x0100// I'm not sure about this?
;
};
Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0x59e300
The gdb showed deadbeef.
(gdb) target remote ppcbdi:2001
Remote debugging using ppcbdi:2001
0xdeadbeef in ?? ()
(gdb)
The kernel doesn't seem to start. What could go wrong here?
Pretty much anything. :-)
I realized that. :-P The kernel booting was able to stop at
start_kernel(). I'm going to trace further.
Make sure that you've got Linux platform code enabled that matches the
top-level compatible of your device tree. Try enabling PPC_EARLY_DEBUG_CPM,
making sure to update PPC_EARLY_DEBUG_CPM_ADDR to 0xfa202008.
I enabled this early debug feature but don't know this address change.
I'll try it later.
Thanks a lot, Scott.
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
Hi Scott, Bus Fault @ 0x00404c40, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 07d1cb80 Unknown values in msr NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 0001 MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 Can you look up the source line/instruction corresponding to 0x404c40, in the wrapper ELF file? I'm not sure how to look up it. But I used the BDI to dump the instructions in which you may find some clue? These should be kernel code, right? Maybe the gdb can help to de-assemble them? BDImd 0x404c00 0x20 00404c00 : 0x4800317d 1207972221 H.1} 00404c04 : 0x80010014 -2147418092 00404c08 : 0xbbc10008 -1144979448 00404c0c : 0x7c0803a6 208096 |... 00404c10 : 0x38210010941686800 8!.. 00404c14 : 0x4e800020 1317011488 N.. 00404c18 : 0x9421fff0 -1809711120 .!.. 00404c1c : 0x7c0802a6 2080899750 |... 00404c20 : 0x429f0005 1117716485 B... 00404c24 : 0xbfc10008 -1077870584 00404c28 : 0x7fc802a6 2143814310 00404c2c : 0x90010014 -1878982636 00404c30 : 0x3fde0001 1071513601 ?... 00404c34 : 0x3bdedd98 1004461464 ;... 00404c38 : 0x813e8000 -2126610432 ... 00404c3c : 0x8149 -2125922304 .I.. 00404c40 : 0xa00a -1609957376 00404c44 : 0x0c00201326592 00404c48 : 0x4c00012c 1275068716 L.., 00404c4c : 0x70090001 1879638017 p... 00404c50 : 0x4082fff0 1082327024 @... 00404c54 : 0x817e8000 -2122416128 .~.. 00404c58 : 0x5469402e 1416183854 t...@. Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
Hi Scott,
Does u-boot on your board put IMMR somewhere other than 0xff00? If so,
you'll need to update the device tree to reflect this.
Thanks a lot. I think you got something here. Please bear with me.
This is the first dts file I'm creating. I have some question
regarding to dts first. BTW, My IMMR is at 0xfa20.
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc
relate to IMMR? So my localbus and soc should be as follows?
local...@fa200100 {
compatible = fsl,mpc885-localbus, fsl,pq1-localbus,
simple-bus;
#address-cells = 2;
#size-cells = 1;
reg = 0xfa200100 0x40;
ranges =
0 0 0xfe00 0x0100// I'm not sure about this?
;
};
s...@fa20 {
compatible = fsl,mpc875-immr, fsl,pq1-soc, simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 0xfa20 0x4000;
// Temporary until code stops depending on it.
device_type = soc;
// Temporary until get_immrbase() is fixed.
reg = 0xfa20 0x4000;
};
Thanks again,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
machine check in kernel for a mpc870 board
I'm porting a mpc870 board to the powerpc arch. The base is the adder-875 board. My first try to boot the cuImage.my870 is experiencing a machine check. And I have no clue where to look. Any help? = bootm 100 ## Booting image at 0100 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:747319 Bytes = 729.8 kB Load Address: 0040 Entry Point: 004004d4 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Bus Fault @ 0x00404c40, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 07d1cb80 Unknown values in msr NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 0001 MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 00404D50 07D1CC70 0004 007FFF0C 0001 0040AAB8 726F6F74 GPR08: 3D2F6465 0059D958 FF0009C0 0059DDDC FF003C00 1014BAC4 07FFF000 0001 GPR16: 007FFF0D 004004D4 0001 007FFF00 07FF9D78 07D5D2A0 GPR24: 007FFEC0 0080 0059D958 004129BC Call backtrace: machine check Thanks alot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
= bootm 100 ## Booting image at 0100 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 747319 Bytes = 729.8 kB Load Address: 0040 Entry Point: 004004d4 Load and Entry Point should probably be 0 But the cuImage.adder875-uboot image also has the same load address as mine and the entry point is 0x4004d8. Also cuImage.mpc885ads has the same load address and entry point as cuImage.adder875-uboot. So I don't suspect them. All right. I built a uImage for mpc885ads and the uImage's load address and entry point are both 0. So this is because I'm using cuImage instead of uImage. Thanks Joake, anyway. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc870 support in the powerpc arch?
On Mon, May 17, 2010 at 12:54 PM, Scott Wood scottw...@freescale.com wrote: On Fri, May 14, 2010 at 02:41:29PM -0700, Shawn Jin wrote: Hi, Is mpc870 fully supported in the powerpc arch? I know it's an old processor but 8xx is still one of platforms in the powerpc arch. If it's not supported, how much effort will it be to resurrect mpc870 in the new arch considering we have substantial 8xx support? It should work, with appropriate board support -- MPC875 and MPC885 have been used with arch/powerpc, and MPC870 is very similar (albeit with fewer devices). Thanks Scott. I found your implementation in the kernel. I use adder875 as my base to port my board support. But I'm having a problem in the last step to create the cuImage. You may know what I did wrong. The error message is as follows. WRAParch/powerpc/boot/cuImage.my870 ppc_8xx-ld: arch/powerpc/boot/cuboot-my870.o: No such file: No such file or directory make[1]: *** [arch/powerpc/boot/cuImage.my870] Error 1 I believe the default cuboot-8xx.c should be enough for my board to fix up the board settings. I don't know why the linker was looking for this cuboot-my870.o object file. BTW, my kernel is 2.6.33.5. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
mpc870 support in the powerpc arch?
Hi, Is mpc870 fully supported in the powerpc arch? I know it's an old processor but 8xx is still one of platforms in the powerpc arch. If it's not supported, how much effort will it be to resurrect mpc870 in the new arch considering we have substantial 8xx support? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Migrating from ppc to powerpc
On Sun, Apr 4, 2010 at 12:27 AM, Grant Likely grant.lik...@secretlab.cawrote: What processor/board/soc are you using? The easiest path is to start with a similar board and adapt the device tree source file (.dts in arch/powerpc/boot/dts) to match your board with your devices. You'll need to add a node to the tree for each device you add. If you post your new .dts file to devicetree-disc...@lists.ozlabs.org for review, then I and others will help you to craft it and get it into the format that it needs to be in. Thanks a lot for the info. The board has a MPC7448 processor. I certainly like to post the .dts file for review and help. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Migrating from ppc to powerpc
Hi, I have a project that needs port ppc drivers to the powerpc arch. I've been searching the mailing list for some clues on what tasks they would look like and where should be the starting point. It's been quite a while since the powerpc arch started so the info is huge. The searching doesn't seem to be easy task for itself. :( Would gurus here shed some light? One thing I know of is a device tree. Assuming a device tree is provided, how much work would it be for driver porting? Thanks alot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
