* Re: [FDT][PATCH] Fix padding options
From: Jon Loeliger @ 2007-12-05 14:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0712041734580.1979@blarg.am.freescale.net>
So, like, the other day Kumar Gala mumbled:
> "Add an option to pad the blob that is generated" broke the padding
> support. We were updating the fdt header after writing it.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
jdl
^ permalink raw reply
* Re: dtc: Implement path references
From: Jon Loeliger @ 2007-12-05 14:47 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071204234350.GE9487@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch extends dtc syntax to allow references (&label, or
> &{/full/path}) directly within property definitions, rather than
> inside a cell list. Such references are expanded to the full path of
> the referenced node, as a string, instead of to a phandle as
> references within cell lists are evaluated.
>
> A testcase is also included.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Excellent. Very timely! :-)
Applied.
jdl
^ permalink raw reply
* Re: [PATCH v2 1/4] [libata] pata_platform: make probe and remove functions device type neutral
From: Anton Vorontsov @ 2007-12-05 15:37 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Olof Johansson, Paul Mundt, Arnd Bergmann, Jeff Garzik
In-Reply-To: <20071204170625.GA15599@localhost.localdomain>
On Tue, Dec 04, 2007 at 08:06:25PM +0300, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
Paul, do you have any objections regarding that one?
If there is no objections, could you stamp Acked-by on it?
Thus I can resend this set one more time for the merge, w/o
fourth patch.
> /**
> - * pata_platform_probe - attach a platform interface
> - * @pdev: platform device
> + * __pata_platform_probe - attach a platform interface
> + * @dev: device
> + * @io_res: Resource representing I/O base
> + * @ctl_res: Resource representing CTL base
> + * @irq_res: Resource representing IRQ and its flags
> + * @ioport_shift: I/O port shift
+ * @__pio_mask: PIO mask
^^^ added
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Kernel symbol version history
From: David H. Lynch Jr. @ 2007-12-05 16:17 UTC (permalink / raw)
To: linuxppc-embedded
This might be slightly OT here, but would anyone know where there
might be a reference that indicates at precisely what version a given
symbol either appeared or disappeared within the Linux kernel ?
As an example if a driver is supposed to work for 2.6 and 2.4 and
uses sysfs, or cdev, or alloc_chr_dev_region or ...
How can one tell at what point that api or symbol appeared so that
the proper conditionals appear within the driver.
The last one that bit me was I made a collection of casting changes
to address 64bit vs. 32bit targets, and found that using the C99 fixed
size types - uint32_t, ... made life much more pleasant, after putting
them I nobody else could build because uintptr_t did not appear until
2.6.24, and I still have not figured out exactly when uint32_t etc.
appeared.
I would think there ought to be some resource besides group memory
to look this up ?
Is there a way to use git to look back through the history of a
symbol rather than a file.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Kernel symbol version history
From: Grant Likely @ 2007-12-05 16:49 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <4756CF15.2090805@dlasys.net>
On 12/5/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> This might be slightly OT here, but would anyone know where there
> might be a reference that indicates at precisely what version a given
> symbol either appeared or disappeared within the Linux kernel ?
>
> As an example if a driver is supposed to work for 2.6 and 2.4 and
> uses sysfs, or cdev, or alloc_chr_dev_region or ...
> How can one tell at what point that api or symbol appeared so that
> the proper conditionals appear within the driver.
the 'gitk' tool allows you to search for the addition or removal of a
string. You
>
> The last one that bit me was I made a collection of casting changes
> to address 64bit vs. 32bit targets, and found that using the C99 fixed
> size types - uint32_t, ... made life much more pleasant, after putting
> them I nobody else could build because uintptr_t did not appear until
> 2.6.24, and I still have not figured out exactly when uint32_t etc.
> appeared.
>
> I would think there ought to be some resource besides group memory
> to look this up ?
> Is there a way to use git to look back through the history of a
> symbol rather than a file.
grant@trillian:~/hacking/linux-2.6$ grep "uint32_t" include/* -r | grep typedef
include/linux/types.h:typedef __u32 uint32_t;
grant@trillian:~/hacking/linux-2.6$ git log -p include/linux/types.h | vim -
(Search for the string uint32_t)
Looks like it was there before Linus started using git.
>
>
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too numerous to list.
>
> "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
> Albert Einstein
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ucc_uart: add support for Freescale QUICCEngine UART
From: Timur Tabi @ 2007-12-05 17:06 UTC (permalink / raw)
To: Arnd Bergmann, PowerPC dev list
In-Reply-To: <200712050037.11489.arnd@arndb.de>
Arnd Bergmann wrote:
> In that case, I think the right solution would be to have different properties
> in the device tree, depending on whether or not you have a soft-uart and whether
> you need to download the microcode.
> Having only a compile time option is very bad because it prevents you from
> using the driver on a multi-platform kernel.
I can see putting the option to need Soft-UART in the device, because this is an
attribute of the hardware. The silicon is broken and UART functionality is
provided via a secondary mechanism.
I'm not so crazy about an option to tell the driver to upload the firmware. So
look at this:
ucc@2400 {
device_type = "serial";
compatible = "ucc_uart";
model = "UCC";
device-id = <5>; /* The UCC number, 1-7*/
port-number = <0>; /* Which ttyQEx device */
soft-uart; /* We need Soft-UART */
upload-firmware; /* Driver should upload FW */
...
In a sense, this is just a message from U-Boot to the driver. It's not really
an attribute of the hardware.
One thing I could do is create a new node under the QE node that describes any
uploaded microcode. The nature of the QE microcode is that only one can be
present at any time. So I could do this:
qe@e0100000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "qe";
model = "QE";
ranges = <0 e0100000 00100000>;
...
microcode@100 { /* 100 is offset within I-RAM where the microcode was uploaded */
name = "Soft-UART";
extended_modes = <0 0>;
vtraps = <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
}
The extended_modes and vtraps are data that the driver needs any way (for
Soft-UART, it's all zeros, but not for other microcodes). I currently don't
have a way to pass this information from U-Boot to the kernel. The driver could
then look for this node, and if it finds it, it would know *not* to try to
upload the microcode itself. And it would also have the extended_modes and
vtraps information that it might need.
This would solve your problem and mine.
> gcc tries to use only aligned accesses, depending on the the target CPU, so
> you may end up accessing a member as bytes instead of words.
Would it do that even if the member were naturally aligned? I find that hard to
believe, since the compiler always knows the alignment of its members.
OTOH, if this
> structure is always in __iomem and you use in_be32() and the like, there is
> no problem at all.
I do. I generally only pack structures that are defined by external hardware,
and this is one.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Kernel symbol version history
From: Jean-Christophe Dubois @ 2007-12-05 17:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4756CF15.2090805@dlasys.net>
Hi David,
You could try the various "linux cross reference" web site out there. It is
not necessarily complete (some linux version might be missing) but it can be
usefull to lookup if some symbols/define/typedef were available in a
particular Linux version.
Have a look there.
http://free-electrons.com/community/kernel/lxr
Regards
JC
On Wednesday 05 December 2007 17:17:25 David H. Lynch Jr. wrote:
> This might be slightly OT here, but would anyone know where there
> might be a reference that indicates at precisely what version a given
> symbol either appeared or disappeared within the Linux kernel ?
>
> As an example if a driver is supposed to work for 2.6 and 2.4 and
> uses sysfs, or cdev, or alloc_chr_dev_region or ...
> How can one tell at what point that api or symbol appeared so that
> the proper conditionals appear within the driver.
>
> The last one that bit me was I made a collection of casting changes
> to address 64bit vs. 32bit targets, and found that using the C99 fixed
> size types - uint32_t, ... made life much more pleasant, after putting
> them I nobody else could build because uintptr_t did not appear until
> 2.6.24, and I still have not figured out exactly when uint32_t etc.
> appeared.
>
> I would think there ought to be some resource besides group memory
> to look this up ?
> Is there a way to use git to look back through the history of a
> symbol rather than a file.
^ permalink raw reply
* Re: Regarding MPC8641D
From: Christopher Fester @ 2007-12-05 17:06 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <14166848.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
On Tue, 2007-12-04 at 23:51 -0800, sivaji wrote:
> We have designed a MPC8641D based AMC card. We are using the
> kernel (2.6.23-rc4) and uboot (1.2.0). When we disable the core1 Low Memory
> offset mode the kernel was up and when we enable this core1 Low Memory
> offset mode kernel was not up, It was hang after MPIC initialization.
[snip!]
> After this the kernel was hang, i want to know why
> kernel was hang when we enalbe Low memory Offset mode. Please help me to fix
> this issue.
Have you compiled your kernel for SMP mode? I believe the Low memory
offset mode is only for AMP mode (vxworks can use this, probably other
OSes). I don't know if the kernel has support for any multiprocessing
mode other than SMP.
Hope that helps,
Chris
[-- Attachment #2: Type: text/html, Size: 1438 bytes --]
^ permalink raw reply
* [PATCH] Add aliases node to 8641hpcn DTS file.
From: Jon Loeliger @ 2007-12-05 17:32 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
The addition of the aliases node is needed for U-Boot
and, eventually, cuImage, to help locate the proper
nodes reliably when using the libfdt approach.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 28 ++++++++++++++++++++--------
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index abb26dc..b039f21 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -16,6 +16,17 @@
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -107,7 +118,7 @@
};
};
- ethernet@24000 {
+ enet0: ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -127,7 +138,7 @@
phy-connection-type = "rgmii-id";
};
- ethernet@25000 {
+ enet1: ethernet@25000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -147,7 +158,7 @@
phy-connection-type = "rgmii-id";
};
- ethernet@26000 {
+ enet2: ethernet@26000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -167,7 +178,7 @@
phy-connection-type = "rgmii-id";
};
- ethernet@27000 {
+ enet3: ethernet@27000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -186,7 +197,8 @@
phy-handle = <&phy3>;
phy-connection-type = "rgmii-id";
};
- serial@4500 {
+
+ serial0: serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
@@ -195,7 +207,7 @@
interrupt-parent = <&mpic>;
};
- serial@4600 {
+ serial1: serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>;
@@ -222,7 +234,7 @@
};
};
- pcie@f8008000 {
+ pci0: pcie@f8008000 {
compatible = "fsl,mpc8641-pcie";
device_type = "pci";
#interrupt-cells = <1>;
@@ -430,7 +442,7 @@
};
- pcie@f8009000 {
+ pci1: pcie@f8009000 {
compatible = "fsl,mpc8641-pcie";
device_type = "pci";
#interrupt-cells = <1>;
--
1.5.2.1.126.g6abd0
^ permalink raw reply related
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Grant Likely @ 2007-12-05 17:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196875970.8544.12.camel@ld0161-tx32>
On 12/5/07, Jon Loeliger <jdl@freescale.com> wrote:
>
> The addition of the aliases node is needed for U-Boot
> and, eventually, cuImage, to help locate the proper
> nodes reliably when using the libfdt approach.
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 28 ++++++++++++++++++++--------
> 1 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index abb26dc..b039f21 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -16,6 +16,17 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + aliases {
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> + ethernet3 = &enet3;
> + serial0 = &serial0;
> + serial1 = &serial1;
> + pci0 = &pci0;
> + pci1 = &pci1;
> + };
I had thought aliases were supposed to be full paths to nodes instead
of phandles. Was I wrong?
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -107,7 +118,7 @@
> };
> };
>
> - ethernet@24000 {
> + enet0: ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -127,7 +138,7 @@
> phy-connection-type = "rgmii-id";
> };
>
> - ethernet@25000 {
> + enet1: ethernet@25000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -147,7 +158,7 @@
> phy-connection-type = "rgmii-id";
> };
>
> - ethernet@26000 {
> + enet2: ethernet@26000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -167,7 +178,7 @@
> phy-connection-type = "rgmii-id";
> };
>
> - ethernet@27000 {
> + enet3: ethernet@27000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -186,7 +197,8 @@
> phy-handle = <&phy3>;
> phy-connection-type = "rgmii-id";
> };
> - serial@4500 {
> +
> + serial0: serial@4500 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <4500 100>;
> @@ -195,7 +207,7 @@
> interrupt-parent = <&mpic>;
> };
>
> - serial@4600 {
> + serial1: serial@4600 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <4600 100>;
> @@ -222,7 +234,7 @@
> };
> };
>
> - pcie@f8008000 {
> + pci0: pcie@f8008000 {
> compatible = "fsl,mpc8641-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> @@ -430,7 +442,7 @@
>
> };
>
> - pcie@f8009000 {
> + pci1: pcie@f8009000 {
> compatible = "fsl,mpc8641-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> --
> 1.5.2.1.126.g6abd0
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: Scott Wood @ 2007-12-05 17:46 UTC (permalink / raw)
To: michael.firth; +Cc: linuxppc-embedded
In-Reply-To: <36D7B34A3A79F84F82FA0C154F299F2506080F6F@E03MVX1-UKDY.domain1.systemhost.net>
michael.firth@bt.com wrote:
> My main queries are: 1) Why did changing the kernel base address to
> 0x80000000 make the system unstable?
Because there's a bug somewhere. :-)
> 2) Currently IMMRBAR has the same physical and virtual address. Does
> this need to be the case?
No, and it is not done that way in arch/powerpc.
> 3) Why the kernel is designed to run at 0xc0000000?
My guess is because it's a number that Linus pulled out of thin air back
when a gig of RAM was unimaginably large. :-P
> This seems to leave only 1GB of addressing space for all the
> physically addressable memory (RAM + ioremapped + registers), while
> reserving 3GB of space for user processes. The 3GB is presumably
> mostly unusable on a system without a large amount of swap, as the
> 1GB limit on memory will prevent much more than that being available
> for user space.
Well, it's also useful for sparse mappings, but I agree that the 3/1
split is probably suboptimal for most workloads.
-Scott
^ permalink raw reply
* RE: [PATCH v2] [POWERPC] Optimize counting distinct entries in the relocation sections
From: Medve Emilian @ 2007-12-05 17:47 UTC (permalink / raw)
To: paulus, rusty, ntl, sfr, behlendorf1, galak, linuxppc-dev,
linuxppc-embedded
In-Reply-To: <1194971044-28840-1-git-send-email-Emilian.Medve@Freescale.com>
> -----Original Message-----
> From: Medve Emilian=20
> Sent: Tuesday, November 13, 2007 10:24 AM
> To: paulus@samba.org; rusty@rustcorp.com.au; ntl@pobox.com;
sfr@canb.auug.org.au; behlendorf1@llnl.gov; galak@kernel.crashing.org;
linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Cc: Medve Emilian
> Subject: [PATCH v2] [POWERPC] Optimize counting distinct entries in
the relocation sections
Hello Paul,
I don't mean to annoy you, but I seem not to be sure if this patch
(http://patchwork.ozlabs.org/linuxppc/patch?id=3D14707) got rejected or
not.
Thanks,
Emil.
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: Scott Wood @ 2007-12-05 17:50 UTC (permalink / raw)
To: michael.firth; +Cc: linuxppc-embedded
In-Reply-To: <4756E3E8.8090102@freescale.com>
Scott Wood wrote:
> michael.firth@bt.com wrote:
>> This seems to leave only 1GB of addressing space for all the
>> physically addressable memory (RAM + ioremapped + registers), while
>> reserving 3GB of space for user processes. The 3GB is presumably
>> mostly unusable on a system without a large amount of swap, as the
>> 1GB limit on memory will prevent much more than that being available
>> for user space.
>
> Well, it's also useful for sparse mappings, but I agree that the 3/1
> split is probably suboptimal for most workloads.
Oh, and the 3G user is also useful for accessing highmem, of course.
-Scott
^ permalink raw reply
* Uboot and ML410
From: khollan @ 2007-12-05 18:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Is there a patch to include support for the ml410 in the Main git tree of
u-boot? I tried compiling Xilinx's tree but it seems it won't compile
correctly with my version of make (3.81). Also is there any support for the
Hard TEMAC in u-boot? I tried looking for both of these questions but a lot
of the threads were unanswered questions. Thanks for your help
kholland
--
View this message in context: http://www.nabble.com/Uboot-and-ML410-tf4951335.html#a14177109
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Jon Loeliger @ 2007-12-05 18:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <fa686aa40712050938j2d286655o94534a00131872e2@mail.gmail.com>
On Wed, 2007-12-05 at 11:38, Grant Likely wrote:
> >
> > + aliases {
> > + ethernet0 = &enet0;
> > + ethernet1 = &enet1;
> > + ethernet2 = &enet2;
> > + ethernet3 = &enet3;
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + pci0 = &pci0;
> > + pci1 = &pci1;
> > + };
>
> I had thought aliases were supposed to be full paths to nodes instead
> of phandles. Was I wrong?
Indeed, that is correct. And they are!
=> fdt addr c00000
=> fdt print /aliases
aliases {
ethernet0 = "/soc8641@f8000000/ethernet@24000";
ethernet1 = "/soc8641@f8000000/ethernet@25000";
ethernet2 = "/soc8641@f8000000/ethernet@26000";
ethernet3 = "/soc8641@f8000000/ethernet@27000";
serial0 = "/soc8641@f8000000/serial@4500";
serial1 = "/soc8641@f8000000/serial@4600";
pci0 = "/pcie@f8008000";
pci1 = "/pcie@f8009000";
};
=> bootm 1000000 - c00000
Grant, you need to keep up, man. Just this morning
I pushed Gibson's patch to DTC to support this. :-)
jdl
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Vitaly Bordug @ 2007-12-05 18:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <fa686aa40712050938j2d286655o94534a00131872e2@mail.gmail.com>
On Wed, 5 Dec 2007 10:38:38 -0700
Grant Likely wrote:
> >
> > + aliases {
> > + ethernet0 = &enet0;
> > + ethernet1 = &enet1;
> > + ethernet2 = &enet2;
> > + ethernet3 = &enet3;
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + pci0 = &pci0;
> > + pci1 = &pci1;
> > + };
>
> I had thought aliases were supposed to be full paths to nodes instead
> of phandles. Was I wrong?
no, but dwg did a patch for dtc to do that dirty work for you, resolving labels. I am also curious if such a change made it in
dtc git (working with full path aliases now). dtc should prolly get tagged and next sub-rev to be clear if it supports aliases or not.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Grant Likely @ 2007-12-05 18:15 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196877907.8544.15.camel@ld0161-tx32>
On 12/5/07, Jon Loeliger <jdl@freescale.com> wrote:
> On Wed, 2007-12-05 at 11:38, Grant Likely wrote:
> > I had thought aliases were supposed to be full paths to nodes instead
> > of phandles. Was I wrong?
>
> Indeed, that is correct. And they are!
>
> Grant, you need to keep up, man. Just this morning
> I pushed Gibson's patch to DTC to support this. :-)
Heh; I'm so behind. Thanks for the clarification.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Uboot and ML410
From: Grant Likely @ 2007-12-05 18:16 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <14177109.post@talk.nabble.com>
On 12/5/07, khollan <khollan@daktronics.com> wrote:
>
> Hi
>
> Is there a patch to include support for the ml410 in the Main git tree of
> u-boot? I tried compiling Xilinx's tree but it seems it won't compile
> correctly with my version of make (3.81).
I don't think there is.
> Also is there any support for the
> Hard TEMAC in u-boot? I tried looking for both of these questions but a lot
> of the threads were unanswered questions. Thanks for your help
No, unfortunately nobody has got a hard TEMAC driver into u-boot mainline.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Josh Boyer @ 2007-12-05 18:31 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196877907.8544.15.camel@ld0161-tx32>
On Wed, 05 Dec 2007 12:05:07 -0600
Jon Loeliger <jdl@freescale.com> wrote:
> On Wed, 2007-12-05 at 11:38, Grant Likely wrote:
>
> > >
> > > + aliases {
> > > + ethernet0 = &enet0;
> > > + ethernet1 = &enet1;
> > > + ethernet2 = &enet2;
> > > + ethernet3 = &enet3;
> > > + serial0 = &serial0;
> > > + serial1 = &serial1;
> > > + pci0 = &pci0;
> > > + pci1 = &pci1;
> > > + };
> >
> > I had thought aliases were supposed to be full paths to nodes instead
> > of phandles. Was I wrong?
>
> Indeed, that is correct. And they are!
>
> => fdt addr c00000
> => fdt print /aliases
> aliases {
> ethernet0 = "/soc8641@f8000000/ethernet@24000";
> ethernet1 = "/soc8641@f8000000/ethernet@25000";
> ethernet2 = "/soc8641@f8000000/ethernet@26000";
> ethernet3 = "/soc8641@f8000000/ethernet@27000";
> serial0 = "/soc8641@f8000000/serial@4500";
> serial1 = "/soc8641@f8000000/serial@4600";
> pci0 = "/pcie@f8008000";
> pci1 = "/pcie@f8009000";
> };
> => bootm 1000000 - c00000
>
> Grant, you need to keep up, man. Just this morning
> I pushed Gibson's patch to DTC to support this. :-)
So now the in-kernel version of DTC needs to support this.
josh
^ permalink raw reply
* Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Scott Wood @ 2007-12-05 18:39 UTC (permalink / raw)
To: Paul Mundt
Cc: Olof Johansson, linux-ide, Jeff Garzik, Arnd Bergmann,
linuxppc-dev
In-Reply-To: <20071205004841.GA25905@linux-sh.org>
On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote:
> On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > > tristate "Generic platform device PATA support"
> > > - depends on EMBEDDED || ARCH_RPC
> > > + depends on EMBEDDED || ARCH_PPC
> >
> > It needs to be || PPC, not || ARCH_PPC.
> >
> Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC.
Why is it dependent on anything other than platform bus support and ATA?
-Scott
^ permalink raw reply
* Re: drivers/net/iseries_veth.c dubious sysfs usage
From: Greg KH @ 2007-12-05 21:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Kyle A. Lucke, paulus, linux-kernel, David Gibson
In-Reply-To: <1196853031.6759.7.camel@concordia>
On Wed, Dec 05, 2007 at 10:10:31PM +1100, Michael Ellerman wrote:
> On Wed, 2007-12-05 at 01:30 -0800, Greg KH wrote:
> > In doing a massive kobject cleanup of the kernel tree, I ran across the
> > iseries_veth.c driver.
> >
> > It looks like the driver is creating a number of subdirectories under
> > the driver sysfs directory. This is odd and probably wrong. You want
> > these virtual connections to show up in the main sysfs device tree, not
> > under the driver directory.
> >
> > I'll be glad to totally guess and try to move it around in the sysfs
> > tree, but odds are I'll get it all wrong as I can't really test this
> > out :)
> >
> > Any hints on what this driver is trying to do in this sysfs directories?
>
> I wrote the code, I think, but it's been a while - I'll have a look at
> it tomorrow.
Yes, can you send me the sysfs tree output of the driver directory, and
what exactly the different files in there are supposed to be used for?
> Why is it "odd and probably wrong" to create subdirectories under the
> driver in sysfs?
Because a driver does not have "devices" under it in the sysfs tree.
All devices liven in the /sys/devices/ tree so we can properly manage
them that way. A driver will then bind to a device, and the driver core
will set up the linkages in sysfs properly so that everthing looks
uniform.
By creating subdirectories associated with a driver, this breaks the
model that the entire rest of the kernel is using, which is something
that you really don't want to be doing :)
How about describing what you were trying to achieve with these
directories and files?
thanks,
greg k-h
^ permalink raw reply
* RE: Uboot and ML410
From: John Hahn @ 2007-12-05 21:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14177109.post@talk.nabble.com>
We are also using 3.81 make (Centos 5 distro) with ELDK 4.1 version
downloaded from www.denx.de and have had no problems using the u-boot.zip
srcs from www.xilinx.com/ml410_p, though we use uboot for our ml403 based
development, we can build u-boot for ml403_config as well as ml410_config.
Cheers
John
_________________
John S Hahn
BCF Semiconductor
> -----Original Message-----
> From: linuxppc-embedded-bounces+jhahn=bcfsemi.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+jhahn=bcfsemi.com@ozlabs.org] On
> Behalf Of khollan
> Sent: Wednesday, December 05, 2007 10:00 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Uboot and ML410
>
>
> Hi
>
> Is there a patch to include support for the ml410 in the Main git tree
> of u-boot? I tried compiling Xilinx's tree but it seems it won't
> compile correctly with my version of make (3.81). Also is there any
> support for the Hard TEMAC in u-boot? I tried looking for both of
> these questions but a lot of the threads were unanswered questions.
> Thanks for your help
>
> kholland
> --
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Mark A. Greer @ 2007-12-05 22:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196875970.8544.12.camel@ld0161-tx32>
On Wed, Dec 05, 2007 at 11:32:50AM -0600, Jon Loeliger wrote:
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index abb26dc..b039f21 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -16,6 +16,17 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + aliases {
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> + ethernet3 = &enet3;
> + serial0 = &serial0;
> + serial1 = &serial1;
> + pci0 = &pci0;
> + pci1 = &pci1;
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -107,7 +118,7 @@
> };
> };
>
> - ethernet@24000 {
> + enet0: ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
This is probably a dumb question but I'll ask it anyway.
What's the point of 'aliases' when you already have labels?
E.g., why not just use enet0 instead of making an ethernet0 alias?
Mark
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: David Gibson @ 2007-12-05 22:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20071205222816.GA3725@mag.az.mvista.com>
On Wed, Dec 05, 2007 at 03:28:16PM -0700, Mark A. Greer wrote:
> On Wed, Dec 05, 2007 at 11:32:50AM -0600, Jon Loeliger wrote:
>
> > diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > index abb26dc..b039f21 100644
> > --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > @@ -16,6 +16,17 @@
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > + aliases {
> > + ethernet0 = &enet0;
> > + ethernet1 = &enet1;
> > + ethernet2 = &enet2;
> > + ethernet3 = &enet3;
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + pci0 = &pci0;
> > + pci1 = &pci1;
> > + };
> > +
> > cpus {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > @@ -107,7 +118,7 @@
> > };
> > };
> >
> > - ethernet@24000 {
> > + enet0: ethernet@24000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > device_type = "network";
>
> This is probably a dumb question but I'll ask it anyway.
>
> What's the point of 'aliases' when you already have labels?
> E.g., why not just use enet0 instead of making an ethernet0 alias?
The aliase information is available in the output tree, whereas labels
are only internal to dtc (well, except for asm output).
I'm planning to add support later to automatically generate aliases
from specially marked labels.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: RFC: Fix some lexical problems with references
From: Josh Boyer @ 2007-12-05 22:34 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122061007.GA22888@localhost.localdomain>
On Thu, 22 Nov 2007 17:10:07 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
So this breaks some of the in-kernel DTS files. Example, bamboo.dts on
line 19 produces:
bamboo.dts: 19 syntax error
FATAL ERROR: Couldn't read input tree
I tried quoting the path with {} but that didn't seem to work.
josh
^ 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