[U-Boot] [Question] bardrate both in gd_t and bd_t

[U-Boot] [Question] bardrate both in gd_t and bd_t

[Masahiro Yamada]

Hi.

I notice bardrate parameter bd_t as well as gd_t.


In include/asm-generic/global_data.h

typedef struct global_data {
	bd_t *bd;
	unsigned long flags;
	unsigned int baudrate;

We have "baudrate" here.




E.g. arch/arm/include/asm/u-boot.h

typedef struct bd_info {
	unsigned int	bi_baudrate;	/* serial console baudrate */

We have "bi_baudrate".



My question is what's the difference
between gd->baudrate and bd->bi_baudrate.
Why do we need both?

Since baudrate is a common paramter for all architectures,
bd->bi_baudrate looks weird to me.




Best Regards
Masahiro Yamada

[U-Boot] [Question] bardrate both in gd_t and bd_t

[Tom Rini]

On Wed, Apr 02, 2014 at 04:12:24PM +0900, Masahiro Yamada wrote:
> Hi.
> 
> I notice bardrate parameter bd_t as well as gd_t.
> 
> 
> In include/asm-generic/global_data.h
> 
> typedef struct global_data {
> 	bd_t *bd;
> 	unsigned long flags;
> 	unsigned int baudrate;
> 
> We have "baudrate" here.
> 
> 
> 
> 
> E.g. arch/arm/include/asm/u-boot.h
> 
> typedef struct bd_info {
> 	unsigned int	bi_baudrate;	/* serial console baudrate */
> 
> We have "bi_baudrate".
> 
> 
> 
> My question is what's the difference
> between gd->baudrate and bd->bi_baudrate.
> Why do we need both?
> 
> Since baudrate is a common paramter for all architectures,
> bd->bi_baudrate looks weird to me.

I think the answer is sadly just duplicated datastructures.  Simon do
you recall why we didn't drop this duplication before?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140403/67126e53/attachment.pgp>

[U-Boot] [Question] bardrate both in gd_t and bd_t

[Simon Glass]

Hi,

On 3 April 2014 14:01, Tom Rini <trini@ti.com> wrote:

> On Wed, Apr 02, 2014 at 04:12:24PM +0900, Masahiro Yamada wrote:
> > Hi.
> >
> > I notice bardrate parameter bd_t as well as gd_t.
> >
> >
> > In include/asm-generic/global_data.h
> >
> > typedef struct global_data {
> >       bd_t *bd;
> >       unsigned long flags;
> >       unsigned int baudrate;
> >
> > We have "baudrate" here.
> >
> >
> >
> >
> > E.g. arch/arm/include/asm/u-boot.h
> >
> > typedef struct bd_info {
> >       unsigned int    bi_baudrate;    /* serial console baudrate */
> >
> > We have "bi_baudrate".
> >
> >
> >
> > My question is what's the difference
> > between gd->baudrate and bd->bi_baudrate.
> > Why do we need both?
> >
> > Since baudrate is a common paramter for all architectures,
> > bd->bi_baudrate looks weird to me.
>
> I think the answer is sadly just duplicated datastructures.  Simon do
> you recall why we didn't drop this duplication before?  Thanks!
>

The duplication existed before generic board (i.e. each arch had its own
baudrate in global_data). I believe the reason for it being in bd_t is that
it can be passed to the kernel in that structure on some archs. So removing
it there may break some boards.

I suspect the reason it is in global_data is that the bd_t  structure
doesn't exist until some time after the console is started up, so it
wouldn't be possible to do serial output otherwise.

Regards,
Simon

[U-Boot] [Question] bardrate both in gd_t and bd_t

[Wolfgang Denk]

Dear Simon,

In message <CAPnjgZ2PrHue3hTW__MaYBRMA3OFZ3p1k9D49rZatur9G5x--g@mail.gmail.com> you wrote:
>
> The duplication existed before generic board (i.e. each arch had its own
> baudrate in global_data). I believe the reason for it being in bd_t is that
> it can be passed to the kernel in that structure on some archs. So removing
> it there may break some boards.

Correct. In some (really old) kernel versions this was the way to pass
this information to the kernel, so we neede dit there.

> I suspect the reason it is in global_data is that the bd_t  structure
> doesn't exist until some time after the console is started up, so it
> wouldn't be possible to do serial output otherwise.

Also correct.

Thanks!

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Always borrow money from a pessimist; they don't expect  to  be  paid
back.

[U-Boot] [Question] bardrate both in gd_t and bd_t

[Masahiro Yamada]

Hi Simon, Wolfgang,

On Thu, 03 Apr 2014 23:51:35 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Simon,
> 
> In message <CAPnjgZ2PrHue3hTW__MaYBRMA3OFZ3p1k9D49rZatur9G5x--g@mail.gmail.com> you wrote:
> >
> > The duplication existed before generic board (i.e. each arch had its own
> > baudrate in global_data). I believe the reason for it being in bd_t is that
> > it can be passed to the kernel in that structure on some archs. So removing
> > it there may break some boards.
> 
> Correct. In some (really old) kernel versions this was the way to pass
> this information to the kernel, so we neede dit there.
> 
> > I suspect the reason it is in global_data is that the bd_t  structure
> > doesn't exist until some time after the console is started up, so it
> > wouldn't be possible to do serial output otherwise.
> 
> Also correct.
> 

Thanks.
Sadly, it looks like we should keep both of the two.


Best Regards
Masahiro Yamada

[U-Boot] [Question] bardrate both in gd_t and bd_t

[Wolfgang Denk]

Dear Masahiro,

In message <20140404114250.5C15.AA925319@jp.panasonic.com> you wrote:
> 
> > Correct. In some (really old) kernel versions this was the way to pass
> > this information to the kernel, so we neede dit there.
> > 
> > > I suspect the reason it is in global_data is that the bd_t  structure
> > > doesn't exist until some time after the console is started up, so it
> > > wouldn't be possible to do serial output otherwise.
> > 
> > Also correct.
> > 
> 
> Thanks.
> Sadly, it looks like we should keep both of the two.

I'm not so sure.  As mentioned, this was used in really old kernel
versions only.  I remember it for the Power archtecture, where only
the pre-devicetree kernel versions (i. e. 2.4.x) used this.  OK, I
know of a number of projeects which are still using such old kernbel
versions, but these are also using ancient U-Boot versions.

I don't think we have to keep support for ancient kernels in current
U-Boot.  Eventually we may drop it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Why should we subsidize intellectual curiosity?" - Ronald Reagan

[U-Boot] [Question] bardrate both in gd_t and bd_t

[Masahiro Yamada]

Hi Wolfgang,


On Fri, 04 Apr 2014 11:22:17 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Masahiro,
> 
> In message <20140404114250.5C15.AA925319@jp.panasonic.com> you wrote:
> > 
> > > Correct. In some (really old) kernel versions this was the way to pass
> > > this information to the kernel, so we neede dit there.
> > > 
> > > > I suspect the reason it is in global_data is that the bd_t  structure
> > > > doesn't exist until some time after the console is started up, so it
> > > > wouldn't be possible to do serial output otherwise.
> > > 
> > > Also correct.
> > > 
> > 
> > Thanks.
> > Sadly, it looks like we should keep both of the two.
> 
> I'm not so sure.  As mentioned, this was used in really old kernel
> versions only.  I remember it for the Power archtecture, where only
> the pre-devicetree kernel versions (i. e. 2.4.x) used this.  OK, I
> know of a number of projeects which are still using such old kernbel
> versions, but these are also using ancient U-Boot versions.
> 
> I don't think we have to keep support for ancient kernels in current
> U-Boot.  Eventually we may drop it.

As a matter of fact, I had prepared a patch when I got replies
from you guys.
I've post it as RFC, just in case.
(I confirmed no boards broken at least build test.)

I am not sure if it can be dropped either.
Anyway, I follow Tom's decesion.


Best Regards
Masahiro Yamada