On Wed, 2009-12-23 at 23:28 -0800, tma...@amcc.com wrote:
> From: Tirumala Marri
>
>
> Signed-off-by: Tirumala Marri
> ---
> When 460SX configured as root as a end point E1000(Intell Ethernet card)
> was plugged into the one of the PCI-E ports. I was able to run the
> traffic
>
On Mon, 2009-12-28 at 12:51 +0200, Felix Radensky wrote:
> Hi,
>
> I'm running linux-2.6.33-rc2 on Canyonlands board. When PLX 6254
> transparent PCI-PCI
> bridge is plugged into PCI slot the kernel simply resets the board
> without printing anything
> to console. Without PLX bridge kernel boots
From: "Liu Dave-R63238"
Date: Mon, 4 Jan 2010 11:42:30 +0800
> How about this patch? Please consider to pick it up to your tree.
It's not in my inbox nor is it in the patchwork networking
queue, so it must be formally resubmitted in order to be
included.
_
> On Fri, Nov 27, 2009 at 04:16:43PM +0800, Dave Liu wrote:
> > current the Rx/Tx FIFO size settings cause problem
> > when four UEC ethernets work simultaneously.
> >
> > eg: GETH1, UEM-J15, GETH2, UEC-J5 on 8569MDS board
> >
> > $ ifconfig eth0 10.193.20.166
> > $ ifconfig eth1 10.193.20.167
Note that the FIT image can also be made to contain a number of DT
blobs, and selection of a "board profile" then can be used to boot the
very sane FIT image file on any of the supported boards - so FIT
images inherently support multibooting.
I agree with Wolfgang. Additionally, if a FIT ima
Hi Wolfgang,
The "new" FIT image type should become the default, and old "legacy"
images should only be generated upon special request (i. e. if some-
one needs these for compatibility with an old, not yet FIT-aware
version of the boot loader).
Agreed.
What do you think about changing the U-
Hello, All,
Happy New Year to everyone!
I am running ppc440epx board which is similar Sequoia board. I have configured
a I2C RTC device. From the console debug message, it is working, but I do not
see /dev/rtc0 file. My kernel version is 2.6.30.4. I use initramfs as my root
file system. Here i
> "Wolfgang" == Wolfgang Denk writes:
Hi,
>> No, that would break stuff for the existing users. The existing format
>> make/file names shouldn't change.
Wolfgang> Well, with this argument you can block all progress and freeze all
Wolfgang> development to some ancient state.
We only bre
Dear Grant Likely,
In message you
wrote:
>
> As I said in a previous email; I understand the need for certain
> scenarios, but in the general case it is not the mode that I think
> should be encouraged. I don't want to merge additional targets for
> .dtb embedded in the kernel image unless abso
Dear Grant Likely,
In message you
wrote:
>
> > Let's make this "uImage.old" (or "uImage.legacy" similar) and
> > "uImage", then.
>
> I'm not interested in renaming the target name for the current uImage
> format. I think it will cause too much breakage and pain to do so.
We did this before, a
Dear Grant Likely,
In message you
wrote:
>
> > Currently they have to make a "legacy" uImage, manually run the device
> > tree compiler with the proper flags to generate a board-specific .dtb
> > file,
>
> ... or put the .dts files into arch/powerpc/boot/dts and use 'make .=
> dtb'
>
> multip
Dear Peter,
In message <87wrzzpq8c@macbook.be.48ers.dk> you wrote:
>
> Wolfgang> Let's make this "uImage.old" (or "uImage.legacy" similar) and
> Wolfgang> "uImage", then.
>
> No, that would break stuff for the existing users. The existing format
> make/file names shouldn't change.
Well, wi
> "Wolfgang" == Wolfgang Denk writes:
>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
Wolfgang> Let's make this "uImage.old" (or "uImage.legacy" similar) and
Wolfgang> "uImage", then.
No, that would break s
13 matches
Mail list logo
