Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote: Finally, something could be wrong with the interrupt controller. AFAICT, you register it through the device tree now, but it's also getting initialized through kirkwood_init_irq, so the numbers would all be wrong. Yes, I'm working through this now. mv_cesa silently fails to come up if it can't find the interrupt controller via fdt. So, it needs to get done. Right now, I'm looking at how mach-versatile does it (vic_init()) since it's also an ARM926ej-s... thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thursday 08 March 2012, Jason wrote: On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote: Finally, something could be wrong with the interrupt controller. AFAICT, you register it through the device tree now, but it's also getting initialized through kirkwood_init_irq, so the numbers would all be wrong. Yes, I'm working through this now. mv_cesa silently fails to come up if it can't find the interrupt controller via fdt. So, it needs to get done. Right now, I'm looking at how mach-versatile does it (vic_init()) since it's also an ARM926ej-s... Ok, sounds good. It's not important whether it's an ARM9 or not btw. You should look at both anything that defines an interrupt-controller property as an example including Documentation/devicetree/bindings/arm/vic.txt and Documentation/devicetree/bindings/arm/gic.txt. (taking Thomas Gleixner on Cc) Since the orion irq chip is based on irqchip_generic, it would be perfect to have a generic irqchip binding to go along with kernel/irq/generic-chip.c. Not sure if anyone has thought about this before, but it looks like we can completely avoid using arch/arm/plat-orion/irq.c and arch/arm/mach-kirkwood/irq.c if we do that. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thu, 8 Mar 2012, Arnd Bergmann wrote: On Thursday 08 March 2012, Jason wrote: On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote: Finally, something could be wrong with the interrupt controller. AFAICT, you register it through the device tree now, but it's also getting initialized through kirkwood_init_irq, so the numbers would all be wrong. Yes, I'm working through this now. mv_cesa silently fails to come up if it can't find the interrupt controller via fdt. So, it needs to get done. Right now, I'm looking at how mach-versatile does it (vic_init()) since it's also an ARM926ej-s... Ok, sounds good. It's not important whether it's an ARM9 or not btw. You should look at both anything that defines an interrupt-controller property as an example including Documentation/devicetree/bindings/arm/vic.txt and Documentation/devicetree/bindings/arm/gic.txt. (taking Thomas Gleixner on Cc) Since the orion irq chip is based on irqchip_generic, it would be perfect to have a generic irqchip binding to go along with kernel/irq/generic-chip.c. Not sure if anyone has thought about this before, but it looks like we can completely avoid using arch/arm/plat-orion/irq.c and arch/arm/mach-kirkwood/irq.c if we do that. Right. That should be trivial to implement. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thu, Mar 08, 2012 at 08:27:11PM +0100, Thomas Gleixner wrote: On Thu, 8 Mar 2012, Arnd Bergmann wrote: On Thursday 08 March 2012, Jason wrote: On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote: Finally, something could be wrong with the interrupt controller. AFAICT, you register it through the device tree now, but it's also getting initialized through kirkwood_init_irq, so the numbers would all be wrong. Yes, I'm working through this now. mv_cesa silently fails to come up if it can't find the interrupt controller via fdt. So, it needs to get done. Right now, I'm looking at how mach-versatile does it (vic_init()) since it's also an ARM926ej-s... Ok, sounds good. It's not important whether it's an ARM9 or not btw. You should look at both anything that defines an interrupt-controller property as an example including Documentation/devicetree/bindings/arm/vic.txt and Documentation/devicetree/bindings/arm/gic.txt. (taking Thomas Gleixner on Cc) Since the orion irq chip is based on irqchip_generic, it would be perfect to have a generic irqchip binding to go along with kernel/irq/generic-chip.c. Not sure if anyone has thought about this before, but it looks like we can completely avoid using arch/arm/plat-orion/irq.c and arch/arm/mach-kirkwood/irq.c if we do that. Right. That should be trivial to implement. ok, I'm on it. kernel/irq/of_generic_irq.c sound good? thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason wrote:
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Here's my most recent attempt:
serial@f1012000 {
device_type = serial;
compatible = ns16550a;
reg = 0xf1012000 0x100; /*phys addr*/
virt-reg = 0xfed12000; /*virt addr*/
reg-shift = 2;
reg-io-width = 1;
interrupts = 33;
current-speed = 115200;
interrupt-parent = intc;
clock-frequency = 2;
};
I've looked at what is done in the powerpc dt's, but, no luck. When
earlyprintk is enabled, I see no error messages, just:
bootconsole [earlycon0] enabled
debug: skip boot console de-registration.
...
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
Any pointers?
My first guess was that clock-frequency is wrong, but it seems that
this one actually is correct, at least it's the same thing that
the platform code sets.
You should never need to pass the virtual address to a device,
most of all because it cannot be known to the device tree at all.
The of_serial driver (you did enable that one in Kconfig, right?)
Ugh. Someone really needs to step up and kill the of_serial driver. All that
stuff belongs in the core 16550 driver.
g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 02:27:23PM -0500, Jason wrote:
On Wed, Mar 07, 2012 at 06:31:31PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not
0xff.
This is different from the way we define resources in Linux.
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Here's my most recent attempt:
I see that you've resolved your problem, but some comments below on the
device node:
serial@f1012000 {
device_type = serial;
Never use device_type. It should only ever appear in the memory node, and
I plan to remove it from there too.
compatible = ns16550a;
reg = 0xf1012000 0x100; /*phys addr*/
virt-reg = 0xfed12000; /*virt addr*/
Don't use virt-reg. Nothing in the kernel uses it and the kernel will
make it's own decision about virtual address mapping.
reg-shift = 2;
reg-io-width = 1;
1 is the default for reg-io-width. No need to have this property. It
should only be used if the device requires 32 bit accesses.
interrupts = 33;
current-speed = 115200;
interrupt-parent = intc;
clock-frequency = 2;
};
g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thu, Mar 08, 2012 at 02:47:25PM -0500, Jason wrote: On Thu, Mar 08, 2012 at 08:27:11PM +0100, Thomas Gleixner wrote: On Thu, 8 Mar 2012, Arnd Bergmann wrote: On Thursday 08 March 2012, Jason wrote: On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote: Finally, something could be wrong with the interrupt controller. AFAICT, you register it through the device tree now, but it's also getting initialized through kirkwood_init_irq, so the numbers would all be wrong. Yes, I'm working through this now. mv_cesa silently fails to come up if it can't find the interrupt controller via fdt. So, it needs to get done. Right now, I'm looking at how mach-versatile does it (vic_init()) since it's also an ARM926ej-s... Ok, sounds good. It's not important whether it's an ARM9 or not btw. You should look at both anything that defines an interrupt-controller property as an example including Documentation/devicetree/bindings/arm/vic.txt and Documentation/devicetree/bindings/arm/gic.txt. (taking Thomas Gleixner on Cc) Since the orion irq chip is based on irqchip_generic, it would be perfect to have a generic irqchip binding to go along with kernel/irq/generic-chip.c. Not sure if anyone has thought about this before, but it looks like we can completely avoid using arch/arm/plat-orion/irq.c and arch/arm/mach-kirkwood/irq.c if we do that. Right. That should be trivial to implement. ok, I'm on it. kernel/irq/of_generic_irq.c sound good? Rob Herring has done some work in this area. Please coordinate with him. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thu, Mar 08, 2012 at 02:32:44PM -0700, Grant Likely wrote: On Thu, Mar 08, 2012 at 02:47:25PM -0500, Jason wrote: On Thu, Mar 08, 2012 at 08:27:11PM +0100, Thomas Gleixner wrote: On Thu, 8 Mar 2012, Arnd Bergmann wrote: On Thursday 08 March 2012, Jason wrote: On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote: Finally, something could be wrong with the interrupt controller. AFAICT, you register it through the device tree now, but it's also getting initialized through kirkwood_init_irq, so the numbers would all be wrong. Yes, I'm working through this now. mv_cesa silently fails to come up if it can't find the interrupt controller via fdt. So, it needs to get done. Right now, I'm looking at how mach-versatile does it (vic_init()) since it's also an ARM926ej-s... Ok, sounds good. It's not important whether it's an ARM9 or not btw. You should look at both anything that defines an interrupt-controller property as an example including Documentation/devicetree/bindings/arm/vic.txt and Documentation/devicetree/bindings/arm/gic.txt. (taking Thomas Gleixner on Cc) Since the orion irq chip is based on irqchip_generic, it would be perfect to have a generic irqchip binding to go along with kernel/irq/generic-chip.c. Not sure if anyone has thought about this before, but it looks like we can completely avoid using arch/arm/plat-orion/irq.c and arch/arm/mach-kirkwood/irq.c if we do that. Right. That should be trivial to implement. ok, I'm on it. kernel/irq/of_generic_irq.c sound good? Rob Herring has done some work in this area. Please coordinate with him. Rob, I'm attempting to convert mach-kirkwood boards over to devicetree, starting with the dreamplug. You can find my stable patches here: git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_stable and the stuff I'm still trying to figure out: git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_staging My next task looks like converting the irq code, since mv_cesa fails silently without the interrupt-controller specified in the dtb. The code I'm replacing can be found here: arch/arm/mach-kirkwood/irq.c arch/arm/plat-orion/irq.c This is the first time I've attempted something like this, so any pointers would be much appreciated. Also, if there is anything I would need to deconflict with, please let me know. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thu, Mar 08, 2012 at 02:31:39PM -0700, Grant Likely wrote:
On Wed, Mar 07, 2012 at 02:27:23PM -0500, Jason wrote:
On Wed, Mar 07, 2012 at 06:31:31PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not
0xff.
This is different from the way we define resources in Linux.
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Here's my most recent attempt:
I see that you've resolved your problem, but some comments below on the
device node:
serial@f1012000 {
device_type = serial;
Never use device_type. It should only ever appear in the memory node, and
I plan to remove it from there too.
compatible = ns16550a;
reg = 0xf1012000 0x100; /*phys addr*/
virt-reg = 0xfed12000; /*virt addr*/
Don't use virt-reg. Nothing in the kernel uses it and the kernel will
make it's own decision about virtual address mapping.
reg-shift = 2;
reg-io-width = 1;
1 is the default for reg-io-width. No need to have this property. It
should only be used if the device requires 32 bit accesses.
interrupts = 33;
current-speed = 115200;
interrupt-parent = intc;
clock-frequency = 2;
};
Thanks, Grant. I reverted all of those changes once I found the root of
my problem.
thx,
Jason.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On 03/08/2012 03:50 PM, Jason wrote: On Thu, Mar 08, 2012 at 02:32:44PM -0700, Grant Likely wrote: On Thu, Mar 08, 2012 at 02:47:25PM -0500, Jason wrote: On Thu, Mar 08, 2012 at 08:27:11PM +0100, Thomas Gleixner wrote: On Thu, 8 Mar 2012, Arnd Bergmann wrote: On Thursday 08 March 2012, Jason wrote: On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote: Finally, something could be wrong with the interrupt controller. AFAICT, you register it through the device tree now, but it's also getting initialized through kirkwood_init_irq, so the numbers would all be wrong. Yes, I'm working through this now. mv_cesa silently fails to come up if it can't find the interrupt controller via fdt. So, it needs to get done. Right now, I'm looking at how mach-versatile does it (vic_init()) since it's also an ARM926ej-s... Ok, sounds good. It's not important whether it's an ARM9 or not btw. You should look at both anything that defines an interrupt-controller property as an example including Documentation/devicetree/bindings/arm/vic.txt and Documentation/devicetree/bindings/arm/gic.txt. (taking Thomas Gleixner on Cc) Since the orion irq chip is based on irqchip_generic, it would be perfect to have a generic irqchip binding to go along with kernel/irq/generic-chip.c. Not sure if anyone has thought about this before, but it looks like we can completely avoid using arch/arm/plat-orion/irq.c and arch/arm/mach-kirkwood/irq.c if we do that. A generic irqchip binding is not the right approach. The binding should still be specific to the controller as the generic irqchip code doesn't handle everything like dispatching interrupts or know how many blocks of 32 interrupts your controller has. Right. That should be trivial to implement. Yes, since someone else already has (me). ok, I'm on it. kernel/irq/of_generic_irq.c sound good? Rob Herring has done some work in this area. Please coordinate with him. Rob, I'm attempting to convert mach-kirkwood boards over to devicetree, starting with the dreamplug. You can find my stable patches here: git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_stable and the stuff I'm still trying to figure out: git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_staging My next task looks like converting the irq code, since mv_cesa fails silently without the interrupt-controller specified in the dtb. The code I'm replacing can be found here: arch/arm/mach-kirkwood/irq.c arch/arm/plat-orion/irq.c This is the first time I've attempted something like this, so any pointers would be much appreciated. Also, if there is anything I would need to deconflict with, please let me know. Look at my branch here: git://sources.calxeda.com/kernel/linux.git irqdomain-for-grant Your .init_irq function should call of_irq_init which will then call an init function for each controller. Then you need to call irq_setup_generic_chip_domain to setup the generic irqchip instances. You also should convert to enabling CONFIG_MULTI_IRQ_HANDLER or I think a linear domain won't work for you and that's what the generic irqchip code will use. Also you should enable SPARSE_IRQ, but that is somewhat independent. In the DT case, you want to not have any compile time dependencies on Linux irq numbers. If you're keeping non-DT compatibility, that will complicate your conversion. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thursday 08 March 2012, Grant Likely wrote: My first guess was that clock-frequency is wrong, but it seems that this one actually is correct, at least it's the same thing that the platform code sets. You should never need to pass the virtual address to a device, most of all because it cannot be known to the device tree at all. The of_serial driver (you did enable that one in Kconfig, right?) Ugh. Someone really needs to step up and kill the of_serial driver. All that stuff belongs in the core 16550 driver. Well, actually I would argue that nothing belongs into the core 8250 driver. What we should do though is split the of_serial.c file into the main 8250 portion and put that into drivers/tty/serial/8250/ along with the other 14 bus glue drivers, and put the nwpserial portion into drivers/tty/serial/nwpserial.c. I have started a major rework of 8250 some time ago that I need to finish up, to make the different ways for registering an 8250 device more regular, and get rid of the more obscure ways we have in the kernel, replacing them with platform devices or other bus specific 'struct device' versions. The main intention of that patch series is to confine the ISA/PCI specific inb/outb accessors in the files that need them so we can actually build the platform drivers without defining those, but I can take care of of_serial.c as well -- after all I wrote that file originally. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Thursday 08 March 2012, Arnd Bergmann wrote: Since the orion irq chip is based on irqchip_generic, it would be perfect to have a generic irqchip binding to go along with kernel/irq/generic-chip.c. Not sure if anyone has thought about this before, but it looks like we can completely avoid using arch/arm/plat-orion/irq.c and arch/arm/mach-kirkwood/irq.c if we do that. One more thing about the interrupt controller changes: The arm-soc tree includes Grants irqchip branch, and the tegra/soc-drivers and at91/dt branches are building on top of that. Please have a look at what they do so you can do the same. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not 0xff.
This is different from the way we define resources in Linux.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 06:31:31PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not 0xff.
This is different from the way we define resources in Linux.
I was maintaining form with plat-orion/common.c:66 (0xff) I'll fix it
to inclusive.
thx,
Jason.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 06:31:31PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not 0xff.
This is different from the way we define resources in Linux.
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Here's my most recent attempt:
serial@f1012000 {
device_type = serial;
compatible = ns16550a;
reg = 0xf1012000 0x100; /*phys addr*/
virt-reg = 0xfed12000; /*virt addr*/
reg-shift = 2;
reg-io-width = 1;
interrupts = 33;
current-speed = 115200;
interrupt-parent = intc;
clock-frequency = 2;
};
I've looked at what is done in the powerpc dt's, but, no luck. When
earlyprintk is enabled, I see no error messages, just:
bootconsole [earlycon0] enabled
debug: skip boot console de-registration.
...
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
Any pointers?
thx,
Jason.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 02:27:23PM -0500, Jason wrote:
On Wed, Mar 07, 2012 at 06:31:31PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not
0xff.
This is different from the way we define resources in Linux.
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Hi Jason
What do you see in /proc/iomem?
You should expect:
f1012000-f10120ff : serial8250.0
f1012000-f101201f : serial
f1012100-f10121ff : serial8250.1
f1012100-f101211f : serial
or probably just the first, if your device only has one serial port.
How about /proc/interrupts?
33:195 orion_irq serial
Anything like this in dmesg?
[ 17.189397] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 17.210023] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[ 17.624748] console [ttyS0] enabled
[ 17.648555] serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
Comparing your system to the above might help you track down which
property is wrong.
Andrew
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wednesday 07 March 2012, Jason wrote:
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Here's my most recent attempt:
serial@f1012000 {
device_type = serial;
compatible = ns16550a;
reg = 0xf1012000 0x100; /*phys addr*/
virt-reg = 0xfed12000; /*virt addr*/
reg-shift = 2;
reg-io-width = 1;
interrupts = 33;
current-speed = 115200;
interrupt-parent = intc;
clock-frequency = 2;
};
I've looked at what is done in the powerpc dt's, but, no luck. When
earlyprintk is enabled, I see no error messages, just:
bootconsole [earlycon0] enabled
debug: skip boot console de-registration.
...
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
Any pointers?
My first guess was that clock-frequency is wrong, but it seems that
this one actually is correct, at least it's the same thing that
the platform code sets.
You should never need to pass the virtual address to a device,
most of all because it cannot be known to the device tree at all.
The of_serial driver (you did enable that one in Kconfig, right?)
sets UPF_IOREMAP for this reason, which means membase gets
overwritten anyway.
You should also not need to set interrupt-parent in the device itself,
as long as it's set in the root node. This one should not hurt though.
Regarting the compatible value, you should check what
/proc/tty/driver/serial contains when the system is up and running.
If you can log into the system through the network after booting it
up, you can also compare the contents of that file and the 'setserial'
output with what you got before the device tree conversion.
Finally, something could be wrong with the interrupt controller.
AFAICT, you register it through the device tree now, but it's also
getting initialized through kirkwood_init_irq, so the numbers
would all be wrong.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
Am Mittwoch 07 März 2012, 20:27:23 schrieb Jason:
On Wed, Mar 07, 2012 at 06:31:31PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not
0xff. This is different from the way we define resources in Linux.
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Here's my most recent attempt:
serial@f1012000 {
device_type = serial;
compatible = ns16550a;
reg = 0xf1012000 0x100; /*phys addr*/
virt-reg = 0xfed12000; /*virt addr*/
reg-shift = 2;
reg-io-width = 1;
interrupts = 33;
current-speed = 115200;
interrupt-parent = intc;
clock-frequency = 2;
};
I've looked at what is done in the powerpc dt's, but, no luck. When
earlyprintk is enabled, I see no error messages, just:
bootconsole [earlycon0] enabled
debug: skip boot console de-registration.
...
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
Any pointers?
dunno if that helps a lot but the following was working for me with my
linkstation:
serial0: serial@f1012000 {
cell-index = 0;
device_type = serial;
compatible = ns16550a;
reg = 0xf1012000 0x20;
reg-shift = 2;
clock-frequency = 2;
interrupts = 33;
};
--
michael
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 09:05:15PM +0100, Andrew Lunn wrote:
On Wed, Mar 07, 2012 at 02:27:23PM -0500, Jason wrote:
On Wed, Mar 07, 2012 at 06:31:31PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason Cooper wrote:
+ serial@f1012000 {
+ compatible = ns16550a;
+ reg = 0xf1012000 0xff;
+ reg-shift = 2;
+ interrupts = 33;
+ clock-frequency = 2;
+ };
I just noticed that the length here should be inclusive, i.e. 0x100 not
0xff.
This is different from the way we define resources in Linux.
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Hi Jason
What do you see in /proc/iomem?
You should expect:
f1012000-f10120ff : serial8250.0
f1012000-f101201f : serial
f1012100-f10121ff : serial8250.1
f1012100-f101211f : serial
or probably just the first, if your device only has one serial port.
How about /proc/interrupts?
33:195 orion_irq serial
Anything like this in dmesg?
[ 17.189397] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 17.210023] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[ 17.624748] console [ttyS0] enabled
These two lines are what I'm missing. Some probe by printk shows
it's getting all the way through tty/serial/8250/8250.c:3263
serial8250_init() okay... then nothing.
[ 17.648555] serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
Comparing your system to the above might help you track down which
property is wrong.
Andrew
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 06/14] ARM: kirkwood: convert uart0 to devicetree.
On Wed, Mar 07, 2012 at 09:13:04PM +, Arnd Bergmann wrote:
On Wednesday 07 March 2012, Jason wrote:
Grrr. Now I'm getting frustrated. I'm trying to boot without
earlyprintk. Evidently, something is wrong with the above, because the
device boots all the way up (blinky lights come on), but I get no
messages after the usual Uncompressing Linux... done, booting the
kernel.
Here's my most recent attempt:
serial@f1012000 {
device_type = serial;
compatible = ns16550a;
reg = 0xf1012000 0x100; /*phys addr*/
virt-reg = 0xfed12000; /*virt addr*/
reg-shift = 2;
reg-io-width = 1;
interrupts = 33;
current-speed = 115200;
interrupt-parent = intc;
clock-frequency = 2;
};
I've looked at what is done in the powerpc dt's, but, no luck. When
earlyprintk is enabled, I see no error messages, just:
bootconsole [earlycon0] enabled
debug: skip boot console de-registration.
...
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
Any pointers?
The of_serial driver (you did enable that one in Kconfig, right?)
Wow. I can't believe I missed that. I now get:
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
without earlyprintk.
Thanks, Arnd.
Jason.
PS - the only change from your code is the 0x100. I'm going to do some
more testing...
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
