RFC: delete UART current-speed from 4xx DTS?

Josh Boyer jwboyer at linux.vnet.ibm.com
Wed Sep 16 01:32:20 EST 2009


On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote:
>One of the guys here was getting a messed up console on a bamboo board
>(on linux boot), which he traced to the fact that the default dts has a
>9600 baudrate coded into it (board was running 115k2, not 9600).  Either
>deleting the line, or replacing the 9600 with zero fixed the problem.

Once booted, was there a valid current-speed property in /proc/device-tree
for the serial node?  I'm curious if U-Boot created it, or if the kernel
just used whatever baud was present already.

When I did the bamboo port a while ago, I recall having issues with either
a missing clock-frequency or current-speed (or both perhaps) and the bootloader
on the board was the original PIBS.  It might have been an issue with PIBS
but I'm guessing the rest of the 4xx boards copied from either Ebony or
Bamboo in their ports and hence contain that property.

>Looking at the Fsl boards, it seems that 99% of them don't list any
>current-speed at all.  I'm willing to whip up a patch to delete them

I think 99% of them use U-Boot, which should fix things up either way.

>from the various boards, but I thought I'd check 1st to see if there was
>some other reasoning/input.  I suppose one could argue that u-boot
>should be replacing the 9600 with 115k2 on the fly, but if the explicit
>specification isn't helping anyone, then it probably just makes sense to
>delete them anyway, I figured.

Yeah, that's probably valid.  I'd be happy to test on the set of boards I
have.

>Here is the subset of boards I was considering deleting the lines from:
>
>   bamboo.dts ebony.dts hcu4.dts holly.dts katmai.dts sam440ep.dts
>   sequoia.dts taishan.dts walnut.dts yosemite.dts

I can test bamboo with PIBS, ebony, holly (which isn't 4xx even though it's
a tree name) with PIBS, sequoia, taishan, yosemite, and walnut.  Perhaps a few
of the 405 boards I have as well.

It's easy enough for me to whip up a patch, and since I'll be testing either
way I'd be happy to do that if you'd like.

josh


More information about the Linuxppc-dev mailing list