Re: [U-Boot] Strange / Unreadable console output
Hi Markus,
On 16.08.2012 17:07, Markus Hubig wrote:
> Dear Andreas,
>
> On Wed, Aug 15, 2012 at 12:55 PM, Andreas Bießmann wrote:
>> On 14.08.2012 17:11, Markus Hubig wrote:
>>> On Tue, Aug 14, 2012 at 02:03:55PM +0200, Andreas Bießmann wrote:
On 14.08.2012 11:08, Markus Hubig wrote:
> On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
>> On 27.07.12 11:16, Markus Hubig wrote:
>
>
>
>>> | int board_early_init_f(void)
>>> | {
>>> | struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
>>> |
>>> | /* Enable clocks for all PIOs */
>>> | writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) |
>>> | (1 << ATMEL_ID_PIOC), &pmc->pcer);
>>> |
>>> | /* Enable the serial interface */
>>> | at91_set_gpio_output(AT91_PIN_PC9, 1);
>>> | mdelay(1000);
>>> | at91_seriald_hw_init();
>>> |
>>> | return 0;
>>> | }
>>
>> Can you just test the delay in board_init()? I think it should remove
>> the wired characters.
>
> Yes, the strange chars are gone with a small delay after enabling PC9!
>
> | --- a/board/taskit/stamp9g20/stamp9g20.c
> | +++ b/board/taskit/stamp9g20/stamp9g20.c
> | @@ -166,6 +166,7 @@ int board_init(void)
> |
> | /* Enable the serial interface */
> | at91_set_gpio_output(AT91_PIN_PC9, 1);
> | + mdelay(1);
> | at91_seriald_hw_init();
> |
> | stamp9G20_nand_hw_init();
>
> And now the output correctly shows "NAND: ..." as the first message course
> stamp9G20_nand_hw_init() is the first funktion that writes something to the
> serial line after it is enabled.
great!
Did you investigate the PCB? Which device is directly behind the DB9
connector? Can you find a datasheet for that device and check if it has
some power saving features? Can you check if these power saving features
switched with the PC9? Did taskit respond to your request for detailed
information?
>>>
>>> Problem is, I don't have the circuit diagrams and taskit didn't respond
>>> yet ...
>
> OK now I got an responce from taskit. PC9 enables the level converter of the
> RS232 interface. The level converter is a TI MAX3243I. And PC9 is connected
> to ~FORCEOFF. So in order to get the serial line working PC9 has to be high.
Ok, as I thought ...
Another possible reason can be the fact that you enable the output pins
after serial port is enabled (serial_init runs way before board_init).
>>>
>>> This is what I think too! But board_early_init_f() is called befor
>>> serial_init() so this would be the place to put this, but I don't
>>> unterstand why the
>>>
>>> | at91_set_gpio_output(AT91_PIN_PC9, 1);
>>>
>>> command is not working in board_early_init_f() ...
>>
>> This works for me:
>> ---8<---
>> --- a/board/atmel/at91sam9263ek/at91sam9263ek.c
>> +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
>> @@ -254,6 +254,14 @@ int board_early_init_f(void)
>> (1 << ATMEL_ID_PIOCDE),
>> &pmc->pcer);
>>
>> + at91_set_gpio_output(AT91_PIN_PB28, 0);
>> + mdelay(10);
>> + at91_set_gpio_output(AT91_PIN_PB28, 1);
>> + mdelay(10);
>> + at91_set_gpio_output(AT91_PIN_PB28, 0);
>> + mdelay(10);
>> + at91_set_gpio_output(AT91_PIN_PB28, 1);
>> +
>> at91_seriald_hw_init();
>> return 0;
>> }
>> --->8---
>>
>> I can see pin toggling, unfortunately not the correct timing (~38 us
>> instead of 10 ms; have to have a look for that). However the PB28 stays
>> high after leaving board_early_init_f().
>
> But it definitly dosn't work here. I checked with an oscilator, if I toggle
> the pin in board_init() I can nicely see it going high and low but if I
> toggle it in board_early_init_f() *nothing* happens!
Well as mentioned in my mail the mdelay() can not work in
board_eraly_init_f() cause the timers are not setup at this stage. You
need to provide some nop-loop based delay here to have proper delay!
As mentioned before my at91sam9263 (running at about 200 MHz produce 38
us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz
produces here). A simple test could be to move the timer init in
a/a/lib/board.c before board_early_init_f in the init_sequence. Then the
mdelay() will work as expected!
> This seems to be the real problem ... for some reason a can *not* toggle gpio
> pins in board_early_init_f()! I also double checked this with a LED pin. I bet
> there is something I need to enable earlier to get the at91_set_gpio_output()
> command working in board_early_init_f() ...
Have you tried pulling the pin low in board_early_init_f and pull it
high later on in e.g. board_init?
>> Another possibility: Your switching of PC9 in board_early_init_f works
>> correctly but needs some settling. Due to the defective mdelay() in
>> board_early_init_f() you will just see nothing cause it was toggled out
>> after your level shifter was ready. Have you tried pressing
>> after boot in your terminal when you tested the at91_seriald_hw_
Re: [U-Boot] Strange / Unreadable console output
Dear Markus Hubig,
On 14.08.2012 17:11, Markus Hubig wrote:
> On Tue, Aug 14, 2012 at 02:03:55PM +0200, Andreas Bießmann wrote:
>> On 14.08.2012 11:08, Markus Hubig wrote:
>>> On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
On 27.07.12 11:16, Markus Hubig wrote:
>
>
>
> Has anyone an ideea how to fix this? Or what's the cause of it? Is it even
> related to u-boot or is it something at91bootstrap is doing wrong?
can you please check http://patchwork.ozlabs.org/patch/107896/
It seems this patch was set to 'Accepted' but never applied to the
master repository. Unfortunately this got lost in nirvana end of last
year. I will apply it in any case but can you please check if it fixes
your problem?
>>>
>>> Unfortunately not ... but it dosen't do any harm.
>>
>> How sad!
>>
>> I wonder if this has something to do with the ominous PC9. It is
>> possible that this PC9 switches some vital element e.g. power supply,
>> 'output enable' of UART level shifter or something else which needs some
>> settling. Have you tried adding some delay in between setting this pin
>> and activating the serial port output pins?
>
> Hmm no, good idea. I tryed this in board_early_init_f(), but again with no
> console output at all ...
>
> | int board_early_init_f(void)
> | {
> | struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> |
> | /* Enable clocks for all PIOs */
> | writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) |
> | (1 << ATMEL_ID_PIOC), &pmc->pcer);
> |
> | /* Enable the serial interface */
> | at91_set_gpio_output(AT91_PIN_PC9, 1);
> | mdelay(1000);
> | at91_seriald_hw_init();
> |
> | return 0;
> | }
Can you just test the delay in board_init()? I think it should remove
the wired characters.
>> Did you investigate the PCB? Which device is directly behind the DB9
>> connector? Can you find a datasheet for that device and check if it has
>> some power saving features? Can you check if these power saving features
>> switched with the PC9? Did taskit respond to your request for detailed
>> information?
>
> Problem is, I don't have the circuit diagrams and taskit didn't respond
> yet ...
>
>> Another possible reason can be the fact that you enable the output pins
>> after serial port is enabled (serial_init runs way before board_init).
>
> This is what I think too! But board_early_init_f() is called befor
> serial_init() so this would be the place to put this, but I don't
> unterstand why the
>
> | at91_set_gpio_output(AT91_PIN_PC9, 1);
>
> command is not working in board_early_init_f() ...
This works for me:
---8<---
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -254,6 +254,14 @@ int board_early_init_f(void)
(1 << ATMEL_ID_PIOCDE),
&pmc->pcer);
+ at91_set_gpio_output(AT91_PIN_PB28, 0);
+ mdelay(10);
+ at91_set_gpio_output(AT91_PIN_PB28, 1);
+ mdelay(10);
+ at91_set_gpio_output(AT91_PIN_PB28, 0);
+ mdelay(10);
+ at91_set_gpio_output(AT91_PIN_PB28, 1);
+
at91_seriald_hw_init();
return 0;
}
--->8---
I can see pin toggling, unfortunately not the correct timing (~38 us
instead of 10 ms; have to have a look for that). However the PB28 stays
high after leaving board_early_init_f().
Another possibility: Your switching of PC9 in board_early_init_f works
correctly but needs some settling. Due to the defective mdelay() in
board_early_init_f() you will just see nothing cause it was toggled out
after your level shifter was ready. Have you tried pressing
after boot in your terminal when you tested the at91_seriald_hw_init()
in board_early_init_f()?
> I even put this into serial_init() but again with no luck ...
>
>> Therefore your output is put into the TX register but I don't know what
>> happens then. Eventually the output is delayed until the output pins are
>> enabled in conjunction with the 'SYS' clock. Maybe the TX logic is
>> happily shifting the bits into nirvana until you switch on the output
>> pins. In conjunction with the PC9 thing this could be your problem.
>
> I'll wait what taskit says, maybe this will shine some light on this issue.
BTW: have you seen this patch http://patchwork.ozlabs.org/patch/71772/
before?
Best regards
Andreas Bießmann
PS: mdelay relies on __udelay() which needs the timer running, but the
timer is started after board_early_init_f!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
On Tue, Aug 14, 2012 at 02:03:55PM +0200, Andreas Bießmann wrote:
> On 14.08.2012 11:08, Markus Hubig wrote:
> > On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
> >> On 27.07.12 11:16, Markus Hubig wrote:
> >>> Has anyone an ideea how to fix this? Or what's the cause of it? Is it even
> >>> related to u-boot or is it something at91bootstrap is doing wrong?
> >>
> >> can you please check http://patchwork.ozlabs.org/patch/107896/
> >>
> >> It seems this patch was set to 'Accepted' but never applied to the
> >> master repository. Unfortunately this got lost in nirvana end of last
> >> year. I will apply it in any case but can you please check if it fixes
> >> your problem?
> >
> > Unfortunately not ... but it dosen't do any harm.
>
> How sad!
>
> I wonder if this has something to do with the ominous PC9. It is
> possible that this PC9 switches some vital element e.g. power supply,
> 'output enable' of UART level shifter or something else which needs some
> settling. Have you tried adding some delay in between setting this pin
> and activating the serial port output pins?
Hmm no, good idea. I tryed this in board_early_init_f(), but again with no
console output at all ...
| int board_early_init_f(void)
| {
| struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
|
| /* Enable clocks for all PIOs */
| writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) |
| (1 << ATMEL_ID_PIOC), &pmc->pcer);
|
| /* Enable the serial interface */
| at91_set_gpio_output(AT91_PIN_PC9, 1);
| mdelay(1000);
| at91_seriald_hw_init();
|
| return 0;
| }
> Did you investigate the PCB? Which device is directly behind the DB9
> connector? Can you find a datasheet for that device and check if it has
> some power saving features? Can you check if these power saving features
> switched with the PC9? Did taskit respond to your request for detailed
> information?
Problem is, I don't have the circuit diagrams and taskit didn't respond
yet ...
> Another possible reason can be the fact that you enable the output pins
> after serial port is enabled (serial_init runs way before board_init).
This is what I think too! But board_early_init_f() is called befor
serial_init() so this would be the place to put this, but I don't
unterstand why the
| at91_set_gpio_output(AT91_PIN_PC9, 1);
command is not working in board_early_init_f() ...
I even put this into serial_init() but again with no luck ...
> Therefore your output is put into the TX register but I don't know what
> happens then. Eventually the output is delayed until the output pins are
> enabled in conjunction with the 'SYS' clock. Maybe the TX logic is
> happily shifting the bits into nirvana until you switch on the output
> pins. In conjunction with the PC9 thing this could be your problem.
I'll wait what taskit says, maybe this will shine some light on this issue.
Cheers, Markus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
Dear Markus Hubig, On 14.08.2012 11:08, Markus Hubig wrote: > On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote: >> On 27.07.12 11:16, Markus Hubig wrote: >>> one minor Problem I often read about in this list is some crappy / >>> unreadable >>> console output at beginning of the U-Boot start procedure. Now I have the >>> same >>> "visual" Problem. >>> >>> | H�NAND: 128 MiB >>> | *** Warning - bad CRC, using default environment >>> | >>> | In:serial >>> | Out: serial >>> | Err: serial >>> | Net: macb0 >>> | macb0: Starting autonegotiation... >>> | macb0: Autonegotiation timed out (status=0x7849) >>> | macb0: link down (status: 0x7849) >>> | Hit any key to stop autoboot: 0 >>> | ... > > > >>> >>> Has anyone an ideea how to fix this? Or what's the cause of it? Is it even >>> related to u-boot or is it something at91bootstrap is doing wrong? >> >> can you please check http://patchwork.ozlabs.org/patch/107896/ >> >> It seems this patch was set to 'Accepted' but never applied to the >> master repository. Unfortunately this got lost in nirvana end of last >> year. I will apply it in any case but can you please check if it fixes >> your problem? > > Unfortunately not ... but it dosen't do any harm. How sad! I wonder if this has something to do with the ominous PC9. It is possible that this PC9 switches some vital element e.g. power supply, 'output enable' of UART level shifter or something else which needs some settling. Have you tried adding some delay in between setting this pin and activating the serial port output pins? Did you investigate the PCB? Which device is directly behind the DB9 connector? Can you find a datasheet for that device and check if it has some power saving features? Can you check if these power saving features switched with the PC9? Did taskit respond to your request for detailed information? Another possible reason can be the fact that you enable the output pins after serial port is enabled (serial_init runs way before board_init). Therefore your output is put into the TX register but I don't know what happens then. Eventually the output is delayed until the output pins are enabled in conjunction with the 'SYS' clock. Maybe the TX logic is happily shifting the bits into nirvana until you switch on the output pins. In conjunction with the PC9 thing this could be your problem. best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
On Mon, Aug 13, 2012 at 08:12:51PM -0400, Jerry Van Baren wrote: > On 08/13/2012 07:17 AM, Markus Hubig wrote: > > On Sat, Aug 11, 2012 at 08:15:43AM -0400, Jerry Van Baren wrote: > >> On 07/27/2012 05:16 AM, Markus Hubig wrote: > > >> 2) The line before the garbled output becomes readable is "WARNING: > >> Caches not enabled". Does (your) at91bootstrap enable caches? If so, > >> does it disable them before jumping to u-boot? When the output is > >> garbled, does it say "WARNING: Caches not enabled" or is that line > >> missing??? > > > > Hmm the only reverence I found related to caches in the at91bootstrap > > code I use (https://bitbucket.org/imko/at91bootstrap) is in crt0_gnu.S. > > > > There are some lines disabling the cache but only if I enable Thump > > support, which I don't ... but I'll try this. > > Good test, although it likely will change the system timing. The really > worst case is that the problem is still lurking, but changing the boot > timing hides it. :-/ Hmm, enabling the thumb support dosen't change anything. But at leased it didn't do no harm. > >> A classic way for UARTs to be garbled is to inadvertently cache their > >> registers. This shows up on start up because typically caching is "all > >> or nothing" until the MMU is fully configured (MMU configuration is > >> complex). > > > > OK. But is enabling the caches in context of u-boot/bootstrap generally > > a good thing to do? > > Enabling caches is a very good thing to do for speed, especially if you > are copying a flash image to RAM, but you pay a price in complexity. > Enabling code cache is generally safe (the only time you get into > problems is self-modifying code - probably why "thump" support disables > the cache). Enabling data caches is good for memory operations, but > will bite you if you inadvertently cache hardware registers. > > A fairly common technique is to enable data caches during heavy memory > read/write operations (copies, checksum/hash verifications, etc.) and > then disable it. > > >> When your program reads the "TxReady" flag, in this scenario it gets a > >> cached value of the status register that a always says "ready" even > >> though the hardware isn't ready at all. The result is all bytes get > >> immediately crammed into the Tx register, overwriting the previous byte > >> and garbling it. > >> > >> If you get lucky and the UART status register isn't cached (or is cached > >> "not ready" but the Tx routine has a timeout so it writes the byte to > >> the Tx register anyway), the UART works properly and the output isn't > >> garbled. > > > > OK good to know, I'm running a bit out of time at the moment course of > > my thesis, but I'll definitely will have a look at this in detail when > > I'm finished. > > Making sure cache is disabled when exiting the bootstrap loader to > u-boot should be reasonably easy to do (make sure you flush the data > cache before disabling it). That and a few reboots should give you a > good indication if that is indeed your problem. This at91bootstrap thing is no good pice of software. I'm looking foreward to have an U-Boot based SPL ... ;-) Cheers, Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote: > On 27.07.12 11:16, Markus Hubig wrote: > > one minor Problem I often read about in this list is some crappy / > > unreadable > > console output at beginning of the U-Boot start procedure. Now I have the > > same > > "visual" Problem. > > > > | H�NAND: 128 MiB > > | *** Warning - bad CRC, using default environment > > | > > | In:serial > > | Out: serial > > | Err: serial > > | Net: macb0 > > | macb0: Starting autonegotiation... > > | macb0: Autonegotiation timed out (status=0x7849) > > | macb0: link down (status: 0x7849) > > | Hit any key to stop autoboot: 0 > > | ... > > > > Has anyone an ideea how to fix this? Or what's the cause of it? Is it even > > related to u-boot or is it something at91bootstrap is doing wrong? > > can you please check http://patchwork.ozlabs.org/patch/107896/ > > It seems this patch was set to 'Accepted' but never applied to the > master repository. Unfortunately this got lost in nirvana end of last > year. I will apply it in any case but can you please check if it fixes > your problem? Unfortunately not ... but it dosen't do any harm. Cheers, Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
Dear Markus Hubig, On 27.07.12 11:16, Markus Hubig wrote: > Hi @all, > > one minor Problem I often read about in this list is some crappy / unreadable > console output at beginning of the U-Boot start procedure. Now I have the same > "visual" Problem. > > | H�NAND: 128 MiB > | *** Warning - bad CRC, using default environment > | > | In:serial > | Out: serial > | Err: serial > | Net: macb0 > | macb0: Starting autonegotiation... > | macb0: Autonegotiation timed out (status=0x7849) > | macb0: link down (status: 0x7849) > | Hit any key to stop autoboot: 0 > | ... > > Sometimes I get a good readable output, which looks like so: > > | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 23 2012 - 14:44:29) > | > | U-Boot code: 23F0 -> 23F30464 BSS: -> 23F72128 > | CPU: AT91SAM9G20 > | Crystal frequency: 18.432 MHz > | CPU clock: 396.288 MHz > | Master clock : 132.096 MHz > | RAM Configuration: > | Bank #0: 2000 64 MiB > | WARNING: Caches not enabled > | NAND: 128 MiB > | ... > > Has anyone an ideea how to fix this? Or what's the cause of it? Is it even > related to u-boot or is it something at91bootstrap is doing wrong? can you please check http://patchwork.ozlabs.org/patch/107896/ It seems this patch was set to 'Accepted' but never applied to the master repository. Unfortunately this got lost in nirvana end of last year. I will apply it in any case but can you please check if it fixes your problem? Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
On 08/13/2012 07:17 AM, Markus Hubig wrote: > On Sat, Aug 11, 2012 at 08:15:43AM -0400, Jerry Van Baren wrote: >> On 07/27/2012 05:16 AM, Markus Hubig wrote: >>> one minor Problem I often read about in this list is some crappy / >>> unreadable >>> console output at beginning of the U-Boot start procedure. Now I have the >>> same >>> "visual" Problem. >>> >>> | H�NAND: 128 MiB >>> | *** Warning - bad CRC, using default environment >>> | >>> | In:serial >>> | Out: serial >>> | Err: serial >>> | Net: macb0 >>> | macb0: Starting autonegotiation... >>> | macb0: Autonegotiation timed out (status=0x7849) >>> | macb0: link down (status: 0x7849) >>> | Hit any key to stop autoboot: 0 >>> | ... >>> >>> Sometimes I get a good readable output, which looks like so: >>> >>> | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 23 2012 - 14:44:29) >>> | >>> | U-Boot code: 23F0 -> 23F30464 BSS: -> 23F72128 >>> | CPU: AT91SAM9G20 >>> | Crystal frequency: 18.432 MHz >>> | CPU clock: 396.288 MHz >>> | Master clock : 132.096 MHz >>> | RAM Configuration: >>> | Bank #0: 2000 64 MiB >>> | WARNING: Caches not enabled >>> | NAND: 128 MiB >>> | ... [snip] >> 2) The line before the garbled output becomes readable is "WARNING: >> Caches not enabled". Does (your) at91bootstrap enable caches? If so, >> does it disable them before jumping to u-boot? When the output is >> garbled, does it say "WARNING: Caches not enabled" or is that line >> missing??? > > Hmm the only reverence I found related to caches in the at91bootstrap > code I use (https://bitbucket.org/imko/at91bootstrap) is in crt0_gnu.S. > > There are some lines disabling the cache but only if I enable Thump > support, which I don't ... but I'll try this. Good test, although it likely will change the system timing. The really worst case is that the problem is still lurking, but changing the boot timing hides it. :-/ >> A classic way for UARTs to be garbled is to inadvertently cache their >> registers. This shows up on start up because typically caching is "all >> or nothing" until the MMU is fully configured (MMU configuration is >> complex). > > OK. But is enabling the caches in context of u-boot/bootstrap generally > a good thing to do? Enabling caches is a very good thing to do for speed, especially if you are copying a flash image to RAM, but you pay a price in complexity. Enabling code cache is generally safe (the only time you get into problems is self-modifying code - probably why "thump" support disables the cache). Enabling data caches is good for memory operations, but will bite you if you inadvertently cache hardware registers. A fairly common technique is to enable data caches during heavy memory read/write operations (copies, checksum/hash verifications, etc.) and then disable it. >> When your program reads the "TxReady" flag, in this scenario it gets a >> cached value of the status register that a always says "ready" even >> though the hardware isn't ready at all. The result is all bytes get >> immediately crammed into the Tx register, overwriting the previous byte >> and garbling it. >> >> If you get lucky and the UART status register isn't cached (or is cached >> "not ready" but the Tx routine has a timeout so it writes the byte to >> the Tx register anyway), the UART works properly and the output isn't >> garbled. > > OK good to know, I'm running a bit out of time at the moment course of > my thesis, but I'll definitely will have a look at this in detail when > I'm finished. Making sure cache is disabled when exiting the bootstrap loader to u-boot should be reasonably easy to do (make sure you flush the data cache before disabling it). That and a few reboots should give you a good indication if that is indeed your problem. > Cheers, Markus Good luck on the thesis, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
On Sat, Aug 11, 2012 at 08:15:43AM -0400, Jerry Van Baren wrote: > On 07/27/2012 05:16 AM, Markus Hubig wrote: > > one minor Problem I often read about in this list is some crappy / > > unreadable > > console output at beginning of the U-Boot start procedure. Now I have the > > same > > "visual" Problem. > > > > | H�NAND: 128 MiB > > | *** Warning - bad CRC, using default environment > > | > > | In:serial > > | Out: serial > > | Err: serial > > | Net: macb0 > > | macb0: Starting autonegotiation... > > | macb0: Autonegotiation timed out (status=0x7849) > > | macb0: link down (status: 0x7849) > > | Hit any key to stop autoboot: 0 > > | ... > > > > Sometimes I get a good readable output, which looks like so: > > > > | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 23 2012 - 14:44:29) > > | > > | U-Boot code: 23F0 -> 23F30464 BSS: -> 23F72128 > > | CPU: AT91SAM9G20 > > | Crystal frequency: 18.432 MHz > > | CPU clock: 396.288 MHz > > | Master clock : 132.096 MHz > > | RAM Configuration: > > | Bank #0: 2000 64 MiB > > | WARNING: Caches not enabled > > | NAND: 128 MiB > > | ... > > > > Has anyone an idea how to fix this? > > No. :-) Damn! :-) > > Or what's the cause of it? > > The UART is being mishandled, either directly or indirectly, e.g. due to > caching issues or maybe the UART block isn't configured properly. > > > Is it even related to u-boot or is it something at91bootstrap is > > doing wrong? > > Yes. :-) > > Questions / observations: > 1) When the output is garbled, is it always associated with the line > "*** Warning - bad CRC, using default environment" and not garbled if > the environment is OK? That would indicate it is a configuration issue > with the default environment. It could also indicate a caching problem > (see next), where your environment is obscured by an enabled cache. No. I get the CRC Warning only after I completly delete the NAND. After a 'saveenv' this warning is gone but my output is garbled. > 2) The line before the garbled output becomes readable is "WARNING: > Caches not enabled". Does (your) at91bootstrap enable caches? If so, > does it disable them before jumping to u-boot? When the output is > garbled, does it say "WARNING: Caches not enabled" or is that line > missing??? Hmm the only reverence I found related to caches in the at91bootstrap code I use (https://bitbucket.org/imko/at91bootstrap) is in crt0_gnu.S. There are some lines disabling the cache but only if I enable Thump support, which I don't ... but I'll try this. > A classic way for UARTs to be garbled is to inadvertently cache their > registers. This shows up on start up because typically caching is "all > or nothing" until the MMU is fully configured (MMU configuration is > complex). OK. But is enabling the caches in context of u-boot/bootstrap generally a good thing to do? > When your program reads the "TxReady" flag, in this scenario it gets a > cached value of the status register that a always says "ready" even > though the hardware isn't ready at all. The result is all bytes get > immediately crammed into the Tx register, overwriting the previous byte > and garbling it. > > If you get lucky and the UART status register isn't cached (or is cached > "not ready" but the Tx routine has a timeout so it writes the byte to > the Tx register anyway), the UART works properly and the output isn't > garbled. OK good to know, I'm running a bit out of time at the moment course of my thesis, but I'll definitely will have a look at this in detail when I'm finished. Cheers, Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange / Unreadable console output
Hi Markus, On 07/27/2012 05:16 AM, Markus Hubig wrote: > Hi @all, > > one minor Problem I often read about in this list is some crappy / unreadable > console output at beginning of the U-Boot start procedure. Now I have the same > "visual" Problem. > > | H�NAND: 128 MiB > | *** Warning - bad CRC, using default environment > | > | In:serial > | Out: serial > | Err: serial > | Net: macb0 > | macb0: Starting autonegotiation... > | macb0: Autonegotiation timed out (status=0x7849) > | macb0: link down (status: 0x7849) > | Hit any key to stop autoboot: 0 > | ... > > Sometimes I get a good readable output, which looks like so: > > | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 23 2012 - 14:44:29) > | > | U-Boot code: 23F0 -> 23F30464 BSS: -> 23F72128 > | CPU: AT91SAM9G20 > | Crystal frequency: 18.432 MHz > | CPU clock: 396.288 MHz > | Master clock : 132.096 MHz > | RAM Configuration: > | Bank #0: 2000 64 MiB > | WARNING: Caches not enabled > | NAND: 128 MiB > | ... > > Has anyone an idea how to fix this? No. :-) > Or what's the cause of it? The UART is being mishandled, either directly or indirectly, e.g. due to caching issues or maybe the UART block isn't configured properly. > Is it even related to u-boot or is it something at91bootstrap is > doing wrong? Yes. :-) Questions / observations: 1) When the output is garbled, is it always associated with the line "*** Warning - bad CRC, using default environment" and not garbled if the environment is OK? That would indicate it is a configuration issue with the default environment. It could also indicate a caching problem (see next), where your environment is obscured by an enabled cache. 2) The line before the garbled output becomes readable is "WARNING: Caches not enabled". Does (your) at91bootstrap enable caches? If so, does it disable them before jumping to u-boot? When the output is garbled, does it say "WARNING: Caches not enabled" or is that line missing??? A classic way for UARTs to be garbled is to inadvertently cache their registers. This shows up on start up because typically caching is "all or nothing" until the MMU is fully configured (MMU configuration is complex). When your program reads the "TxReady" flag, in this scenario it gets a cached value of the status register that a always says "ready" even though the hardware isn't ready at all. The result is all bytes get immediately crammed into the Tx register, overwriting the previous byte and garbling it. If you get lucky and the UART status register isn't cached (or is cached "not ready" but the Tx routine has a timeout so it writes the byte to the Tx register anyway), the UART works properly and the output isn't garbled. > Cheers, Markus Good luck, and let us know what you learn, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
