[P2020]Problem of linking failed in P2020 36Bit setting based on SDKv1.3

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

[P2020]Problem of linking failed in P2020 36Bit setting based on SDKv1.3

Jump to solution
2,680 Views
wedchen
Contributor II

Hello all,

    we have a stable P2020 u-boot environment based on FreeScale SDK v1.3.

In 32-bit mode, we could compile and make bootloader bin file successfully.

Now, for requirement of support 4G DDR and that means we need to support 36-bit physical address access.

After refer to P2020RDB_PC settings, we have following modifications:

1. Modify P2020.config to support 36BIT access, and we make sure 'CONFIG_36BIT' is set correctlly.

2. Modify p2020.h

#define CONFIG_SYS_TEXT_BASE 0xe3f40000

#define CONFIG_RESET_VECTOR_ADDRESS 0xe3ffffff

#define CONFIG_SYS_CCSRBAR 0xffe00000

#define CONFIG_SYS_FLASH_BASE 0xfe0000000ull

#define CONFIG_SYS_PCIE1_MEM_VIRT 0xf90000000ull

#define CONFIG_SYS_PCIE1_IO_VIRT 0xfffc30000ull

#define CONFIG_SYS_CPLD_BASE 0xfea000000ull

#define CONFIG_SYS_NAND_BASE 0xffff00000ull

However, we met below link error messages :

/home/ithinkchen/SWITCH/Urus2_4G/output/host/usr/powerpc-buildroot-linux-gnu/sysroot/usr/lib/powerpc-fsl-linux-gnuspe/4.6.2 -lgcc -Map u-boot.map -o u-boot

/home/ithinkchen/SWITCH/Urus2_4G/output/host/usr/bin/powerpc-fsl-linux-gnuspe-ld:u-boot.lds:1: ignoring invalid character `#' in expression

/home/ithinkchen/SWITCH/Urus2_4G/output/host/usr/bin/powerpc-fsl-linux-gnuspe-ld:u-boot.lds:1: syntax error

Can any one give use some clues about this link error?

We didn't touch/modify the file u-boot.lds in arch/powerpc/cpu/mpc85xx/.

============================================================================

#include "config.h" /* CONFIG_BOARDDIR */

#ifdef CONFIG_RESET_VECTOR_ADDRESS

#define RESET_VECTOR_ADDRESS CONFIG_RESET_VECTOR_ADDRESS

#else

#define RESET_VECTOR_ADDRESS 0xfffffffc

#endif

OUTPUT_ARCH(powerpc)

PHDRS

{

  text PT_LOAD;

  bss PT_LOAD;

}

SECTIONS

{

  /* Read-only sections, merged into text segment: */

  . = + SIZEOF_HEADERS;

  .interp : { *(.interp) }

  .text      :

  {

    *(.text*)

   } :text

    _etext = .;

    PROVIDE (etext = .);

    .rodata    :

   {

    *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))

  } :text

  /* Read-write section, merged into data segment: */

  . = (. + 0x00FF) & 0xFFFFFF00;

  _erotext = .;

  PROVIDE (erotext = .);

  .reloc   :

  {

    _GOT2_TABLE_ = .;

    KEEP(*(.got2))

    KEEP(*(.got))

    PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);

    _FIXUP_TABLE_ = .;

    KEEP(*(.fixup))

  }

  __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;

  __fixup_entries = (. - _FIXUP_TABLE_) >> 2;

  .data    :

  {

    *(.data*)

    *(.sdata*)

  }

  _edata  =  .;

  PROVIDE (edata = .);

  . = .;

  __u_boot_cmd_start = .;

  .u_boot_cmd : { *(.u_boot_cmd) }

  __u_boot_cmd_end = .;

  . = .;

  __start___ex_table = .;

  __ex_table : { *(__ex_table) }

  __stop___ex_table = .;

  . = ALIGN(256);

  __init_begin = .;

  .text.init : { *(.text.init) }

  .data.init : { *(.data.init) }

  . = ALIGN(256);

  __init_end = .;

  .bootpg RESET_VECTOR_ADDRESS - 0xffc :

  {

    arch/powerpc/cpu/mpc85xx/start.o (.bootpg)

  } :text = 0xffff

  .resetvec RESET_VECTOR_ADDRESS :

  {

    KEEP(*(.resetvec))

  } :text = 0xffff

  . = RESET_VECTOR_ADDRESS + 0x4;

  /*

   * Make sure that the bss segment isn't linked at 0x0, otherwise its

   * address won't be updated during relocation fixups.  Note that

   * this is a temporary fix.  Code to dynamically the fixup the bss

   * location will be added in the future.  When the bss relocation

   * fixup code is present this workaround should be removed.

   */

#if (RESET_VECTOR_ADDRESS == 0xfffffffc)

  . |= 0x10;

#endif

  __bss_start = .;

  .bss (NOLOAD)       :

  {

   *(.sbss*)

   *(.bss*)

   *(COMMON)

  } :bss

  . = ALIGN(4);

  __bss_end__ = . ;

  PROVIDE (end = .);

}

With best regards,

Wed.

Labels (1)
1 Solution
1,463 Views
scottwood
NXP Employee
NXP Employee

If you remove config.h, then how are symbols like CONFIG_RESET_VECTOR_ADDRESS going to be set?  You should find the root cause of the problem.  This does not happen when building an unmodified U-Boot.

As for the rest, please use the existing boards (such as p1_p2_rdb_pc) that support 36-bit as a reference.

CONFIG_SYS_TEXT_BASE and CONFIG_RESET_VECTOR_ADDRESS are both effective addresses and cannot be 36-bit.  What "some references" are you referring to?

View solution in original post

7 Replies
1,463 Views
scottwood
NXP Employee
NXP Employee

Enabling CONFIG_36BIT is all you should need, if your config file works like p1_p2_rdb_pc.h.  Note that many of the address you showed as being changed are effective addresses, not physical -- and thus must still be 32-bit.

As for your linker error, it seems something is preventing the preprocessor from running on it.  Did the linker script source somehow get copied directly to u-boot.lds in the toplevel output directory?  Or perhaps there were changes to the makefile that are affecting this?

1,464 Views
wedchen
Contributor II

Dear Scott,

    thanks for your kindly reply, and this issue is fixed by remove the first line #include "config.h" in file u-boot.lds.

It might be something wrong about our preprocessor.

Anyway, about the effective address part you mentioned.

#define CONFIG_SYS_TEXT_BASE 0xe3f40000

#define CONFIG_RESET_VECTOR_ADDRESS 0xe3ffffff

#define CONFIG_SYS_CCSRBAR 0xffe00000

#define CONFIG_SYS_FLASH_BASE 0xfe0000000ull

#define CONFIG_SYS_PCIE1_MEM_VIRT 0xf90000000ull

#define CONFIG_SYS_PCIE1_IO_VIRT 0xfffc30000ull

#define CONFIG_SYS_CPLD_BASE 0xfea000000ull

#define CONFIG_SYS_NAND_BASE 0xffff00000ull

Would you please kindly indicate which settings should keep 32-bits?

Now I am not sure if CONFIG_SYS_TEXT_BASE/ CONFIG_RESET_VECTOR_ADDRESS should keep 32-bits due to there are some references revise these two setting into 36-bits physical addressing.

0 Kudos
Reply
1,464 Views
scottwood
NXP Employee
NXP Employee

If you remove config.h, then how are symbols like CONFIG_RESET_VECTOR_ADDRESS going to be set?  You should find the root cause of the problem.  This does not happen when building an unmodified U-Boot.

As for the rest, please use the existing boards (such as p1_p2_rdb_pc) that support 36-bit as a reference.

CONFIG_SYS_TEXT_BASE and CONFIG_RESET_VECTOR_ADDRESS are both effective addresses and cannot be 36-bit.  What "some references" are you referring to?

1,464 Views
wedchen
Contributor II

Dear Scott,

     thanks for your responses, and I am still finding the root cause in my buildroot environment now.

For the 36-bit physical addressing, I've modified again based on p1_p2_rdb_pc.

Now I understand what you means ... :smileysilly:

Anyway, below link was what I refer to before, and it is not correct.

Uboot problem on uncustom P2020RDB-PC board

With best regards,

Wed.

0 Kudos
Reply
1,464 Views
敏赵
Contributor I

Dear Wed,

Could you tell me how you config your DDR? Do you config DDR by SPD or using p1_p2_rdb_pc.h?

We designed a target board using p2020 CPU referring to the design of P2020RDB-PC. And we change the DDR to 4GB.

But our uboot print messages shows we have 2GB left unmapped and the print messages hangs at DDR.

I'm looking forward to your reply.

Best regards,

Min Zhao

0 Kudos
Reply
1,464 Views
wedchen
Contributor II

Dear Zhao,


    from your message, first, you should need to confirm that your config support 36 BIT physical address access, and'CONFIG_36BIT' is set correctlly.

If you did, and the message "2G memory left unmapped" means your TLB settings about DDR is not correct.


We configured DDR by SPD, and the only change p1_p2_rdb_pc.h with below parts:

the CONFIG_SYS_DDR_TLB_START / CONFIG_NUM_DDR_CONTROLLERS/ CONFIG_DIMM_SLOTS_PER_CTLR/ CONFIG_CHIP_SELECTS_PER_CTRL/ ... etc


should be your check point.


/* DDR Setup */

#define CONFIG_FSL_DDR3

#undef CONFIG_FSL_DDR_INTERACTIVE

#define CONFIG_SPD_EEPROM /* Use SPD EEPROM for DDR setup */

#define SPD_EEPROM_ADDRESS1    (0xA2>>1)

#define CONFIG_DDR_SPD

#define CONFIG_SYS_SPD_BUS_NUM 0 /* SPD EEPROM located on I2C bus 0 */

#undef CONFIG_DDR_DLL

#define CONFIG_DDR_ECC /* only for ECC DDR module */

#define CONFIG_DDR_ECC_CMD

#define CONFIG_ECC_INIT_VIA_DDRCONTROLLER

#define CONFIG_MEM_INIT_VALUE 0x0

#define CONFIG_DDR_800MHZ

#define CONFIG_SYS_ECC_EN 0x20000000

#define CONFIG_SYS_SDRAM_SIZE 2048 /* DDR size on P1_P2 RDBs */

#define CONFIG_SYS_DDR_SDRAM_BASE 0x00000000

#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE

#define CONFIG_NUM_DDR_CONTROLLERS 1

#define CONFIG_DIMM_SLOTS_PER_CTLR 1

/* Use two chip selector CS0 / CS1 for rank select */

#define CONFIG_CHIP_SELECTS_PER_CTRL 2

#define CONFIG_SYS_DDR_ERR_INT_EN 0x0000000d

#define CONFIG_SYS_DDR_ERR_DIS 0x00000000

#define CONFIG_SYS_DDR_SBE 0x00FF0000

#define CONFIG_SYS_DDR_TLB_START 10

#define CONFIG_SYS_DDR_CDR1 0x000C0000

#define CONFIG_SYS_DDR_CDR2 0x00000000

0 Kudos
Reply
1,464 Views
敏赵
Contributor I

Dear Wed,


What's the version of your uboot? I found the code of DDR setting is different from mine(my uboot is 2013.10 ).

The codes of DDR Setup in p1_p2_rdb_pc of my uboot as following:

*****************************************************************************************

/* DDR Setup */

#define CONFIG_FSL_DDR3

#define CONFIG_SYS_DDR_RAW_TIMING

#define CONFIG_DDR_SPD

#define CONFIG_SYS_SPD_BUS_NUM 1

#define SPD_EEPROM_ADDRESS 0x52

#undef CONFIG_FSL_DDR_INTERACTIVE

#define CONFIG_SYS_SDRAM_SIZE_LAW LAW_SIZE_4G

#define CONFIG_CHIP_SELECTS_PER_CTRL 2

#define CONFIG_SYS_SDRAM_SIZE (1u << (CONFIG_SYS_SDRAM_SIZE_LAW - 19))

#define CONFIG_SYS_DDR_SDRAM_BASE 0x00000000

#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE

#define CONFIG_NUM_DDR_CONTROLLERS 1

#define CONFIG_DIMM_SLOTS_PER_CTLR 1

*********************************************************************************************

I tried to modify the codes like yours, but it still print 2G left unmapped.

I make the uboot by the order: make P2020RDB-PC_36BIT_config. Then make it.

Did you modify the tlb.c and ddr.c?


Thank you very much.

Best regards,

Min Zhao



0 Kudos
Reply