Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2014 04:21 PM, Murali Karicheri wrote: > [snip] >>> +Build instructions: >>> +=== >>> + >>> +To build u-boot.bin >>> + >make k2hk_evm_config >>> + >make u-boot-spi.gph >>> + >>> +To build u-boot-spi.gph >>> + >make k2hk_evm_config >>> + >make u-boot-spi.gph >> We need to use CONFIG_SPL_TARGET so that make all just works. > > I am assuming we need to do > > #define CONFIG_SPL_TARGET "u-boot-spi.gph" > > and then > > ./MAKEALL -a arm > > will build this image as well. Is that right? Yes. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTGjnAAAoJENk4IS6UOR1WJyIQAK6bDPHLGoVdi2v+1jktrQ/X H+QTdFvokX9j4gQim7IOIhWvv106N7oeIX7QrCeNieEDPfav1TDMx9vu40DmIiDc o3REaoCzGJ7Vo8kdNIXKwjV7y4tUOjB1q+2b9iqf/p4gJ/OjmQNcbioG9APCIeme cfVZeypANQczMzUfXPGTrZX5GkVOYMFbtkK+pXXckD6XuROWc1CITDXKPjOh1qSt HUQhJA5JtiR72rQvjWXXDsmuGhcYmmSXUQpml/16bBNhb4zxsZxnPB6skv11f0gr kKevhfYREiqAIUmHR888NYB8+PyGsXWoEScYUmzzrFSrZmNH+aUu0gy0/NRaPidg o3dUKun654SbzOXic/Gt/VzFt29ioMmFZAXDHtMwXM+V7V//mhfeQdCDnBgC6ty5 cUtSHsaFmWUuOR3E9IKoeP0Orplf6A8U+wy6swIwmKYPzlEHtI7IL0tweHo/KUyV CYPPBICjJdPconYAN5cV1rQuem+VeBTKTNwtUdXuy9iYk1kwxM3aLi562DVUHBOa oWBi2Aynar4ofFvRqNMYMynJM/ASjs9/nny5jFcxpcvrdzEDlPhcU61mpqEMyBWW 9iJyVN5UV5gJEWf9pofVGdokXl9yZ1YPwjLQF6+KZQwY6qeZhD614yx0MnE9553X 7VOJdxzoPPRazEx3azaB =25vk -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
[snip]
+Build instructions:
+===
+
+To build u-boot.bin
+ >make k2hk_evm_config
+ >make u-boot-spi.gph
+
+To build u-boot-spi.gph
+ >make k2hk_evm_config
+ >make u-boot-spi.gph
We need to use CONFIG_SPL_TARGET so that make all just works.
I am assuming we need to do
#define CONFIG_SPL_TARGET "u-boot-spi.gph"
and then
./MAKEALL -a arm
will build this image as well. Is that right?
Murali
+ if (err < 0)
+ printf("error deleting
linux,initrd-start\n");
Here and elsewhere, puts when we aren't using format chars.
diff --git a/boards.cfg b/boards.cfg
index a8336cc..1690315 100644
--- a/boards.cfg
+++ b/boards.cfg
Please make sure that the entry is correctly sorted, see the top of
boards.cfg.
+++ b/include/configs/k2hk_evm.h
@@ -0,0 +1,221 @@
+/*
+ * Configuration header file for TI's k2hk-evm
+ *
+ * (C) Copyright 2012-2014
+ * Texas Instruments Incorporated,
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __CONFIG_H
Please use __CONFIG_K2HK_EVM_H
+/* Platform type */
+#define CONFIG_SOC_K2HK
+#define CONFIG_K2HK_EVM
Make sure we use these.
+
+/* U-Boot Build Configuration */
+#define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is a 2nd stage loader */
So there's a level before SPL that is doing a certain amount of init we
don't want to re-do?
+#define CONFIG_SYS_DCACHE_OFF
Really?
+#define CONFIG_SYS_MALLOC_LEN (1024 << 10) /* 1 MiB */
This is pretty small, especially since we care about UBI.
+#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 32 << 20)
Please see doc/README.memory-test
+/* SPL SPI Loader Configuration */
+#define CONFIG_SPL_TEXT_BASE 0x0c20
+#define CONFIG_SPL_PAD_TO 65536
+#define CONFIG_SPL_MAX_SIZE(CONFIG_SPL_PAD_TO - 8)
Please explain this a bit more, esp since SPL_PAD_TO should take into
account the header size already...
+#define CONFIG_SPL_BSS_START_ADDR (CONFIG_SPL_TEXT_BASE + \
+CONFIG_SPL_MAX_SIZE)
+#define CONFIG_SPL_BSS_MAX_SIZE(32 * 1024)
Do we really want SPL BSS in early ram (I don't want to get the name of
the type wrong) rather than DDR?
+#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR +\
+CONFIG_SPL_BSS_MAX_SIZE)
+#define CONFIG_SYS_SPL_MALLOC_SIZE (32 * 1024)
Same.
+#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
Please use the default table.
+#define PART_BOOT "1024k(bootloader)ro,"
+#define PART_PARAMS"512k(params)ro,"
+#define PART_UBI "-(ubifs)"
+#define MTDPARTS_DEFAULT "mtdparts=davinci_nand.0:"\
+ PART_BOOT PART_PARAMS PART_UBI
Please just set these outright.
+/* U-Boot command configuration */
+#include
+#undef CONFIG_CMD_BDI
Why?
+#undef CONFIG_CMD_FLASH
Shouldn't be needed.
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_SETGETDCR
Same.
+#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
Not needed.
+ "fdt_high=0x\0" \
Please don't do this, set it to the top of kernel low mem.
+ "mtdparts=mtdparts=davinci_nand.0:" \
+ "1024k(bootloader)ro,512k(params)ro,522752k(ubifs)\0"
Now you're not using the mtdparts you define, this shouldn't be needed.
+/* Linux interfacing */
+#define CONFIG_CMDLINE_TAG
+#define CONFIG_SETUP_MEMORY_TAGS
OF/FDT things should be down here.
+#define LINUX_BOOT_PARAM_ADDR (CONFIG_SYS_SDRAM_BASE + 0x100)
Just use this in the code.
Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/07/2014 11:41 AM, Andrianov, Vitaly wrote:
> Hi Tom,
>
> [snip]
> + "fdt_high=0x\0" \
Please don't do this, set it to the top of kernel low mem.
>>>
>>> The EVM may have up to 8GB of DDR and u-boot can see the first 2GB
>>> with physical address range 0x8000-0x.
>>> If we don't use the "fdt_high" environment variable, u-boot relocates
>>> the dtb to the end of that memory, which is outside of the lowmem.
>>
> [snip]
>
>>> But K2 lowmem VA starts from 0xc000 and has size ~760MB. That
>>> corresponds to the physical range 0x8000-0xaf80.
>>> That is why we have to use the "fdt_high=0x" environment
>> variable.
>>>
>>> Have I missed something I u-boot memory configuration?
>>> Is there a way to tell u-boot to relocate fdt to the end lowmem?
>>
>> Yes, set fdt_high to 0xaf80 instead :)
>>
>
> I think there is a bug in the lmb_alloc_base() and this approach doesn't
> work.
>
> else if (lmbbase < max_addr) {
> base = min(lmbbase + lmbsize, max_addr);
> base = lmb_align_down(base - size, align);
> } else
>
> For boards that have DDR at the end of 32 bit address space the
> (lmbbase + lmbsize) = 0 which is < max_addr.
> So, base becomes 0, and moved to the "end of DDR" - size on the next line.
>
> I tried a quick fix in the __lmb_alloc_base() and got the fdt relocated
> correctly.
> As I'm not sure that is only one buggy place in the lmb.c I don't want to
> commit
> the quick fix. Let's leave the "fdt_high=0x" in the Keystone2 for
> awhile
> and change it later when we fix the bug.
If you're committing to look at this later then yes.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTGfjRAAoJENk4IS6UOR1WxBYQAKjH1cWlziYl74cR7FhPINWd
WEn7AtPKYLXs47D8dMYvshjrg9kBgjpy3VqDKf23t3yndBUugmznV5MdmSMlx2IQ
TuNg0ICqnXt/2NxclKwxtmznohIwx2t8gJ355UP9XzGrr17lf1+WglOvBolI0R0m
VjP3eBivHDlfwLHF3MWdLjmCjGn1sVDCng2JuZZIjfoqxGto2UsDllh1CQx2O9js
tOeAY+i5cHCag8b5+6jtujZ6GICwQ0vg2qB5XFXeOYAZWY+XTvlGgQCZ27RaspRF
pBHhlOH7iftUnKOTGt/HauEnB62TSfSPjan9ww48VA861fAkrpeANjtPz9uZQKwh
Hd/Ib0XOHrfKkReerF/C+R2vJjlYBfKeEFCvF+SuZApgIMX6am4gdHWiGgZq45/Q
YemR9Exj+KJ4MYZky/a8y2z8cowck+RsnpZozojFiPlNmuvXS+qXZste42nIYTRX
puZx4+xogoaLL4HHjOuKR6QlnCSQDvyxPvLPMNw5HbrZ3Eof0Uwxu2omnJpUvx2+
v/xl6gsqcxOZ07Mz7g3sGwsG5HWZPevFK8CZd8xDFQwj/DZo4pAJO7XFj4MZTgaM
Tg3bpsvQFugK9yU/F96Uoie0EYCpCsgGPu5moOSPYB4sl8OlkHj0Mw1oq3rpWF77
2bFm9XxAOL/awEM/X2l/
=n9Wd
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
Hi Tom,
[snip]
> >>
> >>> + "fdt_high=0x\0" \
> >>
> >> Please don't do this, set it to the top of kernel low mem.
> >>
> >
> > The EVM may have up to 8GB of DDR and u-boot can see the first 2GB
> > with physical address range 0x8000-0x.
> > If we don't use the "fdt_high" environment variable, u-boot relocates
> > the dtb to the end of that memory, which is outside of the lowmem.
>
[snip]
> > But K2 lowmem VA starts from 0xc000 and has size ~760MB. That
> > corresponds to the physical range 0x8000-0xaf80.
> > That is why we have to use the "fdt_high=0x" environment
> variable.
> >
> > Have I missed something I u-boot memory configuration?
> > Is there a way to tell u-boot to relocate fdt to the end lowmem?
>
> Yes, set fdt_high to 0xaf80 instead :)
>
I think there is a bug in the lmb_alloc_base() and this approach doesn't
work.
else if (lmbbase < max_addr) {
base = min(lmbbase + lmbsize, max_addr);
base = lmb_align_down(base - size, align);
} else
For boards that have DDR at the end of 32 bit address space the
(lmbbase + lmbsize) = 0 which is < max_addr.
So, base becomes 0, and moved to the "end of DDR" - size on the next line.
I tried a quick fix in the __lmb_alloc_base() and got the fdt relocated
correctly.
As I'm not sure that is only one buggy place in the lmb.c I don't want to commit
the quick fix. Let's leave the "fdt_high=0x" in the Keystone2 for
awhile
and change it later when we fix the bug.
Thanks,
Vitaly
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 02:09 PM, Andrianov, Vitaly wrote: > Hi Tom, > >> -Original Message- >> From: u-boot-boun...@lists.denx.de [mailto:u-boot- >> boun...@lists.denx.de] On Behalf Of Rini, Tom >> Sent: Tuesday, February 25, 2014 5:12 PM >> To: Karicheri, Muralidharan >> Cc: Kwok, WingMan; u-boot@lists.denx.de; Nair, Sandeep >> Subject: Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for >> k2hk SOC and EVM >> >> On Thu, Feb 20, 2014 at 12:55:10PM -0500, Murali Karicheri wrote: >> >>> From: Vitaly Andrianov >>> >>> k2hk EVM is based on Texas Instruments Keystone2 Hawking/Kepler SoC. >>> Keystone2 SoC has ARM v7 Cortex-A15 MPCore processor. Please refer >> the >>> ti/k2hk_evm/README for details on the board, build and other >>> information. >>> >>> This patch add support for keystone architecture and k2hk evm. >>> >>> Signed-off-by: Vitaly Andrianov >>> Signed-off-by: Murali Karicheri >>> Signed-off-by: WingMan Kwok >>> Signed-off-by: Sandeep Nair > > [snip] >> >>> + "fdt_high=0x\0" \ >> >> Please don't do this, set it to the top of kernel low mem. >> > > The EVM may have up to 8GB of DDR and u-boot can see the first 2GB > with physical address range 0x8000-0x. > If we don't use the "fdt_high" environment variable, u-boot relocates > the dtb to the end of that memory, which is outside of the lowmem. Right. > Here is the part of bootlog: > - > ## Flattened Device Tree blob at 8700 >Booting using the fdt blob at 0x8700 >Loading Kernel Image ... OK > OK >Loading Device Tree to 1000, end fcab ... OK > -- > > But K2 lowmem VA starts from 0xc000 and has size ~760MB. That > corresponds to the physical range 0x8000-0xaf80. > That is why we have to use the "fdt_high=0x" environment variable. > > Have I missed something I u-boot memory configuration? > Is there a way to tell u-boot to relocate fdt to the end lowmem? Yes, set fdt_high to 0xaf80 instead :) - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTGMyjAAoJENk4IS6UOR1WGvwP/0uN28wfBHAY3u6reHUv77H4 Xq5OMMxhtS+fOSvUZORBmV22aliFIX7vckshM65KgWQkmxx0fO8zmuVRxUMdXL9R rNGa7azCtQVTwJTvuWDxEhVLxQbIJk+9YuBGGajLG1qDpYBhkAVendpGPGt8FflX YW5pJxMztcRm4bVFZxXZkiqzAwPDc+f/yAYD9VUHnwCImqpTEAcvF7ktUU6QpClr D1DySfhFyV6v0r3/WRVMzsiCmQq5mOkla/dWW0xPp4fl+4trN2sQeM5fusQXd1kR qq2M3hmYRSgo++h9mQDjhKbTmpFi/mRLuYiq0nk90tnAOBH6aOTZoKlpFaqFEO3b /DXq2wUheKs6Y4eE1WtAB99MBkt3u4bLAR1WuVNifdGPgIsUum95WqWQdedKyu4L nGALiBuceykkn0FvvpCa8F8LnF+3BzXY2OmY/VtfwZ3qhcW7/gzaVwPX7rLs035d 1hTJapU9LtmBcDk7Bme4OlTrQczquAo2zfDwKaR3MnPVrDHnwBfsPJ1mWVcWU4dC ATvb8kbLM8TBgKrn/Qsx9DARkeVb+R6/WX99c2bzWtorrVU/oO632B8fDlbi02vi bJVPc/OEMPjB9FHychiDwtBkGCt6pgu3GJ4VVviVmnH50RHKU+sC/DuNg2kmRLmf pXfAZ0dbyhCs0uPnhbS/ =WBxm -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
Hi Tom, > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot- > boun...@lists.denx.de] On Behalf Of Rini, Tom > Sent: Tuesday, February 25, 2014 5:12 PM > To: Karicheri, Muralidharan > Cc: Kwok, WingMan; u-boot@lists.denx.de; Nair, Sandeep > Subject: Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for > k2hk SOC and EVM > > On Thu, Feb 20, 2014 at 12:55:10PM -0500, Murali Karicheri wrote: > > > From: Vitaly Andrianov > > > > k2hk EVM is based on Texas Instruments Keystone2 Hawking/Kepler SoC. > > Keystone2 SoC has ARM v7 Cortex-A15 MPCore processor. Please refer > the > > ti/k2hk_evm/README for details on the board, build and other > > information. > > > > This patch add support for keystone architecture and k2hk evm. > > > > Signed-off-by: Vitaly Andrianov > > Signed-off-by: Murali Karicheri > > Signed-off-by: WingMan Kwok > > Signed-off-by: Sandeep Nair [snip] > > > + "fdt_high=0x\0" \ > > Please don't do this, set it to the top of kernel low mem. > The EVM may have up to 8GB of DDR and u-boot can see the first 2GB with physical address range 0x8000-0x. If we don't use the "fdt_high" environment variable, u-boot relocates the dtb to the end of that memory, which is outside of the lowmem. Here is the part of bootlog: - ## Flattened Device Tree blob at 8700 Booting using the fdt blob at 0x8700 Loading Kernel Image ... OK OK Loading Device Tree to 1000, end fcab ... OK -- But K2 lowmem VA starts from 0xc000 and has size ~760MB. That corresponds to the physical range 0x8000-0xaf80. That is why we have to use the "fdt_high=0x" environment variable. Have I missed something I u-boot memory configuration? Is there a way to tell u-boot to relocate fdt to the end lowmem? Thanks, Vitaly ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/03/2014 01:20 PM, Murali Karicheri wrote:
>
> diff --git a/Makefile b/Makefile
> index 47a03e3..ea2a387 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -491,6 +491,23 @@ $(obj)u-boot.spr:$(obj)u-boot.img
> $(obj)spl/u-boot-spl.bin
> --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff $@
> cat $(obj)u-boot.img >> $@
>
> +$(obj)u-boot-spi.gph:$(obj)u-boot.img $(obj)spl/u-boot-spl.bin
> +$(obj)tools/mkimage -A $(ARCH) -T gpimage -C none \
> +-a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) \
> +-n SPL -d $(obj)spl/u-boot-spl.bin $(obj)spl/u-boot-spl.gph
> +$(OBJCOPY) ${OBJCFLAGS} -I binary \
> +--pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0 -O binary \
> +$(obj)spl/u-boot-spl.gph $(obj)spl/u-boot-spl-pad.gph
> +cat $(obj)spl/u-boot-spl-pad.gph $(obj)u-boot.img > $@
> +
> +$(obj)u-boot-nand.gph:$(obj)u-boot.bin
> +$(obj)tools/mkimage -A $(ARCH) -T gpimage -C none \
> +-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \
> +-n U-Boot -d $(obj)u-boot.bin $(obj)gph-u-boot.bin
> +@dd if=/dev/zero of=$(obj)zero.bin bs=8 count=1 2>/dev/null
> +@cat $(obj)gph-u-boot.bin $(obj)zero.bin > $@
> +@rm $(obj)zero.bin
>
>> First, these need re-writing for Kbuild. Second, we don't ever use
>> u-boot-nand.gph or talk about it in the README, do we?
> Tom,
>
> Will remove remove u-boot-nand.gph for time being as we didn't verify
> nand boot in this
> series. What you mean by re-writing for kbuild. The u-boot-spi.gph
> target is added similar to
> existing u-boot-spr (see just above this target). Could you provide an
> example?
Yes, look at how u-boot.spr looks on master now. Things have changed a
good bit and this needs updating again.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTFMoGAAoJENk4IS6UOR1WlpIP/Rkbl9ejGjmlvUcFQ6klnrNH
ztie7jDThbxqlnGJJJVCALCf5sWgI/W5X/IaiFtBJsAF2JE0h8HaCQjvjBU2r0vq
HSXMzBMfXXURrgbtuU8OcrkG8CUN93rQj06Q3hDNSej2cIQAuZt685G3svQ//Jnw
rvhg3rnnXFK/ypEE20ZT1bETlH76e/RAZXd/V897j53j4rnWzonQisF0P1C9Nguu
DRdH0DPQ4VaDfQ8MHAG9M0L79mSFFaDS6o9fkipEiPJjwYjoI5CNbzcd9jszcWhw
fQtkTl1B7tiD7Aqd48apytOvjO8RSrGyJ1ntdOCvnqlemvACMMO/RoWqJtOnZLD/
6PhPIN4ewYPoWop5Hf8fgSAvaYEQW7s5TnB6KKnk3MTixCtzdFOywoAqAhxZAV6p
eOglTRQ81rR702fHJBT7uNQrUGIjc6DebjtcJkEZmWNoT8TZAvpXXIqLu/3PeFna
U/Ppfq2C4SUyRXf365aODGicKhkEuRi1XseluytvHFHL3/sJZgrkRF32+/g3JBv/
haP/MVw4nGSN4dgsb/UQCBxoLHe6wWfXPktYvHN1ne1QUaXzLbHdi7TM4tejfjjS
ULjMWpaaOuPPgrkQsleAL20Ctx6oY/aArnXf1qjj+CJ0cU1hnYWOxXoOEDVVjYI+
5f9FAQtYTSgSV1uvhX9u
=k4+m
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
diff --git a/Makefile b/Makefile
index 47a03e3..ea2a387 100644
--- a/Makefile
+++ b/Makefile
@@ -491,6 +491,23 @@ $(obj)u-boot.spr: $(obj)u-boot.img
$(obj)spl/u-boot-spl.bin
--pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff $@
cat $(obj)u-boot.img >> $@
+$(obj)u-boot-spi.gph: $(obj)u-boot.img $(obj)spl/u-boot-spl.bin
+ $(obj)tools/mkimage -A $(ARCH) -T gpimage -C none \
+ -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) \
+ -n SPL -d $(obj)spl/u-boot-spl.bin
$(obj)spl/u-boot-spl.gph
+ $(OBJCOPY) ${OBJCFLAGS} -I binary \
+ --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0 -O binary \
+ $(obj)spl/u-boot-spl.gph $(obj)spl/u-boot-spl-pad.gph
+ cat $(obj)spl/u-boot-spl-pad.gph $(obj)u-boot.img > $@
+
+$(obj)u-boot-nand.gph: $(obj)u-boot.bin
+ $(obj)tools/mkimage -A $(ARCH) -T gpimage -C none \
+ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \
+ -n U-Boot -d $(obj)u-boot.bin $(obj)gph-u-boot.bin
+ @dd if=/dev/zero of=$(obj)zero.bin bs=8 count=1 2>/dev/null
+ @cat $(obj)gph-u-boot.bin $(obj)zero.bin > $@
+ @rm $(obj)zero.bin
First, these need re-writing for Kbuild. Second, we don't ever use
u-boot-nand.gph or talk about it in the README, do we?
Tom,
Will remove remove u-boot-nand.gph for time being as we didn't verify
nand boot in this
series. What you mean by re-writing for kbuild. The u-boot-spi.gph
target is added similar to
existing u-boot-spr (see just above this target). Could you provide an
example?
Murali
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot PATCH v2 08/12] k2hk: add support for k2hk SOC and EVM
On Thu, Feb 20, 2014 at 12:55:10PM -0500, Murali Karicheri wrote:
> From: Vitaly Andrianov
>
> k2hk EVM is based on Texas Instruments Keystone2 Hawking/Kepler
> SoC. Keystone2 SoC has ARM v7 Cortex-A15 MPCore processor. Please
> refer the ti/k2hk_evm/README for details on the board, build and other
> information.
>
> This patch add support for keystone architecture and k2hk evm.
>
> Signed-off-by: Vitaly Andrianov
> Signed-off-by: Murali Karicheri
> Signed-off-by: WingMan Kwok
> Signed-off-by: Sandeep Nair
[snip]
> diff --git a/Makefile b/Makefile
> index 47a03e3..ea2a387 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -491,6 +491,23 @@ $(obj)u-boot.spr:$(obj)u-boot.img
> $(obj)spl/u-boot-spl.bin
> --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff $@
> cat $(obj)u-boot.img >> $@
>
> +$(obj)u-boot-spi.gph:$(obj)u-boot.img $(obj)spl/u-boot-spl.bin
> + $(obj)tools/mkimage -A $(ARCH) -T gpimage -C none \
> + -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) \
> + -n SPL -d $(obj)spl/u-boot-spl.bin
> $(obj)spl/u-boot-spl.gph
> + $(OBJCOPY) ${OBJCFLAGS} -I binary \
> + --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0 -O binary \
> + $(obj)spl/u-boot-spl.gph $(obj)spl/u-boot-spl-pad.gph
> + cat $(obj)spl/u-boot-spl-pad.gph $(obj)u-boot.img > $@
> +
> +$(obj)u-boot-nand.gph: $(obj)u-boot.bin
> + $(obj)tools/mkimage -A $(ARCH) -T gpimage -C none \
> + -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \
> + -n U-Boot -d $(obj)u-boot.bin $(obj)gph-u-boot.bin
> + @dd if=/dev/zero of=$(obj)zero.bin bs=8 count=1 2>/dev/null
> + @cat $(obj)gph-u-boot.bin $(obj)zero.bin > $@
> + @rm $(obj)zero.bin
First, these need re-writing for Kbuild. Second, we don't ever use
u-boot-nand.gph or talk about it in the README, do we?
[snip]
> +void init_pll(const struct pll_init_data *data)
> +{
> + u32 tmp, tmp_ctl, pllm, plld, pllod, bwadj;
> +
> + pllm = data->pll_m - 1;
> + plld = (data->pll_d - 1) & PLL_DIV_MASK;
> + pllod = (data->pll_od - 1) & PLL_CLKOD_MASK;
> +
> + if (data->pll == MAIN_PLL) {
> + sdelay(21);
Comments on the delay please.
> diff --git a/arch/arm/cpu/armv7/keystone/config.mk
> b/arch/arm/cpu/armv7/keystone/config.mk
> new file mode 100644
> index 000..1c8769c
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/keystone/config.mk
> @@ -0,0 +1,15 @@
> +# (C) Copyright 2012-2014
> +# Texas Instruments Incorporated,
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
This is incorrect and not needed.
> +# =
> +#
> +# Supply options according to compiler version
> +#
> +# =
> +PF_CPPFLAGS_SLB +=$(call cc-option,-mshort-load-bytes,\
> + $(call cc-option,-malignment-traps,))
> +PLATFORM_RELFLAGS += $(PF_CPPFLAGS_SLB)
Also not needed.
> diff --git a/arch/arm/cpu/armv7/keystone/init.c
> b/arch/arm/cpu/armv7/keystone/init.c
> new file mode 100644
> index 000..1b7e52a
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/keystone/init.c
[snip]
> +void reset_cpu(ulong addr)
> +{
> + volatile u32 *rstctrl = (volatile u32 *)(CLOCK_BASE + 0xe8);
> + u32 tmp;
> +
> + tmp = *rstctrl & 0x;
> + *rstctrl = tmp | 0x5a69;
> +
> + *rstctrl &= 0xfffe;
Comments / define these please.
> +++ b/arch/arm/cpu/armv7/keystone/psc.c
[snip]
> +/*
> + * FUNCTION PURPOSE: Wait for end of transitional state
> + *
> + * DESCRIPTION: Polls pstat for the selected domain and waits for transitions
> + * to be complete.
> + *
> + * Since this is boot loader code it is *ASSUMED* that
> interrupts
> + * are disabled and no other core is mucking around with the psc
> + * at the same time.
> + *
> + * Returns 0 when the domain is free. Returns -1 if a timeout
> + * occurred waiting for the completion.
Rewrap these lines please, and anywhere else things are too long.
> +++ b/arch/arm/cpu/armv7/keystone/spl.c
[snip]
> +u32 spl_boot_device(void)
> +{
> +#if defined(CONFIG_SPL_SPI_LOAD)
> + return BOOT_DEVICE_SPI;
> +#else
> + puts("Unknown boot device\n");
> + hang();
> +#endif
return -EINVAL (or define and use BOOT_DEVICE_UNKNOWN) and fall back to
the common hang() case please.
> + u32 __pad0;
General form is resvN.
[snip]
> +struct davinci_emif_regs {
> + u_int32_t ercsr;
Generally we do uint32_t
[snip]
> +#define REG(addr) (*(volatile unsigned int *)(addr))
> +#define REG_P(addr) ((volatile unsigned int *)(addr))
> +
> +typedef volatile unsigned intdv_reg;
> +typedef vola
