Skip to contentSkip to conversation

P2020rdb :- process hangs while invalidate_tlb's

U-Boot diyaa 2 participants 3 messages Oct 18, 2012 – Nov 15, 2012

lore
Share & tools
lore

diyaa

author
#0 lore raw

Hi

I am working on a custom board (VPX Based P2020 board) and trying to port u-boot-2011.09 (supports P2020 RDB) in it . Our board is similar to P2020RDB board and the technical specification is shown below ,

->Processor

Freescale QorIQ P2020 processor
Dual PowerPC e500v2 cores at up to 1.2 GHz
512 kB of shared L2 cache

->Memory

    1 GB of DDR3-600 SDRAM
    128 MB of NOR flash (16-bit)

Through Codewarroier Emulator Tool, We checked the DDR,FLASH,Uart console and its working fine without any issue.

when we ported u-boot (u-boot-2011.09) at boot rom location 0xFFF80000, it fails at invalidate_tlbs in cpu_init_early_f and cannot proceed to get serial console .we probed the flash CS while poweron boot , processor is keeping bunch of CS( confirms processor able to access flash)

Why its getting held up while invalidating tlb's

Can you help us to solve the issue

Signature · 2 lines
View this message in context: http://old.nabble.com/P2020rdb-%3A--process-hangs-while-invalidate_tlb%27s-tp34572303p34572303.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
#1 lore raw
Quoted 8 lines · diyaa

Hi

I am working on a custom board (VPX Based P2020 board) and trying to port
u-boot-2011.09 (supports P2020 RDB) in it . Our board is similar to P2020RDB
board and the technical specification is shown below ,

You should always try with the latest version when asking for help (even if you will eventually need to use an older version for some other (usually not very good) reason).

Quoted 24 lines

->Processor

Freescale QorIQ P2020 processor
Dual PowerPC e500v2 cores at up to 1.2 GHz
512 kB of shared L2 cache

->Memory

    1 GB of DDR3-600 SDRAM
    128 MB of NOR flash (16-bit)

Through Codewarroier Emulator Tool, We checked the DDR,FLASH,Uart console
and its working fine without any issue.

when we ported u-boot (u-boot-2011.09) at boot rom location 0xFFF80000, it
fails at invalidate_tlbs in cpu_init_early_f and cannot proceed to get
serial console .we probed the flash CS while poweron boot , processor is
keeping bunch of CS( confirms processor able to access flash)

Quoted 1 line

Why its getting held up while invalidating tlb's

Are you sure that's where it's failing? It could be that you just can't single step through that boot phase. There were recently applied patches to shrink the "undebuggable" window somewhat.

If that's not it, probably there's no IPROT TLB entry covering the address you're running out of, or covering the initial RAM area. Have you tried dumping the TLB?

-Scott

#2 lore raw

Hi Scott,

Thanks for ur reply,

Problem got solved after increasing the TLB entry size of flash to 256MB.

Now u-boot booted properly and able to get the prompt.

Quoted 49 lines · Scott Wood
Quoted 8 lines · diyaa

Hi

I am working on a custom board (VPX Based P2020 board) and trying to port u-boot-2011.09 (supports P2020 RDB) in it . Our board is similar to P2020RDB
board and the technical specification is shown below ,

You should always try with the latest version when asking for help (even if you will eventually need to use an older version for some other (usually not very good) reason).

->Processor

Quoted 13 lines

Freescale QorIQ P2020 processor
Dual PowerPC e500v2 cores at up to 1.2 GHz
512 kB of shared L2 cache

->Memory

    1 GB of DDR3-600 SDRAM
    128 MB of NOR flash (16-bit)

Through Codewarroier Emulator Tool, We checked the DDR,FLASH,Uart console and its working fine without any issue.

Quoted 8 lines

when we ported u-boot (u-boot-2011.09) at boot rom location 0xFFF80000, it fails at invalidate_tlbs in cpu_init_early_f and cannot proceed to get serial console .we probed the flash CS while poweron boot , processor is keeping bunch of CS( confirms processor able to access flash)

Why its getting held up while invalidating tlb's

Are you sure that's where it's failing? It could be that you just can't single step through that boot phase. There were recently applied patches to shrink the "undebuggable" window somewhat.

If that's not it, probably there's no IPROT TLB entry covering the address you're running out of, or covering the initial RAM area. Have you tried dumping the TLB?

-Scott