> 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 fr
> 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
>> 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 suppor
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
>> 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 lo
>> 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
>> > > 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
>> 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 tec
> Try the following steps:
> --
> 1. cp arch/powerpc/boot/ramdisk.image.gz
> 2. make cuImage.initrd.
>
> You can get one Image, cuImage.initrd., including kernel and
> ramdisk.
Cool! Thanks a lot, Tiejun.
-Shawn.
___
Linuxppc-dev mailing list
Linu
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 p
>> 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 wit
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
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
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 i
On Tue, Aug 10, 2010 at 11:55 PM, Shawn Jin 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
> CONF
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 r
> 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
>> 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 inte
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 en
>> > >> 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 ear
>> > 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
>> The flat tree located at 0xbe4300 as the kerne message showed. Why
>> cannot the kernel access this area? No TLB set for this area?
>>
>> <1>Unable to handle kernel paging request for data at address 0xc0be4308
>> <1>Faulting instruction address: 0xc01fdabc
>> <4>Oops: Kernel access of bad area,
> 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 kern
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 me
> 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 __d
> 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
>> 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 acceptab
>> 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 woul
>> 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 US
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 t
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 microcod
>> > 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
>> 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, e
> 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.
>
> Progra
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
For some reason. This email was rejected. Resending...
On Sun, Jul 11, 2010 at 11:26 PM, Shawn Jin 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
> 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
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?
>
> <6>Using My MPC870 machine description
> <5>Linux version 2.6.33
>> 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
> ea
On Tue, Jul 6, 2010 at 1:21 PM, Scott Wood 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
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. M
>> 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 in
>> local...@fa200100 {
>> compatible = "fsl,mpc885-localbus", "fsl,pq1-localbus",
>> "simple-bus";
>> #address-cells =<2>;
>> #size-cells =<1>;
>> reg =<0xfa200100 0x40>;
>>
>> ranges =<
>>
>>> 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
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
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.
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
>> => 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
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: Po
On Mon, May 17, 2010 at 12:54 PM, Scott Wood 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
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.
___
On Sun, Apr 4, 2010 at 12:27 AM, Grant Likely wrote:
> 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 tre
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 see
53 matches
Mail list logo
