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

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

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!

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

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

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

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

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
participants (4)
-
Masahiro Yamada
-
Simon Glass
-
Tom Rini
-
Wolfgang Denk