Kernel 3.4 on Dreamplug: no serial console

Kernel 3.4 on Dreamplug: no serial console

[Hans Kröner]

Hello,

I built a 3.4 kernel by grabbing the sources off kernel.org at
/pub/linux/kernel/v3.0/linux-3.4.tar.bz2

I built both the uImage with FDT support for the Dreamplug and it's respective
dtb, and placed them on the Dreamplug's internal SD. I made minor tweaks
to my U-boot env to handle FDT and proceeded to boot.

At first I thought the Dreamplug was hanging while booting the kernel, since
the console hangs at "Uncompressing Linux... done, booting the kernel."
However, doing the "post mortem" analysis and using U-boot to look at
__log_buf, I could see the kernel actually booting fine. I let it boot and
then SSHd into the box, everything seems fine.

I couldn't figure out why the serial console wasn't working, so I tried using
a newer kernel build. I cloned the 3.4 mainline git tree and built a new
kernel and dtb. This time, the kernel does hang! All I get as output
when doing the "post mortem" analysis is: "Booting Linux on physical
CPU 0."

Did I miss something while configuring the kernel? Am I not
understanding FDT and my U-boot env is messed? I'm attaching both
my U-boot env and .config in hopes that someone can help me figure
this out.

Thanks in advance!!!

Hans

----------
U-boot env
----------
baudrate=115200
bootargs=console=ttyS0,115200
bootcmd=${x_bootcmd_usb}; ${x_bootcmd_kernel};
${x_bootcmd_fdt}; setenv bootargs ${x_bootargs} 
${x_bootargs_root}; bootm 0x6400000 - 0xd000000;
bootdelay=3
eth1addr=F0:AD:4E:00:E0:55
ethact=egiga0
ethaddr=F0:AD:4E:00:E0:56
serial_num=DS2-1148-000242
stderr=serial
stdin=serial
stdout=serial
x_bootargs=console=ttyS0,115200n8 earlyprintk
x_bootargs_root=root=/dev/sda2 rootdelay=10 rootfstype=ext4
x_bootcmd_ethernet=ping 192.168.0.110
x_bootcmd_fdt=ext2load usb 0 0xd000000 kirkwood-dreamplug.dtb
x_bootcmd_kernel=ext2load usb 0 0x6400000 uImage
x_bootcmd_usb=usb start

Kernel 3.4 on Dreamplug: no serial console

[Adam Baker]

On Saturday 02 Jun 2012 12:20:59 Hans Kr?ner wrote:
> Hello,
> 
> I built a 3.4 kernel by grabbing the sources off kernel.org at
> /pub/linux/kernel/v3.0/linux-3.4.tar.bz2
> 
> I built both the uImage with FDT support for the Dreamplug and it's
> respective dtb, and placed them on the Dreamplug's internal SD. I made
> minor tweaks to my U-boot env to handle FDT and proceeded to boot.
> 
> At first I thought the Dreamplug was hanging while booting the kernel, since
> the console hangs at "Uncompressing Linux... done, booting the kernel."
> However, doing the "post mortem" analysis and using U-boot to look at
> __log_buf, I could see the kernel actually booting fine. I let it boot and
> then SSHd into the box, everything seems fine.

your .config doesn't seem to be attached but this sounds similiar to the 
problem I had when converting a kernel config to FDT because I didn't have

CONFIG_SERIAL_OF_PLATFORM=y

which is needed to support configuring serial ports with FDT

Hope that Helps

Adam

Kernel 3.4 on Dreamplug: no serial console

[Andrew Lunn]

Hi Hans

Do you have SERIAL_OF_PLATFORM enabled. Without that, the serial ports
won't work.

   Andrew

Kernel 3.4 on Dreamplug: no serial console

[Hans Kröner]

Hi again,

Many thanks to the both of you. CONFIG_SERIAL_OF_PLATFORM was exactly what
I was missing in my .config

Thanks a bunch!

Hans

Kernel 3.4 on Dreamplug: no serial console

[Adam Baker]

On Sunday 03 Jun 2012 15:26:14 Hans Kr?ner wrote:
> Hi again,
> 
> Many thanks to the both of you. CONFIG_SERIAL_OF_PLATFORM was exactly what
> I was missing in my .config
> 

As there are now two of us who have been tripped up by this does anyone think 
the untested patch below is

a) worthwhile
b) likely to be acceptable
c) likely to work

It feels wrong to be putting something arch specific in such general code but 
setting it as a default is cleaner than trying to select it from 
ARCH_KIRKWOOD_DT because default respects depends lines.

--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1021,6 +1021,7 @@ config SERIAL_OF_PLATFORM
        tristate "Serial port on Open Firmware platform bus"
        depends on OF
        depends on SERIAL_8250 || SERIAL_OF_PLATFORM_NWPSERIAL
+        default y if ARCH_KIRKWOOD_DT
        help
          If you have a PowerPC based system that has serial ports
          on a platform specific bus, you should enable this option.

Kernel 3.4 on Dreamplug: no serial console

[Arnd Bergmann]

On Sunday 03 June 2012, Adam Baker wrote:
> As there are now two of us who have been tripped up by this does anyone think 
> the untested patch below is
> 
> a) worthwhile

yes

> b) likely to be acceptable

no

> c) likely to work

yes

> It feels wrong to be putting something arch specific in such general code but 
> setting it as a default is cleaner than trying to select it from 
> ARCH_KIRKWOOD_DT because default respects depends lines.

Just put it into the kirkwood_defconfig file, that is the cleanest approach by
far. We might still get a few people who run into this problem when updating,
but in the long run it will be ok.

I'd also accept a patch to make ARCH_KIRKWOOD_DT select OF_SERIAL if people
prefer that, but I think just changing the defconfig is better.

	Arnd

Kernel 3.4 on Dreamplug: no serial console

[Jason Cooper]

On Sun, Jun 03, 2012 at 05:12:18PM +0000, Arnd Bergmann wrote:
> I'd also accept a patch to make ARCH_KIRKWOOD_DT select OF_SERIAL if people
> prefer that, but I think just changing the defconfig is better.

I'd prefer the defconfig as there are situations where users/oems deploy
a kernel without support for serial console.  In order to do that with
your patch, or similar approaches, they would have to change the code.
With defconfig, they don't.

FYI: there is a running problem with kirkwood_defconfig that I haven't
had time to look into.  I've been doing 'make oldconfig' and thus never
encountered the problem.

The problem involves CONFIG_ARM_PATCH_PHYS_VIRT and causes the system
not to boot.  I'm not sure if this is dreamplug specific, kirkwood, or
all orion.  I've only heard reports regarding dreamplug, but that
doesn't mean it's limited to that board.

I'd like to have the defconfig working by the time the DT conversion is
complete, but I'm currently giving DT conversion higher priority.  So,
if anyone wants to take a crack at solving it, please do.  Otherwise, I
plan on taking a look at it after the driver bindings are done.

thx,

Jason.

Kernel 3.4 on Dreamplug: no serial console

[Andrew Lunn]

> The problem involves CONFIG_ARM_PATCH_PHYS_VIRT and causes the system
> not to boot.  I'm not sure if this is dreamplug specific, kirkwood, or
> all orion.  I've only heard reports regarding dreamplug, but that
> doesn't mean it's limited to that board.

It seems to be kirkwood. Orion5x does not have the problem.

   Andrew

Kernel 3.4 on Dreamplug: no serial console

[Florian Fainelli]

Hi,

On Sunday 03 June 2012 14:40:49 Jason Cooper wrote:
> On Sun, Jun 03, 2012 at 05:12:18PM +0000, Arnd Bergmann wrote:
> > I'd also accept a patch to make ARCH_KIRKWOOD_DT select OF_SERIAL if 
people
> > prefer that, but I think just changing the defconfig is better.
> 
> I'd prefer the defconfig as there are situations where users/oems deploy
> a kernel without support for serial console.  In order to do that with
> your patch, or similar approaches, they would have to change the code.
> With defconfig, they don't.

Should not you rather select OF_SERIAL and add a status propery to the uart 
node in device tree, so that it is up to dtb provider to determine whether 
this device node should be enabled or not? You would avoid all kind of 
defconfig issue.

> 
> FYI: there is a running problem with kirkwood_defconfig that I haven't
> had time to look into.  I've been doing 'make oldconfig' and thus never
> encountered the problem.
> 
> The problem involves CONFIG_ARM_PATCH_PHYS_VIRT and causes the system
> not to boot.  I'm not sure if this is dreamplug specific, kirkwood, or
> all orion.  I've only heard reports regarding dreamplug, but that
> doesn't mean it's limited to that board.
> 
> I'd like to have the defconfig working by the time the DT conversion is
> complete, but I'm currently giving DT conversion higher priority.  So,
> if anyone wants to take a crack at solving it, please do.  Otherwise, I
> plan on taking a look at it after the driver bindings are done.
> 
> thx,
> 
> Jason.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Kernel 3.4 on Dreamplug: no serial console

[Arnd Bergmann]

On Monday 04 June 2012, Florian Fainelli wrote:
> On Sunday 03 June 2012 14:40:49 Jason Cooper wrote:
> > On Sun, Jun 03, 2012 at 05:12:18PM +0000, Arnd Bergmann wrote:
> > > I'd also accept a patch to make ARCH_KIRKWOOD_DT select OF_SERIAL if 
> people
> > > prefer that, but I think just changing the defconfig is better.
> > 
> > I'd prefer the defconfig as there are situations where users/oems deploy
> > a kernel without support for serial console.  In order to do that with
> > your patch, or similar approaches, they would have to change the code.
> > With defconfig, they don't.
> 
> Should not you rather select OF_SERIAL and add a status propery to the uart 
> node in device tree, so that it is up to dtb provider to determine whether 
> this device node should be enabled or not? You would avoid all kind of 
> defconfig issue.

Obviously the configuration comes from DT, but there are still reasons to
not select the driver. E.g. you might want to build a kernel that runs on
a wide variety of systems and has all drivers as loadable modules rather than
built-in. There are also some systems that are rather memory constraint and
even disable printk support, so the console becomes useless too.

	Arnd