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

[Paul Gortmaker <paul.gortmaker@windriver.com>]

[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 11:32) Josh Boyer wrote:

> 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

I meant to say Yosemite board (and hence u-boot), sorry for that.  It
gives garbage up until the udbg -> ttyS0 handover, at which point the
console=ttyS0,115200 fixes things.

> >(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.

Had to go back to get this info; it turns out there is a valid prop in
all the serial nodes (2.6.31-rc7), and hexdumping it gives 0x2580 (9600).

> 
> 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.

Right - so there could still perhaps be the same issue with PIBS/bamboo
present that you saw earlier (given my inability to keep board names
straight)

> 
> >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.

This is the interesting part -- being a yosemite (u-boot), I would have
thought so as well.  I've not looked at the u-boot code, but it may only
add a current-speed if there isn't one yet.  At least that is what the
behaviour tends to indicate.  Board is running u-boot 1.3.3 so what we
are seeing here may not reflect what current u-boot code is doing
anyway...

> 
> >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.

Sure -- the testing effort will be greater than the time to make the
patch, so you doing coverage on all those would be great.  I think I've
probably only got easy immediate access to a PIBS/bamboo at the moment.
We already know the yosemite is OK with the change, so that is one less
to test.

Thanks,
Paul.

> 
> josh