[Re: RFC: delete UART current-speed from 4xx DTS?] On 15/09/2009 (Tue 16:02) Josh Boyer wrote:
> On Tue, Sep 15, 2009 at 03:32:05PM -0400, Paul Gortmaker wrote: > >[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. > > Ok. > > >> >(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). > > Sorry, that was after you removed the property in the DTS entirely, or setting > it to 0, or just using the existing DTS as-is? I should have phrased my > question better, but I think I answered it myself already. > > In my brief test with Sequoia and Bamboo, I removed the current-speed property > entirely and once booted there was no property in the serial node, which is > what I would expect for the old version of U-Boot on these boards. The good > news is that it seems to work fine :). Yep - and if there is a node with a current-speed that differs from what u-boot (1.3.3) is actively using, that current-speed setting will take precedence for early printk and also that baud will appear in the /proc/device-tree (just to clarify on what I'd tried to convey earlier). [...] > >> 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. > > OK, sounds good. I'll do some more testing over the next few days and post > a patch. Thanks for bringing this to my attention. No problem; thanks for the quick response and volunteering to test on the boards you have. Paul. > > josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev