[#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