On 3/8/19 4:05 AM, Daniel Kiper wrote:
> OK, thanks. Then Reviewed-by: Daniel Kiper
>
> If there are no objections I will apply this patch next week.
>
> Thank you for doing the work.
Yay, awesome \o/.
@Eric: What do you think about my patch to write the a.out header manually?
See: http://list
Dear Daniel,
On 07.03.19 20:37, Daniel Kiper wrote:
On Thu, Mar 07, 2019 at 12:16:06PM +0100, Paul Menzel wrote:
Date: Wed Mar 6 08:14:28 2019 +0100
By default all file system modules are added to the GRUB coreboot
payload `default_payload.elf`. This makes the image quite big,
especially as o
In order to be able to read from and write to model-specific registers,
two new modules are added. They are i386 specific, as the cpuid module.
rdmsr module registers the command rdmsr that allows reading from a MSR.
wrmsr module registers the command wrmsr that allows writing to a MSR.
wrmsr mod
In order to maintain the coding style consistency, it was requested to
replace the methods that use __asm__ __volatile__ with asm volatile.
Signed-off-by: Jesús Diéguez Fernández
Reviewed-by: Daniel Kiper
---
grub-core/efiemu/runtime/efiemu.c | 10 +-
grub-core/lib/i386/halt.c |
This patch series consist in a code cleanup and two new modules to access MSR:
The first patch replaces __asm__ __volatile__ with asm volatile.
The second patch adds the modules rdmsr and wrmsr, which register two commands
with the same name to read from and write to MSR.
Currently, it lacks a G
El 7/3/19 a las 20:58, Daniel Kiper escribió:
> On Thu, Mar 07, 2019 at 07:05:20PM +0100, Jesús Diéguez Fernández wrote:
>
> [...]
>
[...]
>> - And from a practical point of view, in case that I need to setup a
>> custom handler for this, is it mandatory to ship the patch with it or
>> could it
On Thu, Mar 07, 2019 at 07:05:20PM +0100, Jesús Diéguez Fernández wrote:
[...]
> I've sorted out the MSR support check, but I'm struggling a bit with
Great!
> handling the exception.
Yeah, this can be difficult.
> I've read the Intel SDM and other docs, and I think I understand the
> reason w
On Thu, Mar 07, 2019 at 12:16:06PM +0100, Paul Menzel wrote:
> Date: Wed Mar 6 08:14:28 2019 +0100
>
> By default all file system modules are added to the GRUB coreboot
> payload `default_payload.elf`. This makes the image quite big,
> especially as often not all modules are needed.
>
> Introduce t
On Wed, Mar 06, 2019 at 08:38:27AM -0700, Eric Snowberg wrote:
> > On Mar 6, 2019, at 4:32 AM, Daniel Kiper wrote:
> > On Mon, Mar 04, 2019 at 05:27:39PM -0800, Eric Snowberg wrote:
> >> Add a new disk driver called obdisk for IEEE1275 platforms. Currently
> >> the only platform using this disk d
On Wed, Mar 06, 2019 at 05:53:58PM +0100, Andreas Schwab wrote:
> On Feb 12 2019, Alexander Graf wrote:
>
> > 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".
> >
> >
On Wed, Mar 06, 2019 at 08:56:53AM -0700, Eric Snowberg wrote:
> > On Mar 6, 2019, at 3:52 AM, Daniel Kiper wrote:
> > On Mon, Mar 04, 2019 at 05:34:01PM -0800, Eric Snowberg wrote:
> >> Add BIOS Boot Partition support for sparc64 platforms. This will work a
> >> little different than x86. With
El 6/3/19 a las 15:30, Daniel Kiper escribió:
> On Wed, Mar 06, 2019 at 01:01:07PM +0100, Jesús DF wrote:
>> El mié., 6 mar. 2019 a las 11:32, Daniel Kiper ()
>> escribió:
>>> On Tue, Mar 05, 2019 at 11:17:01PM +0100, Jesús Diéguez Fernández wrote:
Hi,
I have some doubts that I commen
Dear GRUB team,
I'm interested in getting DragonFlyBSD to boot without a BIOS environment (e.g.
using coreboot / libreboot with the coreboot-grub payload to load the kernel
directly) and require some help getting information to relay to the DFly devs
to make this possible.
Booting the kernel d
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.
Use the opportunity to clean up the code a bit.
Signed-off-by: Andre Przywara
Revie
From: Andrei Borzenkov
DHCP specifies a special dummy option OVERLOAD, to allow DHCP options to
spill over into the (legacy) BOOTFILE and SNAME fields.
Parse and handle this option properly.
Signed-off-by: Andre Przywara
---
grub-core/net/bootp.c | 59 +
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
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
Reviewed-by: Daniel Kiper
---
grub-core/n
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
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
Reviewed-by: D
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:
A minor rework compared to v2, addressing Daniel's comments on the list.
The former patch 2/9 has been split up to first refactor the
parse_dhcp_vendor() function, then later introduce the OVERLOAD
functionality. The other minor nits should be fixed as well, also I
added Daniel's Reviewed-by: tags.
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
Date: Wed Mar 6 08:14:28 2019 +0100
By default all file system modules are added to the GRUB coreboot
payload `default_payload.elf`. This makes the image quite big,
especially as often not all modules are needed.
Introduce the variable `FS_PAYLOAD_MODULES`, which can be used to
explicitly set fil
On Thu, 21 Feb 2019 19:49:08 +0100
Daniel Kiper wrote:
> On Tue, Feb 12, 2019 at 05:46:57PM +, Andre Przywara wrote:
> > 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 t
26 matches
Mail list logo
