[U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

Simon Glass sjg at chromium.org
Fri Oct 12 03:14:38 CEST 2012


Hi Graham,

On Thu, Oct 11, 2012 at 6:00 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon,
>
> On Fri, Oct 12, 2012 at 11:55 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi,
>>
>> On Thu, Oct 11, 2012 at 5:51 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Oct 12, 2012 at 11:46 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Wolfgang,
>>>>
>>>> On Thu, Oct 11, 2012 at 12:32 AM, Wolfgang Denk <wd at denx.de> wrote:
>>>>> Dear Simon Glass,
>>>>>
>>>>> In message <1349910781-32088-2-git-send-email-sjg at chromium.org> you wrote:
>>>>>> This is a ulong for some architectures and just unsigned for others.
>>>>>> Change x86 to be consistent.
>>>>>
>>>>> Given the limited range for this variable it makes no sense to use a
>>>>> long for this.  Please fix this the other way round, i. e. change the
>>>>> architectures that use a long.
>>>>
>>>> OK I will send out a series that changes them to unsigned long.
>>>
>>> Should we just change them all to u32 to be clear on the value range?
>>
>> Sorry, I meant unsigned int.
>>
>> Are there architectures in U-Boot which use a 16-bit int?
>
> The C standard does not guarantee unsigned int will be at least
> 32-bits. It is possible (although I have not checked it) that
> compiling 'real-mode' x86 code can produce 16-bit ints (not that we do
> that in U-Boot)
>
> using u32 will always guarantee a 32-bit unsigned value - better to be
> safe than sorry
>

That's fine, but what about all the other fields? Does the same apply
here? It seems that everything uses 'unsigned int' for u32:

arch/nds32/include/asm/types.h:47:typedef unsigned int u32;
arch/avr32/include/asm/types.h:65:typedef unsigned int u32;
arch/arm/include/asm/types.h:37:typedef unsigned int u32;
arch/sandbox/include/asm/types.h:59:typedef unsigned int u32;
arch/blackfin/include/asm/types.h:70:typedef unsigned int u32;
arch/openrisc/include/asm/types.h:64:typedef unsigned int u32;
arch/mips/include/asm/types.h:62:typedef unsigned int u32;
arch/x86/include/asm/types.h:37:typedef unsigned int u32;
arch/nios2/include/asm/types.h:45:typedef unsigned int u32;
arch/sh/include/asm/types.h:46:typedef unsigned int u32;
arch/microblaze/include/asm/types.h:45:typedef unsigned int u32;
arch/powerpc/include/asm/types.h:37:typedef unsigned int u32;
arch/m68k/include/asm/types.h:37:typedef unsigned int u32;
arch/sparc/include/asm/types.h:58:typedef unsigned int u32;


I wonder then if we need to decide which to use (int or long). I
presume 'long' was used to cope with 16-bit machines, but we don't
actually have any (which is presumably Wolfgang's point). If we don't
have any, then 'int' is safe. I'm just a bit unsure about changing a
single field in these two structures to u32, when all the others are
unsigned long/short.

For example:

typedef struct bd_info {
    int			bi_baudrate;	/* serial console baudrate */
    ulong	        bi_arch_number;	/* unique id for this board */
    ulong	        bi_boot_params;	/* where this board expects params */
	unsigned long	bi_arm_freq; /* arm frequency */
	unsigned long	bi_dsp_freq; /* dsp core frequency */
	unsigned long	bi_ddr_freq; /* ddr frequency */
    struct				/* RAM configuration */
    {
	ulong start;
	ulong size;
    }			bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;


typedef	struct	global_data {
	bd_t		*bd;
	unsigned long	flags;
	unsigned long	baudrate;
	unsigned long	have_console;	/* serial_init() was called */
#ifdef CONFIG_PRE_CONSOLE_BUFFER
	unsigned long	precon_buf_idx;	/* Pre-Console buffer index */
#endif
	unsigned long	env_addr;	/* Address  of Environment struct */
	unsigned long	env_valid;	/* Checksum of Environment valid? */
	unsigned long	fb_base;	/* base address of frame buffer */
#ifdef CONFIG_FSL_ESDHC
	unsigned long	sdhc_clk;
#endif
#ifdef CONFIG_AT91FAMILY
	/* "static data" needed by at91's clock.c */
	unsigned long	cpu_clk_rate_hz;
	unsigned long	main_clk_rate_hz;
	unsigned long	mck_rate_hz;
	unsigned long	plla_rate_hz;
	unsigned long	pllb_rate_hz;
	unsigned long	at91_pllb_usb_init;
#endif
#ifdef CONFIG_ARM
	/* "static data" needed by most of timer.c on ARM platforms */
	unsigned long	timer_rate_hz;
	unsigned long	tbl;
	unsigned long	tbu;
	unsigned long long	timer_reset_value;
	unsigned long	lastinc;


Guidance appreciated!

....

> Regards,
>
> Graeme

Regards,
Simon


More information about the U-Boot mailing list