[#5477] can not enter u-boot in bf518f-ezbrd after reboot from trunk kernel

Document created by Aaronwu Employee on Sep 4, 2013
Version 1Show Document
  • View in full screen mode

[#5477] can not enter u-boot in bf518f-ezbrd after reboot from trunk kernel

Submitted By: Vivi Li

Open Date

2009-09-02 00:19:26    

Priority:

Medium     Assignee:

Nobody

Status:

Open     Fixed In Release:

N/A

Found In Release:

2010R1     Release:

Category:

N/A     Board:

N/A

Processor:

BF518     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

N/A

Uboot version or rev.:

    Toolchain version or rev.:

gcc4.1-09r1-rc9

App binary format:

N/A     

Summary: can not enter u-boot in bf518f-ezbrd after reboot from trunk kernel

Details:

 

Can not enter u-boot in bf518f-ezbrd after reboot from trunk kernel. There is no response when enter input in u-boot.

It works fine with 09r1 kernel image.

 

--

root:/> reboot

Restarting system.

 

 

U-Boot 2009.06-svn2013 (ADI-2009R2-pre) (Aug 29 2009 - 22:42:08)

 

CPU:   ADSP bf518-0.0 (Detected Rev: 0.0) (parallel flash boot)

Board: ADI BF518F EZ-Board board

       Support: http://blackfin.uclinux.org/

Clock: VCO: 400 MHz, Core: 400 MHz, System: 80 MHz

RAM:   64 MB

Flash:  4 MB

In:    serial

Out:   serial

Err:   serial

Net:   Blackfin EMAC

MAC:   00:e0:fe:3d:1a:05

Hit any key to stop autoboot:  3

(no response after press any key)

--

 

Follow-ups

 

--- Barry Song                                               2009-09-29 23:29:17

Same with bug [#5476]. If we force to fulfill the workaround in bfin_reset,

reboot will work.

        /* The bootrom checks to see how it was reset and will

         * automatically perform a software reset for us when

         * it starts executing after the core reset.

         */

     /*  if (ANOMALY_05000353 || ANOMALY_05000386) */{

                /* Initiate System software reset. */

                bfin_write_SWRST(0x7);

 

                /* Due to the way reset is handled in the hardware, we need

                 * to delay for 10 SCLKS.  The only reliable way to do this is

                 * to calculate the CCLK/SCLK ratio and multiply 10.  For now,

                 * we'll assume worse case which is a 1:15 ratio.

                 */

                asm(

                        "LSETUP (1f, 1f) LC0 = %0\n"

                        "1: nop;"

                        :  

                        : "a" (15 * 10)

                        : "LC0", "LB0", "LT0"

                ); 

 

Does it make sense for us to fulfill bootrom software reset always for any

platform?

 

 

--- Barry Song                                               2009-11-09 00:34:30

Then force to execute this workaround since some chips can't reset normally even

though their anomaly lists don't include ANOMALY_05000353 and ANOMALY_05000386.

 

--- Robin Getz                                               2009-11-09 08:41:29

We do not enable anomaly workarounds on parts which don't have the anomaly.

 

If you believe the part does have the anomaly - you need to determine which one

(353 or 386), and then we can have a discussion with design/apps.

 

-Robin

 

--- Sonic Zhang                                              2010-06-30 23:48:45

This must be anomaly 353 according to the description. It looks some SYS MMRs

are not reset properly in bootrom.

 

--- Robin Getz                                               2010-07-01 13:10:21

The Bootrom is not responsible for resetting system MMRs.

 

System MMRs should be reset via the reset assertion.

 

Do we know which MMRs aren't reset? (This will help design) - and it's only on

518? (which version?)

 

Thanks

-Robin

 

--- Sonic Zhang                                              2010-07-02 00:02:45

The description of anomaly 353 says "The bfrom_SysControl() ROM function

does not reset all System MMRs properly and must not be used to perform system

reset of the processor. Bfrom_SysControl(SYSCTRL_SYSRESET) should not be

used."

 

But, this anomaly is not said to cover bf518.

 

Looks like the UART RBR and IIR MMRs are not working properly.

 

--- Mike Frysinger                                           2010-07-02 00:59:58

failure to fully reset the System MMR space is a very different issue from a

random hang (which is what happens with the BF526).  can we double check to see

if this is the issue ?  and figure out which MMR is screwing things up so we can

reduce the problem to u-boot (and thus not involve linux at all) ?

 

--- Barry Song                                               2010-07-08 03:52:56

Can't be repeated in the trunk head now even after i delete the anomoly

workaround.

root:/> reboot

Restarting system.

 

 

U-Boot 2010.06-svn2355 (ADI-2010R1-pre) (Jul 08 2010 - 15:43:31)

 

CPU:   ADSP bf518-0.0 (Detected Rev: 0.0) (parallel flash boot)

Board: ADI BF518F EZ-Board board

       Support: http://blackfin.uclinux.org/

Clock: VCO: 400 MHz, Core: 400 MHz, System: 80 MHz

RAM:   64 MiB

Flash: 4 MiB

MMC:  Blackfin SDH: 0

In:    serial

Out:   serial

Err:   serial

KGDB:  [on serial] ready

Net:   bfin_mac

Hit any key to stop autoboot:  0

Using bfin_mac device

TFTP from server 10.99.29.104; our IP address is 10.99.29.113

Filename 'uImage'.

Load address: 0x1000000

Loading: #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         ################

done

Bytes transferred = 3738743 (390c77 hex)

## Booting kernel from Legacy Image at 01000000 ...

   Image Name:   bf518-2.6.34-ADI-2010R1-pre-svn8

 

...

 

-barry

 

--- Vivi Li                                                  2010-07-22 02:45:36

My kernel config is attached for your reference. With this config, kernel can

not reboot.

 

I also tried your attached image, it can reboot in kernel, but I can not enter

u-boot after reboot. U-boot is updated to 2010.06-svn2356.

 

--- Barry Song                                               2010-07-22 06:35:37

It is sure some hardware status are not restored to normal by raise 1.

For example, at least we have been sure uart is not normal and can be restored

by set ier to 0 manually in uboot. Setting ier to 0 can fix serial hang issue

while rebooting.

We have no much time to figure out all hardware status and it seems random, for

example my image is ok, but vivi's image is not. So, force to run soft reset.

-barry

 

--- Robin Getz                                               2010-07-22 16:14:53

Barry:

 

>It is sure some hardware status are not restored to normal by raise 1.

 

I'm sure you are correct - but this is a hardware bug, that must be verified by

the hardware design/applications team.

 

Please send an email to processor.support, and copy the uclinux-dist-devel

mailing list.

 

Thanks

 

--- Vivi Li                                                  2010-09-20 03:45:41

I can see this bug happens on board 1.1, silicon 0.2.

No such problem on board 0.2, silicon 0.0.

 

--- Vivi Li                                                  2010-09-20 05:24:09

Ignore my previous comment.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

uImage    application/octet-stream    3738743    Barry Song

config.policy    application/octet-stream    34448    Vivi Li

 

 

 

Save changes Back

Attachments

Outcomes