
On Wed, 2013-08-14 at 12:43 +0800, FengHua wrote:
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年8月14日 星期三 收件人: fenghua@phytium.com.cn 抄送: u-boot@lists.denx.de, trini@ti.com 主题: Re: [U-Boot] [PATCH] part1 of arm64. This patch provide u-boot with arm64 support. Currently it works on Foundation Model for armv8 or Fast Model for armv8.
On Mon, 2013-08-12 at 00:05 +0800, fenghua@phytium.com.cn wrote:
diff --git a/arch/arm64/config.mk b/arch/arm64/config.mk new file mode 100644 index 0000000..e40e983 --- /dev/null +++ b/arch/arm64/config.mk
Does there really need to be a separate arch/arm64? I know this is what Linux does, but on every other 32/64 architecture that decision has been eventually reversed (even on x86, which has about as much difference between 32 and 64 bit as ARM does).
We started working on armv8 U-Boot using a unified arch/arm, and at least got to the point of something that builds, so it doesn't seem impractical. Besides making maintenance easier, it would also make it much easier to review what is being done differently for arm64 (and for any files that do need to be moved or copied, be sure to pass -M -C to git format-patch).
The porting is performed as a seperate architecture due to a few considerations,
- The porting will be simple and clear.
No, it's the opposite. It's hard to review what you changed from arm to arm64.
- There's no any real chip of armv8 until now. Many aspect of armv8 are not completely confirmed.
I'm not sure why that makes a difference.
Of course, it could be merged with ARM at a proper time in the later. Actually, linux kernel follow this mode.
Let's do it the right way from the start.
@@ -0,0 +1,32 @@ +# +# Copyright (c) 2013 FengHua fenghua@phytium.com.cn +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +#
+CROSS_COMPILE ?= /home/fenghua/DS-5-Workspace/gcc-linaro-aarch64-linux-gnu-4.8-2013.05_linux/bin/aarch64-linux-gnu-
Please don't insert references to paths that only work on your computer.
I will fix it.
Plus, what about native builds that don't need a cross compiler?
Currently, there's no real chip of armv8. so,cross compiler is needed.
Eventually there will be (or someone could be masochistic enough to build inside the emulator). The point remains that default CROSS_COMPILE is a bad idea.
diff --git a/common/fdt_support.c b/common/fdt_support.c index b034c98..9bc5821 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -21,6 +21,34 @@ */ DECLARE_GLOBAL_DATA_PTR;
+/*
- Get cells len in bytes
if #NNNN-cells property is 2 then len is 8
otherwise len is 4
- */
+static int get_cells_len(void *blob, char *nr_cells_name) +{
- const fdt32_t *cell;
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell && fdt32_to_cpu(*cell) == 2)
return 8;
- return 4;
+}
+/*
- Write a 4 or 8 byte big endian cell
- */
+static void write_cell(u8 *addr, u64 val, int size) +{
- int shift = (size - 1) * 8;
- while (size-- > 0) {
*addr++ = (val >> shift) & 0xff;
shift -= 8;
- }
+}
/**
- fdt_getprop_u32_default - Find a node and return it's property or a default
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force) {
- int nodeoffset;
- int nodeoffset, addr_cell_len; int err, j, total;
- fdt32_t tmp;
- fdt64_t tmp; const char *path; uint64_t addr, size;
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force) return err; }
- addr_cell_len = get_cells_len(fdt, "#address-cells");
- path = fdt_getprop(fdt, nodeoffset, "linux,initrd-start", NULL); if ((path == NULL) || force) {
tmp = cpu_to_fdt32(initrd_start);
err = fdt_setprop(fdt, nodeoffset, "linux,initrd-start", &tmp, sizeof(tmp)); if (err < 0) {write_cell((u8 *)&tmp, initrd_start, addr_cell_len);
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force) fdt_strerror(err)); return err; }
tmp = cpu_to_fdt32(initrd_end);
err = fdt_setprop(fdt, nodeoffset, "linux,initrd-end", &tmp, sizeof(tmp)); if (err < 0) {write_cell((u8 *)&tmp, initrd_end, addr_cell_len);
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat, do_fixup_by_compat(fdt, compat, prop, &tmp, 4, create); }
-/*
- Get cells len in bytes
if #NNNN-cells property is 2 then len is 8
otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name) -{
- const fdt32_t *cell;
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell && fdt32_to_cpu(*cell) == 2)
return 8;
- return 4;
-}
-/*
- Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size) -{
- int shift = (size - 1) * 8;
- while (size-- > 0) {
*addr++ = (val >> shift) & 0xff;
shift -= 8;
- }
-}
#ifdef CONFIG_NR_DRAM_BANKS #define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS #else
What's going on here?
Whitout this the initrd represented by "linux,initrd-start" could only be placed under 4G address space. This part fix it to 64 bit address space.
Make it a separate patch with a more detailed explanation.
diff --git a/doc/README.arm64 b/doc/README.arm64 new file mode 100644 index 0000000..8fef26d --- /dev/null +++ b/doc/README.arm64 @@ -0,0 +1,10 @@ +Notes:
+1. Currenly, u-boot running at EL2.
+2. Currently, gcc-aarch64 produce error when compiling with pie and rel_dyn.
arm64 uses rela, not rel. This requires a small change to the relocation code and the linker script.
I also try to use rela but it not works. maybe something is wrong with the code.
Was it a build error or a runtime problem?
-Scott