[U-Boot] u-boot for Galileo board

[U-Boot] u-boot for Galileo board

[Liu, Changcheng]

Hi all,

    I have some questions about the u-boot for Galileo2 board.



    1. Code: https://github.com/LeMaker/u-boot (it's for Galileo board which could be ported for Galileo2 board)



    2. Confusing at the building process.

           a. objcopy  --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot u-boot.bin

               Question: Why the ".resetvec" section should be removed since it's placed at "0xffffffff0" section according to arch/x86/cpu/u-boot.lds?



           b. cat u-boot.bin dts/dt.dtb > u-boot-dtb.bin

               Question:

               I think ROM is layout at the top of the physical address and quark x1000 SoC will fetch instruction from  FFFF_FFF0H after being power on. If dts/dt.dtb is appended after u-boot.bin, how could the content is effective at FFFF_FFF0H?


B.R.
Changcheng

[U-Boot] u-boot for Galileo board

[Liu, Changcheng]

Hi all,

    I have some questions about the u-boot for Galileo2 board.



    1. Code: https://github.com/LeMaker/u-boot (it's for Galileo board which could be ported for Galileo2 board)



    2. Confusing at the building process.

           a. objcopy  --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot u-boot.bin

               Question: Why the ".resetvec" section should be removed since it's placed at "0xffffffff0" section according to arch/x86/cpu/u-boot.lds?



           b. cat u-boot.bin dts/dt.dtb > u-boot-dtb.bin

               Question:

               I think ROM is layout at the top of the physical address and quark x1000 SoC will fetch instruction from  FFFF_FFF0H after being power on. If dts/dt.dtb is appended after u-boot.bin, how could the content is effective at FFFF_FFF0H?


B.R.
Changcheng

[U-Boot] u-boot for Galileo board

[Bin Meng]

Hi Changcheng,

On Thu, Jun 16, 2016 at 7:22 PM, Liu, Changcheng
<changcheng.liu@intel.com> wrote:
> Hi all,
>
>     I have some questions about the u-boot for Galileo2 board.
>
>
>
>     1. Code: https://github.com/LeMaker/u-boot (it's for Galileo board which could be ported for Galileo2 board)
>
>

What's Galileo2 board? If you are talking about Galileo gen2 board,
this is already supported by current U-Boot. In fact, both Galileo
gen1 and gen2 boards are supported in U-Boot with the same code base.

>
>     2. Confusing at the building process.
>
>            a. objcopy  --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot u-boot.bin
>
>                Question: Why the ".resetvec" section should be removed since it's placed at "0xffffffff0" section according to arch/x86/cpu/u-boot.lds?
>

The bootable image u-boot.rom will have these sections backfilled by
ifdtool. See Makefile: IFDTOOL_FLAGS += -w
$(CONFIG_SYS_X86_START16):$(objtree)/u-boot-x86-16bit.bin

>
>            b. cat u-boot.bin dts/dt.dtb > u-boot-dtb.bin
>
>                Question:
>
>                I think ROM is layout at the top of the physical address and quark x1000 SoC will fetch instruction from  FFFF_FFF0H after being power on. If dts/dt.dtb is appended after u-boot.bin, how could the content is effective at FFFF_FFF0H?
>

Like you mentioned above, u-boot.bin has the .resetvec removed, so
itself does not contain anything that occupies FFFF_FFF0h.

Regards,
Bin

[U-Boot] u-boot for Galileo board

[Liu, Changcheng]

Hi Bin,
    1) It's Galileo gen2 board.
    2) Thx for reminding me of the rom target in Makefile.
       I've got the right building process since it extract the boot section and add it to the end of image.
    3) There's one comment error in tools/ifdtool.c and correct it as below.
    4) I work on Galileo gen2 board in my free time and I'll verify the code later.


commit 6f57cd5467c14bb8dc1de72b814a014fefc94820
Date:   Sun Jun 19 10:21:28 2016 +0800

    corrent comment about x86 ROM address
    
    For 8M ROM, the start address should be 0xff800000
    
    Signed-off-by: Changcheng Liu <changcheng.liu@intel.com>

diff --git a/tools/ifdtool.c b/tools/ifdtool.c
index 48059c0..7b41dba 100644
--- a/tools/ifdtool.c
+++ b/tools/ifdtool.c
@@ -704,7 +704,7 @@ int inject_region(char *image, int size, int region_type, char *region_fname)
  * @size:              Size of image in bytes
  * @addr:              x86 ROM address to put file. The ROM ends at
  *                     0xffffffff so use an address relative to that. For an
- *                     8MB ROM the start address is 0xfff80000.
+ *                     8MB ROM the start address is 0xff800000.
  * @write_fname:       Filename to add to the image
  * @offset_uboot_top:  Offset of the top of U-Boot
  * @offset_uboot_start:        Offset of the start of U-Boot


B.R.
Changcheng

On Fri, Jun 17, 2016 at 09:53:42AM +0800, Bin Meng wrote:
> Hi Changcheng,
> 
> On Thu, Jun 16, 2016 at 7:22 PM, Liu, Changcheng
> <changcheng.liu@intel.com> wrote:
> > Hi all,
> >
> >     I have some questions about the u-boot for Galileo2 board.
> >
> >
> >
> >     1. Code: https://github.com/LeMaker/u-boot (it's for Galileo board which could be ported for Galileo2 board)
> >
> >
> 
> What's Galileo2 board? If you are talking about Galileo gen2 board,
> this is already supported by current U-Boot. In fact, both Galileo
> gen1 and gen2 boards are supported in U-Boot with the same code base.
> 
> >
> >     2. Confusing at the building process.
> >
> >            a. objcopy  --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot u-boot.bin
> >
> >                Question: Why the ".resetvec" section should be removed since it's placed at "0xffffffff0" section according to arch/x86/cpu/u-boot.lds?
> >
> 
> The bootable image u-boot.rom will have these sections backfilled by
> ifdtool. See Makefile: IFDTOOL_FLAGS += -w
> $(CONFIG_SYS_X86_START16):$(objtree)/u-boot-x86-16bit.bin
> 
> >
> >            b. cat u-boot.bin dts/dt.dtb > u-boot-dtb.bin
> >
> >                Question:
> >
> >                I think ROM is layout at the top of the physical address and quark x1000 SoC will fetch instruction from  FFFF_FFF0H after being power on. If dts/dt.dtb is appended after u-boot.bin, how could the content is effective at FFFF_FFF0H?
> >
> 
> Like you mentioned above, u-boot.bin has the .resetvec removed, so
> itself does not contain anything that occupies FFFF_FFF0h.
> 
> Regards,
> Bin