From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: [RFC] New port to arm64-efi
Date: Thu, 14 Nov 2013 15:06:25 +0100 [thread overview]
Message-ID: <5284D8E1.3000504@gmail.com> (raw)
In-Reply-To: <1384432539-7696-1-git-send-email-leif.lindholm@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
Good work. Few minor problems:
On 14.11.2013 13:35, Leif Lindholm wrote:
> +
> + grub_arch_sync_caches_real (address, len);
Why not do alignment here? You could align for both dcache and icache,
this simplifies asm part and makes it a bit more robust.
> + grub_uint32_t insword, insmask;
> + grub_ssize_t offset, offset_low, offset_high;
> +
> + insword = grub_le_to_cpu32 (*place);
> + insmask = 0xfc000000;
> +
> + offset_low = -(1 << 27);
> + offset_high = (1 << 27) - 1;
> +
Should be declared as const.
> +int grub_setjmp (grub_jmp_buf env) __attribute__ ((returns_twice));
We have a macro for returns_twice.
> +/* Unaligned accesses only supported if MMU enabled */
> +#define GRUB_HAVE_UNALIGNED_ACCESS 1
> +
Feels like it shouldn't be defined:
#undef GRUB_HAVE_UNALIGNED_ACCESS
Not defining those does no harm unless there is some weird unaligned device.
> diff --git a/util/grub-install.in b/util/grub-install.in
> index 4cddf5e..a882acf 100644
> --- a/util/grub-install.in
> +++ b/util/grub-install.in
> @@ -280,6 +280,8 @@ if [ x$source_directory = x ]; then
> ;;
> x"arm"*)
> target="arm-uboot";;
> + x"aarch64"*)
> + target="arm64-efi";;
> *)
> gettext "Unable to determine your platform. Use --target." ;
> echo ;;
> @@ -434,6 +436,8 @@ if [ x"$grub_modinfo_platform" = xefi ]; then
> efi_file=BOOTIA64.EFI ;;
> arm)
> efi_file=BOOTARM.EFI ;;
> + arm64)
> + efi_file=BOOTAARCH64.EFI ;;
> esac
> else
> # It is convenient for each architecture to have a different
> @@ -450,6 +454,8 @@ if [ x"$grub_modinfo_platform" = xefi ]; then
> efi_file=grubia64.efi ;;
> arm)
> efi_file=grubarm.efi ;;
> + arm64)
> + efi_file=grubarm64.efi ;;
> *)
> efi_file=grub.efi ;;
> esac
I'l need to merge those into install_c. Will you be available to test it?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
next prev parent reply other threads:[~2013-11-14 14:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 12:35 [RFC] New port to arm64-efi Leif Lindholm
2013-11-14 14:06 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-11-14 15:31 ` Leif Lindholm
2013-11-16 19:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-14 14:12 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-14 15:25 ` Leif Lindholm
2013-11-15 12:02 ` Vladimir 'φ-coder/phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5284D8E1.3000504@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).