* Re: DMA Driver on MPC8260
From: Manish Joshi @ 2006-08-03 23:09 UTC (permalink / raw)
To: jimmy liu, linuxppc-embedded
In-Reply-To: <20060803213507.93830.qmail@web53109.mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
No idea about sample code.
But I think programming DMA itself is straightforward as mentioned below.
Just ensure to use uncached physical memory for src/dest addresses.
Then you can program your interrupt to receive the DMA completion notification.
There are couple of registers like ESR, DMASR etc which you can check in case you see any issues after programming your DMA config registers which are little endian.
jimmy liu <jimmyzhmliu@yahoo.com> wrote:
You are 100% right. MPC8260 has 4 DMA channels which
can be programmed independently. Could I find some
sample code from some place?
--- Manish Joshi wrote:
> What kind of information you are looking for?
> Specific questions always help.
> General details you can find in the user manual
> itself.
>
> Not sure, but I think MPC8260 has 4 DMA channels
> which can be programmed independently. You need to
> set the mode registers and then the src/dest addr
> registers and byte count and finally turn on the
> start bit.
>
>
> jimmy liu wrote:
> I am working on PCI transactions between MPC8260
> and
> FPGA. Could somebody give me some information about
> the PCI DMA Driver on MPC8260?
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> ---------------------------------
> Want to be your own boss? Learn how on Yahoo! Small
> Business.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------
Want to be your own boss? Learn how on Yahoo! Small Business.
[-- Attachment #2: Type: text/html, Size: 2474 bytes --]
^ permalink raw reply
* tool for editing builtin command line
From: Amos Waterland @ 2006-08-03 22:22 UTC (permalink / raw)
To: linuxppc-dev
The following is a tool for reading and editing the builtin command line
arguments in Linux zImage files and other bootable files that follow the
same format. It is useful in a cluster context in which one is booting
the same kernel on many machines with the only difference being their
network autoconfiguration values. Inspired by a script that Michal
Ostrowski posted earlier.
To see the existing arguments in a bootable image:
$ ./builtin-cmdline zImage
console=ttyS0,19200
To put new arguments in the image:
$ ./builtin-cmdline zImage "ro root=/dev/nfs nfsroot=192.168.0.3:/nfsroot \
ip=192.168.0.4::192.168.0.2:255.255.255.0:cluster001:eth0:off"
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
#!/bin/bash
#
# Copyright (C) 2006 Amos Waterland <apw@us.ibm.com>, IBM Corp.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
function help()
{
local name=$1;
local version=$2;
echo -e "\`$name' manipulates builtin command line arguments\n" \
"\n" \
"Usage: $name FILE [ARGS]\n" \
" -?, --help Show this help statement.\n" \
" --version Show version statement.\n" \
"\n" \
"Examples: $name zImage\n" \
" $name zImage 'console=ttyS0'";
}
function work()
{
local file=$1;
local args=$2;
local off; local siz; local out;
off=$(objdump -h $file |
gawk -- '{if($2=="__builtin_cmdline") {print strtonum("0x"$6);}}';)
if [ -z $off ]; then
echo "error: cannot find command line section in: $file"; return 1;
fi
siz=$(objdump -h $file |
gawk -- '{if($2=="__builtin_cmdline") {print strtonum("0x"$3);}}';)
if [ -z $siz ]; then return 1; fi
if [ -z "$args" ]; then
out=$(dd bs=1 if=$file skip=$off count=$siz 2>/dev/null);
if [ $? -ne 0 ]; then return 1; fi
echo $out;
else
dd if=/dev/zero of=$file bs=1 \
seek=$off conv=notrunc count=$siz 2>/dev/null
if [ $? -ne 0 ]; then return 1; fi
echo -n "$args" | dd \
of=$file bs=1 seek=$off conv=notrunc count=$siz 2>/dev/null
if [ $? -ne 0 ]; then return 1; fi
fi
return 0;
}
function main()
{
local args;
local file;
local name=builtin-cmdline;
local version=0.1.0;
while [ $# -gt 0 ]; do
case $1 in
-\? | --help)
help $name $version; return 1;
;;
--version)
echo "$name $version"; return 1;
;;
*)
if [ -z "$file" ]; then
file="$1"; shift;
elif [ -z "$args" ]; then
args="$1"; shift;
else
help $name $version; return 1;
fi
;;
esac
done
[ -z "$file" ] && {
help $name $version; return 1;
}
work "$file" "$args" || {
echo "bailing out because of errors"; return 1;
}
return 0;
}
main "$@";
exit $?;
^ permalink raw reply
* Re: [PATCH] Convert to mac-address for ethernet MAC address data.
From: Jon Loeliger @ 2006-08-03 21:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <0D9BEF4A-F8A5-42C5-9962-8C88322C9F50@kernel.crashing.org>
On Thu, 2006-08-03 at 16:49, Kumar Gala wrote:
> >
> > - mac_addr = get_property(np, "address", NULL);
> > - memcpy(gfar_data.mac_addr, mac_addr, 6);
> > + mac_addr = get_property(np, "local-mac-address", NULL);
>
> If "mac-address" the preferred mechanism, why dont we check for it
> first?
It's not. "local-mac-address" is. But that is HW specific.
SW version comes in as "mac-address". Here's what was said
earlier by Paul Nasrat:
Well I'm biased and say we shouldn't reinvent the wheel
with dtc if we don't need to. I've sent Jon a patch to
start validating this for dtc and am waiting feedback
before I add additional device_types. So we should have
local-mac-address be preassiged hwaddr and mac-address last
used. For some setups this would be the same persistently,
but I can envisage some non OF setups populating mac-address
from the card.
Paul
Which I interpreted to mean the order: local-mac-address first,
mac-address next, and the obsolete one, "address" last.
jdl
^ permalink raw reply
* Re: USB problem on MPC8349 (MPH0-ULPI)
From: Kumar Gala @ 2006-08-03 21:50 UTC (permalink / raw)
To: Srinivasa Hebbar; +Cc: linuxppc-embedded
In-Reply-To: <200608032101.23547.sshebbar@gmail.com>
On Aug 3, 2006, at 10:31 AM, Srinivasa Hebbar wrote:
>
> Hello,
>
> On MPC8349 sys board, I am getting following error when
> I connect the USB mass storage device.
>
> I am using MPH0 in ULPI mode.
>
> The driver doesn't detect any USB device.
>
> Any help to solve this problem is appreciated.
>
> The configuration and details of the board is given at
> the end of this mail.
[snip]
>> Operating System: Linux 2.6.11 (Freescale BSP downloaded from
>> metrowerks/freescale website).
I'd suggest using a stock 2.6.17 kernel or take the issue up with
Freescale since you are running a kernel from them.
- kumar
^ permalink raw reply
* Re: [PATCH] Convert to mac-address for ethernet MAC address data.
From: Kumar Gala @ 2006-08-03 21:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154640338.26770.34.camel@cashmere.sps.mot.com>
On Aug 3, 2006, at 4:25 PM, Jon Loeliger wrote:
> onvert to mac-address for ethernet MAC address data.
>
> Also accept "local-mac-address". However the old "address"
> is now obsolete, but accepted for backwards compatibility.
> It should be removed after all device trees have been
> converted to use "mac-address".
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 10 +++++-----
> arch/powerpc/sysdev/fsl_soc.c | 12 ++++++++++--
> 2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index 3c62e66..8c48b8a 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1196,7 +1196,7 @@ platforms are moved over to use the flat
> - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
> - compatible : Should be "gianfar"
> - reg : Offset and length of the register set for the device
> - - address : List of bytes representing the ethernet address of
> + - mac-address : List of bytes representing the ethernet
> address of
> this controller
> - interrupts : <a b> where a is the interrupt number and b is a
> field that represents an encoding of the sense and level
> @@ -1216,7 +1216,7 @@ platforms are moved over to use the flat
> model = "TSEC";
> compatible = "gianfar";
> reg = <24000 1000>;
> - address = [ 00 E0 0C 00 73 00 ];
> + mac-address = [ 00 E0 0C 00 73 00 ];
> interrupts = <d 3 e 3 12 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452000>
> @@ -1498,7 +1498,7 @@ not necessary as they are usually the sa
> model = "TSEC";
> compatible = "gianfar";
> reg = <24000 1000>;
> - address = [ 00 E0 0C 00 73 00 ];
> + mac-address = [ 00 E0 0C 00 73 00 ];
> interrupts = <d 3 e 3 12 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452000>;
> @@ -1511,7 +1511,7 @@ not necessary as they are usually the sa
> model = "TSEC";
> compatible = "gianfar";
> reg = <25000 1000>;
> - address = [ 00 E0 0C 00 73 01 ];
> + mac-address = [ 00 E0 0C 00 73 01 ];
> interrupts = <13 3 14 3 18 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452001>;
> @@ -1524,7 +1524,7 @@ not necessary as they are usually the sa
> model = "FEC";
> compatible = "gianfar";
> reg = <26000 1000>;
> - address = [ 00 E0 0C 00 73 02 ];
> + mac-address = [ 00 E0 0C 00 73 02 ];
> interrupts = <19 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452002>;
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
> fsl_soc.c
> index 4a6aa64..92ba378 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -166,8 +166,16 @@ static int __init gfar_of_init(void)
> goto err;
> }
>
> - mac_addr = get_property(np, "address", NULL);
> - memcpy(gfar_data.mac_addr, mac_addr, 6);
> + mac_addr = get_property(np, "local-mac-address", NULL);
If "mac-address" the preferred mechanism, why dont we check for it
first?
> + if (mac_addr == NULL)
> + mac_addr = get_property(np, "mac-address", NULL);
> + if (mac_addr == NULL) {
> + /* Obsolete */
> + mac_addr = get_property(np, "address", NULL);
> + }
> +
> + if (mac_addr)
> + memcpy(gfar_data.mac_addr, mac_addr, 6);
>
> if (model && !strcasecmp(model, "TSEC"))
> gfar_data.device_flags =
> --
> 2006_06_07.01.gittree_pull-dirty
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: DMA Driver on MPC8260
From: jimmy liu @ 2006-08-03 21:35 UTC (permalink / raw)
To: Manish Joshi, linuxppc-embedded
In-Reply-To: <20060803201848.45985.qmail@web34715.mail.mud.yahoo.com>
You are 100% right. MPC8260 has 4 DMA channels which
can be programmed independently. Could I find some
sample code from some place?
--- Manish Joshi <mjoshi_blr@yahoo.com> wrote:
> What kind of information you are looking for?
> Specific questions always help.
> General details you can find in the user manual
> itself.
>
> Not sure, but I think MPC8260 has 4 DMA channels
> which can be programmed independently. You need to
> set the mode registers and then the src/dest addr
> registers and byte count and finally turn on the
> start bit.
>
>
> jimmy liu <jimmyzhmliu@yahoo.com> wrote:
> I am working on PCI transactions between MPC8260
> and
> FPGA. Could somebody give me some information about
> the PCI DMA Driver on MPC8260?
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> ---------------------------------
> Want to be your own boss? Learn how on Yahoo! Small
> Business.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [PATCH Ver 2] Add MPC8641 HPCN Device Tree Source file.
From: Jon Loeliger @ 2006-08-03 21:27 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Subject: [PATCH] Add MPC8641 HPCN Device Tree Source file.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Uses "mac-address" instead of "address" in ethernet nodes.
Ignore my previous version of this patch.
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 338 ++++++++++++++++++++++++++++++++
1 files changed, 338 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
new file mode 100644
index 0000000..e832a88
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -0,0 +1,338 @@
+/*
+ * MPC8641 HPCN Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+
+/ {
+ model = "MPC8641HPCN";
+ compatible = "mpc86xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #cpus = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8641@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>; // From uboot
+ clock-frequency = <0>; // From uboot
+ 32-bit;
+ linux,boot-cpu;
+ };
+ PowerPC,8641@1 {
+ device_type = "cpu";
+ reg = <1>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>; // From uboot
+ clock-frequency = <0>; // From uboot
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 40000000>; // 1G at 0x0
+ };
+
+ soc8641@f8000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0 f8000000 00100000>;
+ reg = <f8000000 00100000>; // CCSRBAR 1M
+ bus-frequency = <0>;
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <40000>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3100 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <40000>;
+ dfsrr;
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ linux,phandle = <24520>;
+ ethernet-phy@0 {
+ linux,phandle = <2452000>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@1 {
+ linux,phandle = <2452001>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@2 {
+ linux,phandle = <2452002>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@3 {
+ linux,phandle = <2452003>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ mac-address = [ 00 E0 0C 00 73 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452000>;
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ mac-address = [ 00 E0 0C 00 73 01 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452001>;
+ };
+
+ ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <26000 1000>;
+ mac-address = [ 00 E0 0C 00 02 FD ];
+ interrupts = <1F 2 20 2 21 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452002>;
+ };
+
+ ethernet@27000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <27000 1000>;
+ mac-address = [ 00 E0 0C 00 03 FD ];
+ interrupts = <25 2 26 2 27 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452003>;
+ };
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <40000>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <1c 2>;
+ interrupt-parent = <40000>;
+ };
+
+ pci@8000 {
+ compatible = "86xx";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8000 1000>;
+ bus-range = <0 fe>;
+ ranges = <02000000 0 80000000 80000000 0 20000000
+ 01000000 0 00000000 e2000000 0 00100000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <40000>;
+ interrupts = <18 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x11 */
+ 8800 0 0 1 4d0 3 2
+ 8800 0 0 2 4d0 4 2
+ 8800 0 0 3 4d0 5 2
+ 8800 0 0 4 4d0 6 2
+
+ /* IDSEL 0x12 */
+ 9000 0 0 1 4d0 4 2
+ 9000 0 0 2 4d0 5 2
+ 9000 0 0 3 4d0 6 2
+ 9000 0 0 4 4d0 3 2
+
+ /* IDSEL 0x13 */
+ 9800 0 0 1 4d0 0 0
+ 9800 0 0 2 4d0 0 0
+ 9800 0 0 3 4d0 0 0
+ 9800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x14 */
+ a000 0 0 1 4d0 0 0
+ a000 0 0 2 4d0 0 0
+ a000 0 0 3 4d0 0 0
+ a000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 4d0 0 0
+ a800 0 0 2 4d0 0 0
+ a800 0 0 3 4d0 0 0
+ a800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x16 */
+ b000 0 0 1 4d0 0 0
+ b000 0 0 2 4d0 0 0
+ b000 0 0 3 4d0 0 0
+ b000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 4d0 0 0
+ b800 0 0 2 4d0 0 0
+ b800 0 0 3 4d0 0 0
+ b800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x18 */
+ c000 0 0 1 4d0 0 0
+ c000 0 0 2 4d0 0 0
+ c000 0 0 3 4d0 0 0
+ c000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x19 */
+ c800 0 0 1 4d0 0 0
+ c800 0 0 2 4d0 0 0
+ c800 0 0 3 4d0 0 0
+ c800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1a */
+ d000 0 0 1 4d0 6 2
+ d000 0 0 2 4d0 3 2
+ d000 0 0 3 4d0 4 2
+ d000 0 0 4 4d0 5 2
+
+
+ /* IDSEL 0x1b */
+ d800 0 0 1 4d0 5 2
+ d800 0 0 2 4d0 0 0
+ d800 0 0 3 4d0 0 0
+ d800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1c */
+ e000 0 0 1 4d0 9 2
+ e000 0 0 2 4d0 a 2
+ e000 0 0 3 4d0 c 2
+ e000 0 0 4 4d0 7 2
+
+ /* IDSEL 0x1d */
+ e800 0 0 1 4d0 9 2
+ e800 0 0 2 4d0 a 2
+ e800 0 0 3 4d0 b 2
+ e800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1e */
+ f000 0 0 1 4d0 c 2
+ f000 0 0 2 4d0 0 0
+ f000 0 0 3 4d0 0 0
+ f000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1f */
+ f800 0 0 1 4d0 6 2
+ f800 0 0 2 4d0 0 0
+ f800 0 0 3 4d0 0 0
+ f800 0 0 4 4d0 0 0
+ >;
+ i8259@4d0 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ big-endian;
+ interrupts = <49 2>;
+ interrupt-parent = <40000>;
+ };
+
+ };
+ pic@40000 {
+ linux,phandle = <40000>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <40000 40000>;
+ built-in;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ interrupts = <
+ 10 2 11 2 12 2 13 2
+ 14 2 15 2 16 2 17 2
+ 18 2 19 2 1a 2 1b 2
+ 1c 2 1d 2 1e 2 1f 2
+ 20 2 21 2 22 2 23 2
+ 24 2 25 2 26 2 27 2
+ 28 2 29 2 2a 2 2b 2
+ 2c 2 2d 2 2e 2 2f 2
+ 30 2 31 2 32 2 33 2
+ 34 2 35 2 36 2 37 2
+ 38 2 39 2 2a 2 3b 2
+ 3c 2 3d 2 3e 2 3f 2
+ 48 1 49 2 4a 1
+ >;
+ interrupt-parent = <40000>;
+ };
+ };
+};
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Convert to mac-address for ethernet MAC address data.
From: Jon Loeliger @ 2006-08-03 21:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
onvert to mac-address for ethernet MAC address data.
Also accept "local-mac-address". However the old "address"
is now obsolete, but accepted for backwards compatibility.
It should be removed after all device trees have been
converted to use "mac-address".
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 10 +++++-----
arch/powerpc/sysdev/fsl_soc.c | 12 ++++++++++--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 3c62e66..8c48b8a 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1196,7 +1196,7 @@ platforms are moved over to use the flat
- model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
- compatible : Should be "gianfar"
- reg : Offset and length of the register set for the device
- - address : List of bytes representing the ethernet address of
+ - mac-address : List of bytes representing the ethernet address of
this controller
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
@@ -1216,7 +1216,7 @@ platforms are moved over to use the flat
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
- address = [ 00 E0 0C 00 73 00 ];
+ mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <d 3 e 3 12 3>;
interrupt-parent = <40000>;
phy-handle = <2452000>
@@ -1498,7 +1498,7 @@ not necessary as they are usually the sa
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
- address = [ 00 E0 0C 00 73 00 ];
+ mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <d 3 e 3 12 3>;
interrupt-parent = <40000>;
phy-handle = <2452000>;
@@ -1511,7 +1511,7 @@ not necessary as they are usually the sa
model = "TSEC";
compatible = "gianfar";
reg = <25000 1000>;
- address = [ 00 E0 0C 00 73 01 ];
+ mac-address = [ 00 E0 0C 00 73 01 ];
interrupts = <13 3 14 3 18 3>;
interrupt-parent = <40000>;
phy-handle = <2452001>;
@@ -1524,7 +1524,7 @@ not necessary as they are usually the sa
model = "FEC";
compatible = "gianfar";
reg = <26000 1000>;
- address = [ 00 E0 0C 00 73 02 ];
+ mac-address = [ 00 E0 0C 00 73 02 ];
interrupts = <19 3>;
interrupt-parent = <40000>;
phy-handle = <2452002>;
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 4a6aa64..92ba378 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -166,8 +166,16 @@ static int __init gfar_of_init(void)
goto err;
}
- mac_addr = get_property(np, "address", NULL);
- memcpy(gfar_data.mac_addr, mac_addr, 6);
+ mac_addr = get_property(np, "local-mac-address", NULL);
+ if (mac_addr == NULL)
+ mac_addr = get_property(np, "mac-address", NULL);
+ if (mac_addr == NULL) {
+ /* Obsolete */
+ mac_addr = get_property(np, "address", NULL);
+ }
+
+ if (mac_addr)
+ memcpy(gfar_data.mac_addr, mac_addr, 6);
if (model && !strcasecmp(model, "TSEC"))
gfar_data.device_flags =
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* Re: [PATCH] clean up pseries hcall interfaces
From: Geoff Levand @ 2006-08-03 21:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <17617.30304.366738.986854@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Geoff Levand writes:
>
>> Change the scope of some pSeries routines now called through
>> ppc_md to static.
>
> With this I get:
>
> CC arch/powerpc/platforms/pseries/lpar.o
> /home/paulus/kernel/powerpc/arch/powerpc/platforms/pseries/lpar.c:273: error: static declaration of ^[$B!F^[(BpSeries_lpar_hpte_insert^[$B!G^[(B follows non-static declaration
> include2/asm/mmu.h:254: error: previous declaration of ^[$B!F^[(BpSeries_lpar_hpte_insert^[$B!G^[(B was here
> make[3]: *** [arch/powerpc/platforms/pseries/lpar.o] Error 1
OK, thanks for checking it. As I mentioned in my original
mail, it just looked like there could be some cleanup done,
but I didn't test it. I'll take a look at it some more and
see if I can make a proper re-work.
-Geoff
^ permalink raw reply
* Re: [PATCH] pSeries hvsi char driver janitorial cleanup.
From: Alan Cox @ 2006-08-03 21:06 UTC (permalink / raw)
To: Linas Vepstas; +Cc: akpm, hollisbl, linux-kernel, linuxppc-dev
In-Reply-To: <20060803193643.GA10638@austin.ibm.com>
Ar Iau, 2006-08-03 am 14:36 -0500, ysgrifennodd Linas Vepstas:
> Andrew,
> Please apply.
>
> A set of tty line discipline cleanup patches were introduced
> before the dawn of time, in kernel version 2.4.21. This patch
> performs that cleanup for the hvsi driver.
Actually its also a bug fix, tty->ldisc should be locked by refcounting
and the helpers do this for you.
Acked-by: Alan Cox <alan@redhat.com>
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Matthew McClintock @ 2006-08-03 20:40 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20060803202557.28DED35360F@atlas.denx.de>
On Thu, 2006-08-03 at 22:25 +0200, Wolfgang Denk wrote:
> In message <1154636438.5094.45.camel@localhost> you wrote:
> >
> > However, currently the zImage has an elfheader which will come before
>
> May it have whatever it wants. It's irrelevant.
>
> WE DO NOT USE zImage FILES FOR U-BOOT.
I've explained this well enough at this point, if you don't want to ask
more questions to figure it out then I can not really help anymore.
>
> > > This way U-Boot will load (and if necessary uncompress) the kernel
> > > image plus your attached bootstrap code to it's normal start address.
> > > Then it starts your bootstrap code which can fixup DTB and then just
> > > start the kernel.
> > >
> >
> > We do not need to worry about this with cuImage because the kernel
> > section will not be compressed. If compression is desired it will be
> > done at the U-Boot level (were U-Boot would do the uncompressing).
>
> Yes, we do need to care about this. A useless copy of the
> uncompressed kernel image is just a waste of boot time. Not to
> mention that you have to copy your bootstrapo loader out of the way
> before it gets overwritten.
I agree. Your previous advice is something I am going to try to reduce
memory copying. Keeping the bootloader after the kernel image should
prevent any overwritting problems, as you said.
-Matthew
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Matthew McClintock @ 2006-08-03 20:31 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20060803202325.4566C352660@atlas.denx.de>
On Thu, 2006-08-03 at 22:23 +0200, Wolfgang Denk wrote:
> > I'm referring to the zImage target as what the current method does.
> My
>
> This is highly confusing. zImage is a special make target, which has
> NOTHING to do with U-Boot. Please don't use this name in the U-Boot
> context unleass you really mean it.
>
AFAIK, there are no other targets that include the bootwrapper code
other than zImage. It was a very nice starting point for me to explain
the differences. If you don't want to ask questions and have me try to
further clarify things I cannot help.
The 'cuImage' target as I described is *basically* the following:
$ make zImage
$ mkimage -A ppc -O linux -T kernel -C gzip -a 400000 -e 400010 -n
'Linux-2.6.18' -d arch/powerpc/boot/zImage arch/powerpc/boot/cuImage
> > The zImage can have a compressed kernel section or an uncompressed
>
> I stop parsing here. zImage has *nothing* to do with this topic.
Your loss.
-Matthew
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-03 20:25 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154636438.5094.45.camel@localhost>
In message <1154636438.5094.45.camel@localhost> you wrote:
>
> However, currently the zImage has an elfheader which will come before
May it have whatever it wants. It's irrelevant.
WE DO NOT USE zImage FILES FOR U-BOOT.
> > This way U-Boot will load (and if necessary uncompress) the kernel
> > image plus your attached bootstrap code to it's normal start address.
> > Then it starts your bootstrap code which can fixup DTB and then just
> > start the kernel.
> >
>
> We do not need to worry about this with cuImage because the kernel
> section will not be compressed. If compression is desired it will be
> done at the U-Boot level (were U-Boot would do the uncompressing).
Yes, we do need to care about this. A useless copy of the
uncompressed kernel image is just a waste of boot time. Not to
mention that you have to copy your bootstrapo loader out of the way
before it gets overwritten.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is research but a blind date with knowledge? -- Will Harvey
^ permalink raw reply
* Re: DMA Driver on MPC8260
From: Manish Joshi @ 2006-08-03 20:18 UTC (permalink / raw)
To: jimmy liu, linuxppc-embedded
In-Reply-To: <20060803152112.13604.qmail@web53103.mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
What kind of information you are looking for? Specific questions always help.
General details you can find in the user manual itself.
Not sure, but I think MPC8260 has 4 DMA channels which can be programmed independently. You need to set the mode registers and then the src/dest addr registers and byte count and finally turn on the start bit.
jimmy liu <jimmyzhmliu@yahoo.com> wrote:
I am working on PCI transactions between MPC8260 and
FPGA. Could somebody give me some information about
the PCI DMA Driver on MPC8260?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
---------------------------------
Want to be your own boss? Learn how on Yahoo! Small Business.
[-- Attachment #2: Type: text/html, Size: 1285 bytes --]
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-03 20:23 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154635939.5094.37.camel@localhost>
In message <1154635939.5094.37.camel@localhost> you wrote:
>
> I'm referring to the zImage target as what the current method does. My
This is highly confusing. zImage is a special make target, which has
NOTHING to do with U-Boot. Please don't use this name in the U-Boot
context unleass you really mean it.
> The zImage can have a compressed kernel section or an uncompressed
I stop parsing here. zImage has *nothing* to do with this topic.
> As a side note, the final cuImage (which is a U-Boot image) can be
> either compressed or uncompressed. That is irrelevant. The major point
> is the kernel section within the cuImage is not compressed, and the
> final cuImage is in fact a U-Boot image which can be started with the
> 'bootm' command from within U-Boot.
As explained in a previous message, you should change the order of
parts (sections?) in your image. Put the kernel image first, and
attach your stuff at the end. This allows to use standard mechanisms,
keep all the existing flexibility and avoid useless memory copy.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Matthew McClintock @ 2006-08-03 20:20 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20060803201441.C8A89352660@atlas.denx.de>
On Thu, 2006-08-03 at 22:14 +0200, Wolfgang Denk wrote:
> Both approaches seem broken to me.
>
> You should make sure that your bootstrap code comes *after* the
> kernel image, so you can load the whole blob at address 0x0000
> (mkimage option "-a 0") while starting it at the bootstrap entry
> point (mkimage option "-e <your_address>").
However, currently the zImage has an elfheader which will come before
the code. But, since we are making a new target we don't actually need
to preserve this. I like this idea. I will look into it further.
>
> This way U-Boot will load (and if necessary uncompress) the kernel
> image plus your attached bootstrap code to it's normal start address.
> Then it starts your bootstrap code which can fixup DTB and then just
> start the kernel.
>
We do not need to worry about this with cuImage because the kernel
section will not be compressed. If compression is desired it will be
done at the U-Boot level (were U-Boot would do the uncompressing).
> Please avoid any aditional memory copy. It's not necessary.
>
Agreed.
-Matthew
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-03 20:14 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154622246.5094.18.camel@localhost>
In message <1154622246.5094.18.camel@localhost> you wrote:
>
> I'm not sure that is correct. Let me walk through the steps to verify.
>
> 1) Load cuImage at a load address
> 2) Extract zImage at an address and begin execution
> 3) Copy kernel to load address and fixup DTB, etc.
> 4) Start kernel execution
>
> versus...
>
> 1) Load cuImage at a load address
> 2) Copy zImage to an address and begin execution
> 3) Extract kernel to load address and fixup DTB, etc.
> 4) Start kernel execution
Both approaches seem broken to me.
You should make sure that your bootstrap code comes *after* the
kernel image, so you can load the whole blob at address 0x0000
(mkimage option "-a 0") while starting it at the bootstrap entry
point (mkimage option "-e <your_address>").
This way U-Boot will load (and if necessary uncompress) the kernel
image plus your attached bootstrap code to it's normal start address.
Then it starts your bootstrap code which can fixup DTB and then just
start the kernel.
Please avoid any aditional memory copy. It's not necessary.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"In Christianity neither morality nor religion come into contact with
reality at any point." - Friedrich Nietzsche
^ permalink raw reply
* [PATCH] pSeries hvsi char driver null pointer deref
From: Linas Vepstas @ 2006-08-03 20:13 UTC (permalink / raw)
To: akpm, hollisbl; +Cc: linuxppc-dev, linux-kernel
Andrew,
Please apply.
Under certain rare circumstances, it appears that there can be
be a NULL-pointer deref when a user fiddles with terminal
emeulation programs while outpu is being sent to the console.
This patch checks for and avoids a NULL-pointer deref.
Signed-off-by: Hollis Blanchard <hollisbl@austin.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/char/hvsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.18-rc3-git1/drivers/char/hvsi.c
===================================================================
--- linux-2.6.18-rc3-git1.orig/drivers/char/hvsi.c 2006-08-03 14:50:00.000000000 -0500
+++ linux-2.6.18-rc3-git1/drivers/char/hvsi.c 2006-08-03 14:51:46.000000000 -0500
@@ -311,7 +311,8 @@ static void hvsi_recv_control(struct hvs
/* CD went away; no more connection */
pr_debug("hvsi%i: CD dropped\n", hp->index);
hp->mctrl &= TIOCM_CD;
- if (!(hp->tty->flags & CLOCAL))
+ /* If userland hasn't done an open(2) yet, hp->tty is NULL. */
+ if (hp->tty && !(hp->tty->flags & CLOCAL))
*to_hangup = hp->tty;
}
break;
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Matthew McClintock @ 2006-08-03 20:12 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20060803200043.0EF78352660@atlas.denx.de>
On Thu, 2006-08-03 at 22:00 +0200, Wolfgang Denk wrote:
> > So to clarify. The current method has a zImage with a compressed
> kernel
>
> No, it does not. We do not use zImage (which includes bootstrap
> wrapper code). U-Boot uses a plain stripped and compressed kernel
> image, i. e. something like this:
>
> objcopy -O binary vmlinux vmlinux.bin
> gzip -f -9 <vmlinux.bin >vmlinux.gz
> mkimage ... -C gzip -d vmlinux.gz uImage
I'm referring to the zImage target as what the current method does. My
changes would in no way effect the current method of booting, with the
current method being a plain uImage target.
The zImage can have a compressed kernel section or an uncompressed
kernel section. The new 'cuImage' always has an uncompressed kernel
section and which is packaged in the U-Boot image format.
You might refer to the code in my original email for clarification. This
in no way effects the current method of booting, it simply adds a method
to package the bootwrapper + kernel + fdt to pass to old version of
U-Boot so they can use the new 'powerpc' kernels
As a side note, the final cuImage (which is a U-Boot image) can be
either compressed or uncompressed. That is irrelevant. The major point
is the kernel section within the cuImage is not compressed, and the
final cuImage is in fact a U-Boot image which can be started with the
'bootm' command from within U-Boot.
Phew!
-Matthew
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-03 20:07 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <a0bc9bf80608030917y7fde2b75n6719dc675cad8cfe@mail.gmail.com>
In message <a0bc9bf80608030917y7fde2b75n6719dc675cad8cfe@mail.gmail.com> you wrote:
>
> Though it will need more space, the increase won't be too much as
> wrapper and FDT should be very small. The benefit is that kernel can
> be extract directly to it's destination(address 0), rather than
> extract to another place and then move it there. A classical
> time/space tradeoff.
You probably cannot expect a perfect solution when retrofitting new
features into an old system (this we should keep in mind: we're
talking about old U-Boot versions only, not about current versions
which will support DT).
BTW: Another option is using U-Boot's multifile image format...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
That said, there may be good reasons for what you did beyond obsequi-
ous sycophantic parody. Perhaps you might be so kind as to elucidate.
-- Tom Christiansen in <5ldjbm$jtk$1@csnews.cs.colorado.edu>
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-03 20:02 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <a0bc9bf80608030856p45870487of2646c4f9393869b@mail.gmail.com>
In message <a0bc9bf80608030856p45870487of2646c4f9393869b@mail.gmail.com> you wrote:
>
> If U-boot supports uncompressed kernel image in uImage, I think it
> will be better to use this scheme:
>
> u-boot header + wrapper + FDT + compressed kernel image
No, this must not be made the only way to build images. It must also
possible to use uncompressed kernel images.
> As kernel image will be uncompressed to its loading address directly.
Only if it was compressed. This is NOT mandatory.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-03 20:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154618945.5094.6.camel@localhost>
In message <1154618945.5094.6.camel@localhost> you wrote:
>
> > In my understanding, an "uImage" file is a image consisting of an
> > U-Boot header (64 bytes) followed by an (compressed or uncompressed)
> > Linux kernel image.
>
> Yes
OK.
> I mean that the data contained within the uImage is compressed. In this
This is only one option. Some configurations prefer to use uncom-
pressed images because these canbe booted faster.
> case where the uImage data is compressed I choose to skip compressing
> the kernel section in the zImage (because have it compressed twice was
> wasteful)
We don't use zImage !
> So to clarify. The current method has a zImage with a compressed kernel
No, it does not. We do not use zImage (which includes bootstrap
wrapper code). U-Boot uses a plain stripped and compressed kernel
image, i. e. something like this:
objcopy -O binary vmlinux vmlinux.bin
gzip -f -9 <vmlinux.bin >vmlinux.gz
mkimage ... -C gzip -d vmlinux.gz uImage
> section where the actual kernel lives. The zImage uncompressed this code
> to the kernel load address. The 'cuImage' would be packaged in a uImage
> with the entire zImage compressed, except in this case the kernel
> section would not be compressed (to avoid have a compressed image within
> a compressed image)
You would have to create a new image type which has executable code
at the start and carries the kernel image as payload, similar to what
zImage does.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The shortest unit of time in the multiverse is the News York Second,
defined as the period of time between the traffic lights turning
green and the cab behind you honking.
- Terry Pratchett, _Lords and Ladies_
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Mark A. Greer @ 2006-08-03 19:37 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154620934.5094.12.camel@localhost>
On Thu, Aug 03, 2006 at 11:02:14AM -0500, Matthew McClintock wrote:
> On Thu, 2006-08-03 at 23:56 +0800, Li Yang wrote:
> >
> > If U-boot supports uncompressed kernel image in uImage, I think it
> > will be better to use this scheme:
> >
> > u-boot header + wrapper + FDT + compressed kernel image
> >
> > As kernel image will be uncompressed to its loading address directly.
> > While in your proposal, it needs to be moved one more time.
> >
>
> This is an option. But, I do not see a reason why you would not still
> opt to compress everything. Especially since it is already working.
> Comments anyone?
Yes...sort of. I believe that one of the goals is to be able to tack
an fdt onto a zImage/uImage/whatever long after that image has been
built. That would be simpler if the fdt wasn't compressed.
A proper tool can handle this, of course, but it would be simpler and
not a huge waste of space to keep the fdt uncompressed.
But, as long as we have tools to view and modify the fdt that in the
clump of bits, I don't really care that much.
Mark
^ permalink raw reply
* [PATCH] pSeries hvsi char driver janitorial cleanup.
From: Linas Vepstas @ 2006-08-03 19:36 UTC (permalink / raw)
To: akpm, hollisbl; +Cc: linuxppc-dev, linux-kernel
Andrew,
Please apply.
A set of tty line discipline cleanup patches were introduced
before the dawn of time, in kernel version 2.4.21. This patch
performs that cleanup for the hvsi driver.
The hvsi driver is used only on IBM pSeries PowerPC boxes.
The driver was originally written by Hollis Blanchard, who
has delegated maintainership to me. So this my first and
maybe only patch in this official new role, because this
driver is otherwise bug-free :-)
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/char/hvsi.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
Index: linux-2.6.18-rc3-git1/drivers/char/hvsi.c
===================================================================
--- linux-2.6.18-rc3-git1.orig/drivers/char/hvsi.c 2006-08-01 14:26:38.000000000 -0500
+++ linux-2.6.18-rc3-git1/drivers/char/hvsi.c 2006-08-01 15:03:12.000000000 -0500
@@ -986,10 +986,7 @@ static void hvsi_write_worker(void *arg)
start_j = 0;
#endif /* DEBUG */
wake_up_all(&hp->emptyq);
- if (test_bit(TTY_DO_WRITE_WAKEUP, &hp->tty->flags)
- && hp->tty->ldisc.write_wakeup)
- hp->tty->ldisc.write_wakeup(hp->tty);
- wake_up_interruptible(&hp->tty->write_wait);
+ tty_wakeup(hp->tty);
}
out:
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Mark A. Greer @ 2006-08-03 19:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17616.17129.964122.125259@cargo.ozlabs.ibm.com>
On Wed, Aug 02, 2006 at 04:15:05PM +1000, Paul Mackerras wrote:
> I wrote:
>
> > The ops structure seems like a reasonable concept, but I question
> > whether we need to have platform_ops separate from fw_ops, since the
> > firmware is essentially part of the implementation of the platform.
> > Also I don't see why we need to do a double indirection to get to each
> > ops function.
>
> Thinking about this a bit more, why do we need the indirect function
> calls at all? Do we ever want to be able to choose (e.g.) one of
> several possible console implementations at runtime? Don't we know at
> compile time which one we will be using, and thus can't we use the
> linker to make the necessary linkages?
Hi Paul,
I realize that I didn't really answer your question. Its at least
possible that the console driver could not be known at link time.
An example I used in another email is a platform that has 4 serial
ports, 2-16550 and 2-mpsc, say. The /chosen/linux,stdout-path could
pick any of the four so you would need to compile in a low-level
serial driver for both and hook the correct one up at runtime.
Same could be said for a serial vs. video console.
At least for now, I'd like to keep the flexibility. Once things
settle down we can take another look to see what was is really
necessary and what's overkill.
Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox