On Tue, 2019-02-12 at 17:32 +0100, Alexander Graf wrote:
> To support a new architecture we need to provide a few helper
> functions
> for memory, cache, timer, etc support.
>
> This patch adds the remainders of those. Some bits are still
> disabled,
> as I couldn't guarantee that we're always run
On Tue, 2019-02-12 at 11:31 +0100, Alexander Graf wrote:
> This patch adds awareness of RISC-V relocations throughout the grub
> tools
> as well as dynamic linkage and elf->PE relocation conversion support.
>
> Signed-off-by: Alexander Graf
Reviewed-by: Alistair Francis
Alistair
>
> ---
>
>
On Tue, 2019-02-12 at 11:31 +0100, Alexander Graf wrote:
> We now have signature check logic in grub which allows us to treat
> files differently depending on their file type.
>
> Treat a loaded device tree like an overlayed ACPI table.
> Both describe hardware, so I suppose their threat level is
On Tue, 2019-02-12 at 11:31 +0100, Alexander Graf wrote:
> We currently only support to run grub on RISC-V as UEFI payload.
> Ideally,
> we also only want to support running Linux underneath as UEFI
> payload.
>
> Prepare that with some Linux boot stub code. Once the arm64 target is
> generalized,
On Tue, Feb 12, 2019 at 06:00:33PM +0100, Alexander Graf wrote:
> There is a really convenient service for open source project from Travis
> CI: They allow for free CI testing using their infrastructure.
>
> Grub has had issues with broken builds for various targets for a long time
> already. The
From: Andrei Borzenkov
The BOOTP RFC describes the boot file name and the server name as being
part of the integral BOOTP data structure, with some limits on the size
of them.
DHCP extends this by allowing them to be separate DHCP options, which is
more flexible.
Teach the code dealing with thos
From: Andrei Borzenkov
Mostly for cosmetic reasons, we add a "net_dhcp" command, which is
(at the moment) identical to the existing "net_bootp" command. Both
actually trigger a DHCP handshake now, and both should be able to deal
with pure BOOTP servers.
We could think about dropping the DHCP opti
From: Andrei Borzenkov
Change the interface of the function dealing with incoming BOOTP packets
to take an interface instead of a card, to allow more fine per-interface
state (timeout, handshake state) later on.
Signed-off-by: Andre Przywara
---
grub-core/net/bootp.c | 29 -
From: Andrei Borzenkov
Even though we were parsing some DHCP options sent by the server, so far
we are only using the BOOTP 2-way handshake, even when talking to a DHCP
server.
Change this by actually sending out DHCP DISCOVER packets instead of the
generic (mostly empty) BOOTP BOOTREQUEST packe
From: Andrei Borzenkov
In respone to a BOOTREQUEST packet a BOOTP server would answer with a
BOOTREPLY packet, which ends the conversation for good.
DHCP uses a 4-way handshake, where the initial server respone is an OFFER,
which has to be answered with REQUEST by the client again, only to be
com
This is a split-up of the previous all-in-one patch from Andrei,
to teach grub proper DHCP manners.
This split is based on my limited understanding of BOOTP/DHCP and grub,
but it should be an improvement over the single patch version anyway.
All patches compile and work, although only patch 8/9 act
From: Andrei Borzenkov
The comment is right, the "giaddr" fields holds the IP address of the
BOOTP relay, not a general purpose router address.
Just remove the commented code, archeologists can find it in the git
history.
Signed-off-by: Andre Przywara
---
grub-core/net/bootp.c | 29 ---
From: Andrei Borzenkov
Currently we have a global timeout for all network cards in the
BOOTP/DHCP discovery process.
Make this timeout a per-interface one, so better accommodate the
upcoming 4-way DHCP handshake and to also cover the lease time limit a
DHCP offer will come with.
Signed-off-by:
From: Andrei Borzenkov
In contrast to BOOTP, DHCP uses a 4-way handshake, so requires to send
packets more often.
Refactor the generation and sending of the BOOTREQUEST packet into a
separate function, so that future code can more easily reuse this.
Signed-off-by: Andre Przywara
---
grub-core
From: Andrei Borzenkov
For proper DHCP support we will need to parse DHCP options from a packet
more often and at various places.
Refactor the option parsing into a new function, which will scan a
packet to find *a particular* option field.
Use that new function in places where we were dealing w
There is a really convenient service for open source project from Travis
CI: They allow for free CI testing using their infrastructure.
Grub has had issues with broken builds for various targets for a long time
already. The main reason is a lack of CI to just do smoke tests on whether
all targets
To support a new architecture we need to provide a few helper functions
for memory, cache, timer, etc support.
This patch adds the remainders of those. Some bits are still disabled,
as I couldn't guarantee that we're always running on models / in modes
where the respective hardware is available.
Dear developers,
To update many old production servers never updated I need to use an old CentOS
5.6 live CD (CentOS-5.6-i386-LiveCD.iso) which does not support loopback
method. Impossible to get it to work, impossible to boot it always cannot find
root file system!
dd'ing this iso to an USB key
Dear Developers,
I'm trying to use the setparams built-in command.
Documentations say:
- setparams [arg] …
-
Replace positional parameters starting with $1 with arguments tosetparams.
so I'm trying this:
setparams 'fr-FR'
set grub_kblayout_file=${grub_kblayouts_path}/$1.gkb
Resul
We currently only support to run grub on RISC-V as UEFI payload. Ideally,
we also only want to support running Linux underneath as UEFI payload.
Prepare that with some Linux boot stub code. Once the arm64 target is
generalized, we can hook into that one and gain boot functionality.
Signed-off-by:
Some architectures want to boot Linux as plain UEFI binary. Today that
really only encompasses ARM and AArch64, but going forward more
architectures may adopt that model.
So rename our internal API accordingly.
Signed-off-by: Alexander Graf
Acked-by: Leif Lindholm
Reviewed-by: Alistair Francis
This patch adds a 32/64 capable setjmp implementation for RISC-V.
Signed-off-by: Alexander Graf
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Reviewed-by: Daniel Kiper
---
v3 -> v4:
- Change copyright from 2013 to 2018
v4 -> v5:
- Add blank lines before and
The PE format defines magic numbers as well as relocation identifiers for
RISC-V. Add them to our include file, so we can make use of them.
Signed-off-by: Alexander Graf
Reviewed-by: Leif Lindholm
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Reviewed-by: Daniel Kipe
This patch adds awareness of RISC-V relocations throughout the grub tools
as well as dynamic linkage and elf->PE relocation conversion support.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- Fix riscv32 target
v3 -> v4:
- Change copyright from 2013 to 2018
- Add spec reference
v4 -> v5
Gcc may decide it wants to call helper functions to execute clz. Provide
them in our own copy of libgcc.
Signed-off-by: Alexander Graf
---
grub-core/kern/compiler-rt.c | 42 ++
include/grub/compiler-rt.h | 7 +++
2 files changed, 49 insertions(+)
d
We now have signature check logic in grub which allows us to treat
files differently depending on their file type.
Treat a loaded device tree like an overlayed ACPI table.
Both describe hardware, so I suppose their threat level is the same.
Signed-off-by: Alexander Graf
Reviewed-by: Daniel Kiper
This patch adds support for RISC-V to the grub build system. With this
patch, I can successfully build grub on RISC-V as a UEFI application.
Signed-off-by: Alexander Graf
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
v2 -> v3:
- Fix riscv32 target
---
config
The RISC-V ABI document outlines ELF header structure and relocation
information. Pull the respective magic numbers into our elf header
so we can make use of them.
Signed-off-by: Alexander Graf
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Reviewed-by: Daniel Kiper
-
To support a new architecture we need to provide a few helper functions
for memory, cache, timer, etc support.
This patch adds the remainders of those. Some bits are still disabled,
as I couldn't guarantee that we're always running on models / in modes
where the respective hardware is available.
As part of the plan for total world domination, we would like to make sure
that booting on RISC-V is in a sane state before anyone goes and does quick
hacks "just because".
For that reason, U-Boot supports UEFI booting on RISC-V for a while now.
This patch set is the second part of the puzzle, wit
On entry, we need to save the system table pointer as well as our image
handle. Add an early startup file that saves them and then brings us
into our main function.
Signed-off-by: Alexander Graf
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Reviewed-by: Daniel Kiper
31 matches
Mail list logo
