[U-Boot] U-Boot support for board(s) meesc, otc570

[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Dear Daniel Gorsulowski,
> Hello Albert,
> 
> Albert ARIBAUD wrote:
>> Le 18/01/2011 10:27, Daniel Gorsulowski a ?crit :
>>> Hello again!
>>
>> Hi Daniel,
>>
>>> One month ago, I asked you for help (see message below), but got no
>>> answer.
>>
>> Sorry about that. Last quarter of 2010 was rather busy for me.
>>
>>> Do you see any chance, to fix the at91 tree?
>>>
>>> There is no way to fix my boards, as long as all at91 builds have
>>> fundamental problems.
>>>
>>> I found a patch series from Alexander Stein, but it seems, this series
>>> does not go mainline:
>>> http://lists.denx.de/pipermail/u-boot/2010-November/080885.html
>>> Should I ask Alexander for resend his pathes?
>>>
>>> Regards
>>> Daniel
>>
>> Reinhard (Cc:) has lots of fixes in his u-boot-atmel tree; you should try
>> its master branch. I'm leaving below your (unanswered, apologies again)
>> questions for Reinhard to answer.
>>
>> Regards,
>> Albert.
> 
> Thanks for your response!
> I tried Reinhards master branch, but build throws same errors as shown
> below. It seems, among other things the atmel usart driver needs an
> update to new SoC access. Alexander Steins patch series seems to add this
> support.
> 
> I'll wait for a fix until I send patches for my boards.

1. Please send always the mailing list, too!

2. Use the rework101229 branch (minus the last 5 patches).

There is lot of cleanup done in the header files and the ATMEL drivers.
The at91sam9260(9xe)ek board builds fine and works.
Use that as a template or reference what to do.
You should *only* need to adapt board/*/files and your configs/<board>.h
files. And of course updated entries in boards.cfg.

Once the rework is done for *almost* *ALL* AT91 SoCs it will be put for
review into mainline, probably for the 06.2011 U-Boot.

Best Regards,
Reinhard

[U-Boot] U-Boot support for board(s) meesc, otc570

[Daniel Gorsulowski]

Hello Reinhard,

Reinhard Meyer wrote:
> Dear Daniel Gorsulowski,
>> Hello Albert,
>>
>> Albert ARIBAUD wrote:
>>> Le 18/01/2011 10:27, Daniel Gorsulowski a ?crit :
>>>> Hello again!
>>>
>>> Hi Daniel,
>>>
>>>> One month ago, I asked you for help (see message below), but got no
>>>> answer.
>>>
>>> Sorry about that. Last quarter of 2010 was rather busy for me.
>>>
>>>> Do you see any chance, to fix the at91 tree?
>>>>
>>>> There is no way to fix my boards, as long as all at91 builds have
>>>> fundamental problems.
>>>>
>>>> I found a patch series from Alexander Stein, but it seems, this series
>>>> does not go mainline:
>>>> http://lists.denx.de/pipermail/u-boot/2010-November/080885.html
>>>> Should I ask Alexander for resend his pathes?
>>>>
>>>> Regards
>>>> Daniel
>>>
>>> Reinhard (Cc:) has lots of fixes in his u-boot-atmel tree; you should try
>>> its master branch. I'm leaving below your (unanswered, apologies again)
>>> questions for Reinhard to answer.
>>>
>>> Regards,
>>> Albert.
>>
>> Thanks for your response!
>> I tried Reinhards master branch, but build throws same errors as shown
>> below. It seems, among other things the atmel usart driver needs an
>> update to new SoC access. Alexander Steins patch series seems to add this
>> support.
>>
>> I'll wait for a fix until I send patches for my boards.
> 
> 1. Please send always the mailing list, too!
> 
> 2. Use the rework101229 branch (minus the last 5 patches).
> 
> There is lot of cleanup done in the header files and the ATMEL drivers.
> The at91sam9260(9xe)ek board builds fine and works.

I can confirm that.

> Use that as a template or reference what to do.
> You should *only* need to adapt board/*/files and your configs/<board>.h
> files. And of course updated entries in boards.cfg.

Not quiet. I had to fix arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c
additionally.

With my adoptions, my boards builds fine. But they do not boot.
Can you really confirm that the at91sam9260ek board boots? I have no
chance to debug my problems, so I have no idea, why my boards does not boot.

Nevertheless, should I send my patches for reviewing?

> 
> Once the rework is done for *almost* *ALL* AT91 SoCs it will be put for
> review into mainline, probably for the 06.2011 U-Boot.
> 
> Best Regards,
> Reinhard
> 


-- 
Best Regards,
Daniel Gorsulowski

-------------------------------------------------------------------------
B.Eng. Daniel Gorsulowski
System-Design

esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Telefon: 0511-37298-192 - Fax: 0511-37298-68
Bitte besuchen Sie uns im Internet unter http://www.esd.eu
Quality Products - Made in Germany
-------------------------------------------------------------------------
Gesch?ftsf?hrer: Klaus Detering
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-------------------------------------------------------------------------

[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Dear Daniel Gorsulowski,
> Hello Reinhard,
>
> Reinhard Meyer wrote:
>> Dear Daniel Gorsulowski,

...

>> The at91sam9260(9xe)ek board builds fine and works.
>
> I can confirm that.
>
>> Use that as a template or reference what to do.
>> You should *only* need to adapt board/*/files and your configs/<board>.h
>> files. And of course updated entries in boards.cfg.
>
> Not quiet. I had to fix arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c
> additionally.
Yes, of course... I had only "reworked" the 9260 variant yet. You should need
to change it similarly to at91sam9260_devices.c...
>
> With my adoptions, my boards builds fine. But they do not boot.
> Can you really confirm that the at91sam9260ek board boots? I have no
> chance to debug my problems, so I have no idea, why my boards does not boot.
Yes it does.

What exactly does "does not boot" mean? No message at all?

Check that your AT91Bootstrap loads u-boot to a sane address not at the very end
of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where AT91Bootstrap
loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin of DRAM
for our boards.)

>
> Nevertheless, should I send my patches for reviewing?
>

Of course. We might see something that helps you.

Best Regards,
Reinhard

[U-Boot] U-Boot support for board(s) meesc, otc570

[Daniel Gorsulowski]

Dear Reinhard,

Reinhard Meyer wrote:
> Dear Daniel Gorsulowski,
>> Hello Reinhard,
>>
>> Reinhard Meyer wrote:
>>> Dear Daniel Gorsulowski,
> 
> ...
> 
>>> The at91sam9260(9xe)ek board builds fine and works.
>>
>> I can confirm that.
>>
>>> Use that as a template or reference what to do.
>>> You should *only* need to adapt board/*/files and your configs/<board>.h
>>> files. And of course updated entries in boards.cfg.
>>
>> Not quiet. I had to fix arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c
>> additionally.
> Yes, of course... I had only "reworked" the 9260 variant yet. You should
> need
> to change it similarly to at91sam9260_devices.c...
>>
>> With my adoptions, my boards builds fine. But they do not boot.
>> Can you really confirm that the at91sam9260ek board boots? I have no
>> chance to debug my problems, so I have no idea, why my boards does not
>> boot.
> Yes it does.
> 
> What exactly does "does not boot" mean? No message at all?

Yes, sorry for indefinite description...
There is no message at all, except for bootrom 'RomBOOT' promt.

> 
> Check that your AT91Bootstrap loads u-boot to a sane address not at the
> very end
> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
> AT91Bootstrap
> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin
> of DRAM
> for our boards.)
> 

I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address,
so the problem must be located elsewhere.

Today I found out by GPIO debugging, that U-Boot seems to boot but prints
its startup messages to wrong USART with proper baudrate. I'll try to
find out, why there is no output on DBGU.

>>
>> Nevertheless, should I send my patches for reviewing?
>>
> 
> Of course. We might see something that helps you.

Ok, I'll do so.

> 
> Best Regards,
> Reinhard
> 
> 
> 
Best regards,
Daniel Gorsulowski

[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Dear Daniel Gorsulowski,
> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
> its startup messages to wrong USART with proper baudrate. I'll try to
> find out, why there is no output on DBGU.

Note that the USART to use is defined differently than before:

/* serial console */
#define CONFIG_ATMEL_USART
#define CONFIG_USART_BASE		ATMEL_BASE_DBGU
#define	CONFIG_USART_ID			ATMEL_ID_SYS
#define CONFIG_BAUDRATE			115200
#define CONFIG_SYS_BAUDRATE_TABLE	{115200 , 19200, 38400, 57600, 9600 }

Best Regards,
Reinhard

[U-Boot] U-Boot support for board(s) meesc, otc570

[Daniel Gorsulowski]

Hello Reinhard,

Reinhard Meyer wrote:
> Dear Daniel Gorsulowski,
>> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
>> its startup messages to wrong USART with proper baudrate. I'll try to
>> find out, why there is no output on DBGU.
> 
> Note that the USART to use is defined differently than before:
> 
> /* serial console */
> #define CONFIG_ATMEL_USART
> #define CONFIG_USART_BASE		ATMEL_BASE_DBGU
> #define	CONFIG_USART_ID			ATMEL_ID_SYS
> #define CONFIG_BAUDRATE			115200
> #define CONFIG_SYS_BAUDRATE_TABLE	{115200 , 19200, 38400, 57600, 9600 }

I did so, see http://lists.denx.de/pipermail/u-boot/2011-January/085863.html

But I'm a little bit confused. In the past, USART_ID was defined by '3',
if DBGU was used. Now, USART_ID is replaced by CONFIG_USART_ID, which is
defined by ATMEL_ID_SYS, which is defined by '1'.
However, this discrepancy does not matter, because CONFIG_USART_ID is
only used once in drivers/serial/atmel_usart.c, line 57:
usart_hz = get_usart_clk_rate(USART_ID);
And get_usart_clk_rate(); ignores its parameter. See
arch/arm/include/asm/arch-at91/clk.h
static inline unsigned long get_usart_clk_rate(unsigned int dev_id)
{
        return get_mck_clk_rate();
}
(all other functions in clk.h act similar. I think, a rework would be
advisable?)

Back to the problem...
In my opinion, my USART configuration is correct. I still have no idea,
why there is no output on DBGU.

> 
> Best Regards,
> Reinhard

Regards,
Daniel

[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Dear Daniel Gorsulowski,
> Hello Reinhard,
>
> Reinhard Meyer wrote:
>> Dear Daniel Gorsulowski,
>>> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
>>> its startup messages to wrong USART with proper baudrate. I'll try to
>>> find out, why there is no output on DBGU.
>>
>> Note that the USART to use is defined differently than before:
>>
>> /* serial console */
>> #define CONFIG_ATMEL_USART
>> #define CONFIG_USART_BASE		ATMEL_BASE_DBGU
>> #define	CONFIG_USART_ID			ATMEL_ID_SYS
>> #define CONFIG_BAUDRATE			115200
>> #define CONFIG_SYS_BAUDRATE_TABLE	{115200 , 19200, 38400, 57600, 9600 }
>
> I did so, see http://lists.denx.de/pipermail/u-boot/2011-January/085863.html
>
> But I'm a little bit confused. In the past, USART_ID was defined by '3',
> if DBGU was used. Now, USART_ID is replaced by CONFIG_USART_ID, which is
> defined by ATMEL_ID_SYS, which is defined by '1'.
> However, this discrepancy does not matter, because CONFIG_USART_ID is
> only used once in drivers/serial/atmel_usart.c, line 57:
> usart_hz = get_usart_clk_rate(USART_ID);
> And get_usart_clk_rate(); ignores its parameter. See
> arch/arm/include/asm/arch-at91/clk.h

That is correct for AT91. However AVR32 has separate clock dividers for each USART.
The atmel_usart driver is the same for both architectures. For that reason the ID
is carried along but nowhere used in AT91 clock code. But who knows, maybe there will be
an AT91 variant in the future with different clocks for each peripheral...

What matters is that the driver uses the value of CONFIG_USART_BASE to access the
registers. This value you have set (correctly) to ATMEL_BASE_DBGU. So by all
reasoning output should not come out any other USART...

> static inline unsigned long get_usart_clk_rate(unsigned int dev_id)
> {
>          return get_mck_clk_rate();
> }
> (all other functions in clk.h act similar. I think, a rework would be
> advisable?)

No, in AVR32 those functions are different for each peripheral.

>
> Back to the problem...
> In my opinion, my USART configuration is correct. I still have no idea,
> why there is no output on DBGU.

I am at a loss there, too.

Which USART is the output coming from instead? Is it really console output
or maybe some other, independent pulses?

Can you verify that the value for ATMEL_BASE_DBGU in at91sam9263.h is correct?

Are you using the actual driver source? It should have lines like
         atmel_usart3_t *usart = (atmel_usart3_t*)CONFIG_USART_BASE;
at the begin of each function.

Best Regards,
Reinhard

[U-Boot] U-Boot support for board(s) meesc, otc570

[Daniel Gorsulowski]

Hello Reinhard,

...
>>
>> Back to the problem...
>> In my opinion, my USART configuration is correct. I still have no idea,
>> why there is no output on DBGU.
>
> I am at a loss there, too.
>
> Which USART is the output coming from instead? Is it really console output
> or maybe some other, independent pulses?

I don't know, to which USART the output goes. I guess you assume, my
"GPIO debugging" was to meassure the pulses on the USART pins. But no, my
GPIO debugging was as follows:
-set gpio pin with led attached
-send characters by puts() (wherever it goes) ;-)
-reset gpio pin
-measure time between high- and low- rising edge on gpio pin
-calculate baudrate

(on DBGU pin, there is no pulse at all past starting U-Boot)

>
> Can you verify that the value for ATMEL_BASE_DBGU in at91sam9263.h is
> correct?

Yes, according to datasheet, Debug Unit Control Register (DBGU_CR) is
located at 0xFFFFEE00.
And in at91sam9263.h is defined:
#define ATMEL_BASE_DBGU         0xffffee00

>
> Are you using the actual driver source? It should have lines like
>         atmel_usart3_t *usart = (atmel_usart3_t*)CONFIG_USART_BASE;
> at the begin of each function.

Yes, I'm using the driver with your changes from 2010-11-03 16:32:56

>
> Best Regards,
> Reinhard
>
>

Best Regards,
Daniel

[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Hello Daniel,
> Hello Reinhard,
>> Which USART is the output coming from instead? Is it really console output
>> or maybe some other, independent pulses?
> 
> I don't know, to which USART the output goes. I guess you assume, my
> "GPIO debugging" was to meassure the pulses on the USART pins. But no, my
> GPIO debugging was as follows:
> -set gpio pin with led attached
> -send characters by puts() (wherever it goes) ;-)
> -reset gpio pin
> -measure time between high- and low- rising edge on gpio pin
> -calculate baudrate
> 
> (on DBGU pin, there is no pulse at all past starting U-Boot)
> 
>>
>> Can you verify that the value for ATMEL_BASE_DBGU in at91sam9263.h is
>> correct?
> 
> Yes, according to datasheet, Debug Unit Control Register (DBGU_CR) is
> located at 0xFFFFEE00.
> And in at91sam9263.h is defined:
> #define ATMEL_BASE_DBGU         0xffffee00
(I could have made an error there while reworking)

I think its now safe to assume that the DBGU UART is really used, but maybe
the GPIO pins are not correctly assigned to it. Try to look in the
at91sam9263_devices.c area, seriald_init().. Is it called, and does it do the
"right" thing?

It must be something rather trivial...

Best Regards,
Reinhard

[U-Boot] U-Boot support for board(s) meesc, otc570

[Daniel Gorsulowski]

Hello Reinhard,

...
>>
>> Check that your AT91Bootstrap loads u-boot to a sane address not at the
>> very end
>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
>> AT91Bootstrap
>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin
>> of DRAM
>> for our boards.)
>>
> 
> I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address,
> so the problem must be located elsewhere.
> 
> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
> its startup messages to wrong USART with proper baudrate. I'll try to
> find out, why there is no output on DBGU.
> 

I have to correct myself.
My board_init() and checkboard() fanctions are executed. But the board
crashes, before misc_init_r() functions executes.
(I guess, it crashes somwhere in board_init_f())
I'll try to find out more infos. But without an appropriate opportunity
to debug, it will be verry difficult.


Best regards
Daniel

[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Dear Daniel Gorsulowski,
> Hello Reinhard,
> 
> ...
>>>
>>> Check that your AT91Bootstrap loads u-boot to a sane address not at the
>>> very end
>>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
>>> AT91Bootstrap
>>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin
>>> of DRAM
>>> for our boards.)
>>>
>>
>> I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address,
>> so the problem must be located elsewhere.

Not necessaryly. You have not changed them, but who says they were correct before?
I am not sure, but before relocation it might have not mattered if they were
different. Just really check to make sure.

>>
>> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
>> its startup messages to wrong USART with proper baudrate. I'll try to
>> find out, why there is no output on DBGU.
>>
> 
> I have to correct myself.
> My board_init() and checkboard() fanctions are executed. But the board
> crashes, before misc_init_r() functions executes.
> (I guess, it crashes somwhere in board_init_f())
> I'll try to find out more infos. But without an appropriate opportunity
> to debug, it will be verry difficult.

I can only advice a step by step approach: Take the at91sam9260ek port and
only change the bits that are different for 9263 and your board. I don't have any
9263 based board here, so I cannot point to a proven, working port for that SoC.

Best Regards,
Reinhard

[U-Boot] U-Boot support for board(s) meesc, otc570

[Albert ARIBAUD]

Le 24/01/2011 12:39, Daniel Gorsulowski a ?crit :
> Hello Reinhard,
>
> ...
>>>
>>> Check that your AT91Bootstrap loads u-boot to a sane address not at the
>>> very end
>>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
>>> AT91Bootstrap
>>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin
>>> of DRAM
>>> for our boards.)
>>>
>>
>> I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address,
>> so the problem must be located elsewhere.
>>
>> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
>> its startup messages to wrong USART with proper baudrate. I'll try to
>> find out, why there is no output on DBGU.
>>
>
> I have to correct myself.
> My board_init() and checkboard() fanctions are executed. But the board
> crashes, before misc_init_r() functions executes.
> (I guess, it crashes somwhere in board_init_f())
> I'll try to find out more infos. But without an appropriate opportunity
> to debug, it will be verry difficult.

Make sure nothing executes under board_init_f() that tries to write to 
BSS (uninitialized) variables: BSS does not actually exist until after 
relocation, and writing to the would-be BSS area will cause corruption 
of the U-boot code. Not sure this is what happens with you but better 
safe than sorry.

> Best regards
> Daniel

Amicalement,
-- 
Albert.

[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Dear Daniel Gorsulowski,

>>> Check that your AT91Bootstrap loads u-boot to a sane address not at the
>>> very end
>>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
>>> AT91Bootstrap
>>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin
>>> of DRAM
>>> for our boards.)
>>>
>>
>> I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address,
>> so the problem must be located elsewhere.
>>
>> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
>> its startup messages to wrong USART with proper baudrate. I'll try to
>> find out, why there is no output on DBGU.
>>
> 
> I have to correct myself.
> My board_init() and checkboard() fanctions are executed. But the board
> crashes, before misc_init_r() functions executes.
> (I guess, it crashes somwhere in board_init_f())
> I'll try to find out more infos. But without an appropriate opportunity
> to debug, it will be verry difficult.

Any updates on this patch yet?

Best Regards,

Reinhard