Re: [U-Boot] U-Boot support for board(s) meesc, otc570
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
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.
Please send always the mailing list, too!
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
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
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
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
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
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
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
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
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
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
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,
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
participants (3)
-
Albert ARIBAUD -
Daniel Gorsulowski -
Reinhard Meyer