On Fri, 2016-07-01 at 13:15 -0300, Thiago Jung Bauermann wrote:
> Hi Samuel,
>
> Thanks for your response.
>
> Am Freitag, 01 Juli 2016, 11:46:21 schrieb Samuel Mendoza-Jonas:
> > On Thu, 2016-06-30 at 11:27 -0300, Thiago Jung Bauermann wrote:
> > > I have a question about the petitboot feature w
Hi Samuel,
Thanks for your response.
Am Freitag, 01 Juli 2016, 11:46:21 schrieb Samuel Mendoza-Jonas:
> On Thu, 2016-06-30 at 11:27 -0300, Thiago Jung Bauermann wrote:
> > I have a question about the petitboot feature which allows the user to
> > specify a device tree blob to pass to the target O
On Fri, Jun 13, 2014, at 05:21 AM, Scott Wood wrote:
> On Thu, 2014-06-12 at 23:36 +0800, Pannirselvam Kanagaratnam wrote:
> > The QORIQ P1023RDB has an option to populate the Marvell 88E6165
> > Ethernet switch. We populated this device and was able to initialize
> > it as a basic switch in U-Bo
On Thu, 2014-06-12 at 23:36 +0800, Pannirselvam Kanagaratnam wrote:
> The QORIQ P1023RDB has an option to populate the Marvell 88E6165
> Ethernet switch. We populated this device and was able to initialize
> it as a basic switch in U-Boot. However, the switch driver was not
> loaded upon kernel boo
On Mon, 2013-09-23 at 11:37 +0400, Aida Mynzhasova wrote:
> Hi,
>
> Currently, Freescale Gianfar PTP reference clock source is determined
> through hard-coded value in gianfar_ptp driver. I don't think that
> recompilation of the entire module (or even worse - the kernel) is a god
> idea when w
On 15/01/13 08:11, ternaryd wrote:
> Hi,
>
> I'm trying to install linux on an e500v2 board with the tsi148
> VME-Bridge, but got stuck. Now it seems that I need to include
> information regarding this bridge into the .dts-file, but can't figure
> out how. Maybe somebody on this list could post th
:11 PM
To: Lixin Yao
Cc: mich...@ellerman.id.au; linuxppc-dev@lists.ozlabs.org
Subject: Re: Device Tree Corrupted after unflatten_device_tree()
On Wed, Oct 21, 2009 at 10:43:55AM -0700, Lixin Yao wrote:
> When corrupted, curtain blocks of 64 bytes are messed up.
> This is a screen dump of
On Wed, Oct 21, 2009 at 10:43:55AM -0700, Lixin Yao wrote:
> When corrupted, curtain blocks of 64 bytes are messed up.
> This is a screen dump of a good unflattened device at beginning:
[snip]
> When corrupted, it becomes following, note the 64 bock at 0x03ffdf00
> is messed up. And this kind of c
ode is used many many times and on many many boards. It should
work. I am not sure if this causes the problem.
Thanks!
Lixin
-Original Message-
From: Michael Ellerman [mailto:mich...@ellerman.id.au]
Sent: Tuesday, October 20, 2009 7:02 PM
To: Lixin Yao
Cc: linuxppc-dev@lists.ozlabs.org
Sub
On Tue, 2009-10-20 at 09:10 -0700, Lixin Yao wrote:
> I use a board with MPC866T and 2.6.28 Linux Kernel. Occasionally, the
> unflattened device is corrupted after “unflatten_device_tree()” which
> causes crash of kernel when device tree is traversed later on.
>
> I looked at the fixes in lib/lmb
Hi,
ok, so I have managed to give it some OF support in a preliminary way(see
patch). But now, I am facing serious problems which I am finding difficult
to tackle. I understand that maybe these problems have to do partially or
entirely to the Xilinx ML403. Let me explain myself: First of all, I d
> "Jorge" == Jorge Sánchez de Nova writes:
Jorge> Hi,
Jorge> It doesn't work at all since it doesn't load anything. I have
Jorge> looked at the driver and there is apparently no openfirmware
Jorge> support for it, so maybe the dts info won't work without
Jorge> it. Am I wrong? Does this
On Thu, Jan 22, 2009 at 06:47:01PM +1100, Daniel Ng wrote:
> Thanks Scott. What is the meaning of the Ethernet reg field?:
>
> reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
>
> Is it-
>
> 0x11300-> GFMR1 ie. the GFMR for FCC1?
> 0x20-> GFMR1 Fields are a total of 32 bits?
> 0x8400-> initial val
On Thu, Jan 22, 2009 at 4:52 AM, Scott Wood wrote:
>> 3) In the PIC: interrupt-control...@10c00 node-
>> reg = <0x10c00 0x80>;
>
> Offset and length of PIC registers.
Thanks Scott. What is the meaning of the Ethernet reg field?:
reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
Is it-
0x11300-> G
On Wed, Jan 21, 2009 at 06:37:32PM +1100, Daniel Ng wrote:
> I think the of_get_gpio() error messages are a result of the following
> code in cpm_uart_init_port()-
>
> for (i = 0; i < NUM_GPIOS; i++)
> pinfo->gpios[i] = of_get_gpio(np, i);
>
> -why is this code here? Is it for processing mo
Hi Scott,
On Wed, Jan 21, 2009 at 3:41 AM, Scott Wood wrote:
> On Tue, Jan 20, 2009 at 06:23:08PM +1100, Daniel Ng wrote:
>> PID hash table entries: 128 (order: 7, 512 bytes)
>> time_init: decrementer frequency = 16.50 MHz
>> time_init: processor frequency = 330.00 MHz
>> clocksource: t
On Tue, Jan 20, 2009 at 06:23:08PM +1100, Daniel Ng wrote:
> PID hash table entries: 128 (order: 7, 512 bytes)
> time_init: decrementer frequency = 16.50 MHz
> time_init: processor frequency = 330.00 MHz
> clocksource: timebase mult[f26c9b2] shift[22] registered
> clockevent: decrementer
Hi Scott,
By #defining DEBUG in setup-32.c and setting the following in my kernel config-
CONFIG_PPC_EARLY_DEBUG=y
CONFIG_PPC_EARLY_DEBUG_CPM=y
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf0001ff8
-I have been able to get the following boot messages:
## Booting kernel from Legacy Image at 0020 ...
On Mon, Jan 19, 2009 at 12:58:41PM +1100, Daniel Ng wrote:
> Hi Scott,
> On Sat, Jan 17, 2009 at 5:14 AM, Scott Wood wrote:
> >
> >> /dts-v1/;
> >>
> >> / {
> >> model = "HPXRED";
> >> compatible = "fsl,mpc8272ads";
> >
> > Is it 100% compatible? If not, change the compatible to something else
>
Hi Scott,
On Sat, Jan 17, 2009 at 5:14 AM, Scott Wood wrote:
>
>> /dts-v1/;
>>
>> / {
>> model = "HPXRED";
>> compatible = "fsl,mpc8272ads";
>
> Is it 100% compatible? If not, change the compatible to something else
> (and make sure your board code matches it).
My board is similar to the mpc8272
On Fri, Jan 16, 2009 at 02:40:03PM +1100, Daniel Ng wrote:
> I've tried various values for 'console' but I'm quite certain 'ttyCPM0' is the
> one to use as this is what I was using when it was working with Linux 2.6.14
> and an old (pre-Device Tree) version of u-boot.
Yes, that is correct. You ca
Hi Scott,
> Scott Wood freescale.com> writes:
> > Yes, if u-boot is providing junk, then you'll probably want to hack up
> > the wrapper to ignore it. Or just upgrade u-boot to one that works.
So, I've gotten the latest u-boot installed and working. Here's my boot
sequence-
## Booting kernel fro
Thank for your answers.
Sébastien
Matt Sealey a écrit :
Benjamin Herrenschmidt wrote:
On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
It's far more common than people might think at first glance. With x86
I am sure it would benefit the platform a little more if the OF support
was in-line
> Thanks. The fdt_del_node approach works pretty nicely. I added a
> dt_ops hook since fdt is static in libfdt-wrapper.c.
.../...
David says your patch is ok, However it's not in the right form. Could
you repost it please with a proper changeset comment and signed-off-by:
line ?
Thanks !
Ch
On Fri, Oct 17, 2008 at 07:14:05PM -0700, Mike Ditto wrote:
> David Gibson wrote:
> > Deleting the irrelevant parts or picking a device tree to pass to
> > fdt_init() are both reasonable solutions. libfdt which is included in
> > the bootwrapper has functions for removing unwanted nodes: either
>
David Gibson wrote:
> Deleting the irrelevant parts or picking a device tree to pass to
> fdt_init() are both reasonable solutions. libfdt which is included in
> the bootwrapper has functions for removing unwanted nodes: either
> fdt_nop_node() or fdt_del_node() will suffice. There isn't currentl
On Thu, Oct 16, 2008 at 05:52:54PM -0700, Mike Ditto wrote:
> I'm building a kernel that can run on a handful of hardware
> configurations, all using OF-unaware U-Boot. I know how to make a
> static device tree (dts file) that works on one of these hardware
> variations, and how to add nodes and m
Benjamin Herrenschmidt wrote:
On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
It's far more common than people might think at first glance. With x86
I am sure it would benefit the platform a little more if the OF support
was in-line with the shared code between PPC and SPARC (and now I gue
On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
> It's far more common than people might think at first glance. With x86
> I am sure it would benefit the platform a little more if the OF support
> was in-line with the shared code between PPC and SPARC (and now I guess,
> ARM) but nevertheless
Gerald Van Baren wrote:
Matt Sealey wrote:
>>
The Toshiba TOPAS910 ARM development board also runs Open Firmware and
contains patches to support OF device trees.
I dare say there might be an x86 box or two out there, too. But they
have ACPI tables too which is far more common..
More than a
Matt Sealey wrote:
>
> Sergei Shtylyov wrote:
>> Hello.
>>
>> Sébastien Chrétien wrote:
>>> Hello,
>>> I have a question about Device Tree.
>>> Is Device Tree found only only on Linux Powerpc ?
>>
>> Not only Linux as it's a part of Open Firmware which is also used at
>> least on SPARC.
>
> The T
Sergei Shtylyov wrote:
Hello.
Sébastien Chrétien wrote:
Hello,
I have a question about Device Tree.
Is Device Tree found only only on Linux Powerpc ?
Not only Linux as it's a part of Open Firmware which is also used at
least on SPARC.
The Toshiba TOPAS910 ARM development board also runs
On Mon, 2008-09-29 at 08:24 +0200, Sébastien Chrétien wrote:
> Hello,
> I have a question about Device Tree.
> Is Device Tree found only only on Linux Powerpc ?
Sparc also uses open firmware and shares some of the device-tree
handling code with powerpc in linux. Other operating systems on those
pl
Hello.
Sébastien Chrétien wrote:
I have a question about Device Tree.
Is Device Tree found only only on Linux Powerpc ?
Not only Linux as it's a part of Open Firmware which is also used at
least on SPARC.
WBR, Sergei
___
Linuxppc-dev mailing
Hello.
Sébastien Chrétien wrote:
Hello,
I have a question about Device Tree.
Is Device Tree found only only on Linux Powerpc ?
Not only Linux as it's a part of Open Firmware which is also used at
least on SPARC.
WBR, Sergei
___
Linuxppc-dev ma
Benjamin Herrenschmidt wrote:
> On Thu, 2008-08-07 at 15:56 -0400, Steven A. Falco wrote:
>
>> I have added a compact flash to the external bus of a Sequoia
>> (PPC440EPx) evaluation board. It is wired to CS1, and U-boot is set to
>> configure CS1 to be at address 0xc100. U-boot can access
On Thu, 2008-08-07 at 15:56 -0400, Steven A. Falco wrote:
> I have added a compact flash to the external bus of a Sequoia
> (PPC440EPx) evaluation board. It is wired to CS1, and U-boot is set to
> configure CS1 to be at address 0xc100. U-boot can access the
> device, and reports the correct p
Chandru writes:
> When I set linux 2.6.26-rc1 as default kernel to boot in
> /etc/yaboot.conf, then the device tree in open firmware shows only one
> memory node ( the same memory node appears in /proc/device-tree/[EMAIL
> PROTECTED]
> ). But when RHEL5.2 kernel is set as default in /etc/yabo
> [EMAIL PROTECTED] {
> interrupt-map-mask = <0f800 0 0 7>;
> interrupt-map = <
> /* IDSEL 0x10 */
> 8000 0 0 1 &PCI_INT 1
>
> /* IDSEL 0x11 */
>
>From: Scott Wood
>Sent: Fri 1/11/2008 1:02 PM
>To: Rune Torgersen
>Cc: linuxppc-dev@ozlabs.org
>Subject: Re: Device Tree & PCI
>
>On Fri, Jan 11, 2008 at 12:17:41PM -0600, Rune Torgersen wrote:
>> PCI_INT: [EMAIL PROTECTED],10 {
>>
On Fri, Jan 11, 2008 at 12:17:41PM -0600, Rune Torgersen wrote:
> PCI_INT: [EMAIL PROTECTED],10 {
> #interrupt-cells = <1>;
> interrupt-controller;
> reg = <5 10 4>; //
> Chip select, offset,
Thanks, I've updated the generator to reflect this.
Steve
-Original Message-
From: David Gibson [mailto:[EMAIL PROTECTED]
Sent: Sun 12/16/2007 9:21 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; Michal Simek; git
Subject: Re: Device Tree updates for xilinx.
On Sun, D
On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
>
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference? For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version. So for the
> microblaze, I'd prefer s
r ibm,ppc405 or ibm.ppc-405 would seem to be more in
character than PowerPC,405.
Steve
-Original Message-
From: David Gibson [mailto:[EMAIL PROTECTED]
Sent: Sat 12/15/2007 11:04 PM
To: Stephen Neuendorffer
Cc: Grant Likely; Michal Simek; John Williams; linuxppc-dev@ozlabs.org; git
Subj
On Sun, 16 Dec 2007 18:04:04 +1100
David Gibson <[EMAIL PROTECTED]> wrote:
> > cpus {
> > #address-cells = <1>;
> > #cpus = <1>;
> > #size-cells = <0>;
> > PowerPC,[EMAIL PROTECTED] {
>
> I'm trying to encourage people to move to naming cpu node
On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:
> These patches synchronize all the in-kernel drivers to use the
> compatible names generated by the UBoot BSP generator.
> (at git://git.xilinx.com/gen-mhs-devtree.git)
>
> The patches to make this work are coming shortly:
>
>
Alan Bennett wrote:
> Device Tree and BRG?
> The SMC1 uses BRG7 and the SCC1 uses BRG1, should we have both BRGs
> configured in the .dts? ( BRG1 is configured).
They should both be specified, and either in the firmware or in the
platform code you need to set CMXSMR.
> Device Tree and Chosen?
Device Tree and BRG?
The SMC1 uses BRG7 and the SCC1 uses BRG1, should we have both BRGs
configured in the .dts? ( BRG1 is configured).
Device Tree and Chosen?
Adding a chosen block and I end up off in the weeds. removing the
chosen block and I die within cpm_uart_console_write
chose
Alan Bennett wrote:
> Ok, making progress on the ep8248 / devtrees, etc...
>
> But I'm not getting any output on the serial and my log_buf is pretty
> clean. Without console; what's the best way to figure out why I'm not
> getting any output on my SMC1 serial port (using u-boot , not planetcore
Ok, making progress on the ep8248 / devtrees, etc...
But I'm not getting any output on the serial and my log_buf is pretty
clean. Without console; what's the best way to figure out why I'm not
getting any output on my SMC1 serial port (using u-boot , not planetcore)?
-Alan
__log_buf:
Using Em
On Thu, 2007-08-23 at 09:30 +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote:
> >
> >
> > Jeff, I've discussed this with BenH, and although there are some
> > problems with the driver still, we think it's good enough to merge in
> > 2.6.24, the warts ca
On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote:
>
>
> Jeff, I've discussed this with BenH, and although there are some
> problems with the driver still, we think it's good enough to merge in
> 2.6.24, the warts can be fixed up later. Please apply...
Or to be more precise:
This driver wi
On Fri, Aug 10, 2007 at 10:39:31PM +0200, Segher Boessenkool wrote:
> > * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> >to use ibm_newemac-y rather than ibm_newemac-objs.
>
> I thought it was the other way around, so I checked with the
> Kbuild maintainer, and indeed
On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> This driver is designed to sit alongside the old driver (it lies in
> drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> old driver is left in place to support arch/ppc until arch/ppc itself
> reaches its final demi
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
>to use ibm_newemac-y rather than ibm_newemac-objs.
I thought it was the other way around, so I checked with the
Kbuild maintainer, and indeed you are correct.
Segher
___
Li
On Wed, 2007-08-08 at 15:09 +1000, David Gibson wrote:
>
> Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
> them.
Ahah... maybe I -did- add some of those then :-) I do use C++ comments
for FIXME's on purpose, because they are ugly, it improves the changes
that I actually get t
> * c++ style comments
Ouch... I haven't removed them all ? I promise I didn't -add- any :-)
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
On Wed, Aug 08, 2007 at 01:16:43PM +1000, Tony Breeds wrote:
> On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASIC is also found
On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> Based on BenH's earlier work, this is a new version of the EMAC driver
> for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> same ASIC is also found in the Axon bridge chip. This new version is
> designed to work in t
On Tue, Aug 07, 2007 at 07:15:39AM -0500, Josh Boyer wrote:
> On Tue, 7 Aug 2007 16:22:31 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
>
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASI
On Tue, 7 Aug 2007 16:22:31 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> Based on BenH's earlier work, this is a new version of the EMAC driver
> for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> same ASIC is also found in the Axon bridge chip. This new version is
> designed
61 matches
Mail list logo
