On Tue, Feb 12, 2019 at 05:47:00PM +, Andre Przywara wrote:
> 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
On Tue, Feb 12, 2019 at 05:46:59PM +, Andre Przywara wrote:
> 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 DI
On Tue, Feb 12, 2019 at 05:46:58PM +, Andre Przywara wrote:
> 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,
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 the size
> of them.
> DHCP extends this by allowing them to be separ
On Tue, Feb 12, 2019 at 05:46:56PM +, Andre Przywara wrote:
> 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 a
On Tue, Feb 12, 2019 at 05:46:55PM +, Andre Przywara wrote:
> 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-o
On Tue, Feb 12, 2019 at 05:46:54PM +, Andre Przywara wrote:
> 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 cod
On Tue, Feb 12, 2019 at 05:46:53PM +, Andre Przywara wrote:
> 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 parti
Hi Daniel!
On 2/21/19 4:40 PM, Daniel Kiper wrote:
> If you sprinkle the comments similar to above ones into the code then
> I will be happy with the patch.
Ok, thanks. I'll try to get around doing it tomorrow.
> And sorry for late reply but I am recovering after the travel.
No worries. I'm cur
On Thu, Feb 21, 2019 at 03:04:26PM +, Leif Lindholm wrote:
> On Thu, Feb 21, 2019 at 02:46:11PM +, Steve McIntyre wrote:
> > Much like on x86, we can work out if the system is running on top of
> > EFI firmware. If so, return "arm-efi". If not, fall back to
> > "arm-uboot" as previously.
>
On Thu, Feb 21, 2019 at 04:28:40PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Daniel!
>
> Thanks for the review!
>
> On 2/20/19 9:59 PM, Daniel Kiper wrote:
> > On Sat, Feb 09, 2019 at 02:39:05PM +0100, John Paul Adrian Glaubitz wrote:
> >> Recent versions of binutils dropped support for the a.ou
Hi Daniel!
Thanks for the review!
On 2/20/19 9:59 PM, Daniel Kiper wrote:
> On Sat, Feb 09, 2019 at 02:39:05PM +0100, John Paul Adrian Glaubitz wrote:
>> Recent versions of binutils dropped support for the a.out and COFF
>> formats on sparc64 targets. Since the boot loader on sparc64 is
>> suppos
On Thu, Feb 21, 2019 at 3:54 PM Steve McIntyre <93...@debian.org> wrote:
>
> On Thu, Feb 21, 2019 at 03:23:55PM +0100, dann frazier wrote:
> >On Thu, Feb 21, 2019 at 12:42 PM Leif Lindholm
> >wrote:
> >>
> >> Hi Steve,
> >>
> >> On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
> >>
On Thu, Feb 21, 2019 at 12:38:09AM +0100, Alexander Graf wrote:
> > Am 20.02.2019 um 21:46 schrieb Daniel Kiper :
> >> On Tue, Feb 19, 2019 at 04:34:08PM +0100, Alexander Graf wrote:
> >> There is a really convenient service for open source project from Travis
> >> CI: They allow for free CI testin
On Thu, Feb 21, 2019 at 03:23:55PM +0100, dann frazier wrote:
>On Thu, Feb 21, 2019 at 12:42 PM Leif Lindholm
>wrote:
>>
>> Hi Steve,
>>
>> On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
>> > Much like on x86, we can work out if the system is running on top of
>> > EFI firmware.
On Thu, Feb 21, 2019 at 02:46:11PM +, Steve McIntyre wrote:
> Much like on x86, we can work out if the system is running on top of
> EFI firmware. If so, return "arm-efi". If not, fall back to
> "arm-uboot" as previously.
>
> Split out the code to (maybe) load the efivar module and check for
>
On Thu, Feb 21, 2019 at 02:53:48PM +, Steve McIntyre wrote:
> >> Right, this clearly needs a fix.
> >>
> >> > Heavily inspired by the existing code for x86.
> >>
> >> Mmm. I would much prefer if we could break out the efi test in a
> >> separate helper function. And clean it up while we're at i
Much like on x86, we can work out if the system is running on top of
EFI firmware. If so, return "arm-efi". If not, fall back to
"arm-uboot" as previously.
Split out the code to (maybe) load the efivar module and check for
/sys/firmware/efi into a common helper routine is_efi_system()
Signed-off-
On Thu, Feb 21, 2019 at 11:10:35AM +, Steve McIntyre wrote:
> On Thu, Feb 21, 2019 at 10:15:08AM +, Leif Lindholm wrote:
> >grub_efi_get_ram_base() looks for the lowest available RAM address by
> >traversing the memory map, comparing lowest address found so far.
> >Due to a brain glitch, th
Hey Leif,
On Thu, Feb 21, 2019 at 11:41:10AM +, Leif Lindholm wrote:
>On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
>> Much like on x86, we can work out if the system is running on top of
>> EFI firmware. If so, return "arm-efi". If not, fall back to
>> "arm-uboot" as previou
On Thu, Feb 21, 2019 at 12:42 PM Leif Lindholm wrote:
>
> Hi Steve,
>
> On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
> > Much like on x86, we can work out if the system is running on top of
> > EFI firmware. If so, return "arm-efi". If not, fall back to
> > "arm-uboot" as previo
Hi Steve,
On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
> Much like on x86, we can work out if the system is running on top of
> EFI firmware. If so, return "arm-efi". If not, fall back to
> "arm-uboot" as previously.
Right, this clearly needs a fix.
> Heavily inspired by the e
On Thu, Feb 21, 2019 at 10:15:08AM +, Leif Lindholm wrote:
>grub_efi_get_ram_base() looks for the lowest available RAM address by
>traversing the memory map, comparing lowest address found so far.
>Due to a brain glitch, that "so far" was initialized to GRUB_UINT_MAX -
>completely preventing bo
grub_efi_get_ram_base() looks for the lowest available RAM address by
traversing the memory map, comparing lowest address found so far.
Due to a brain glitch, that "so far" was initialized to GRUB_UINT_MAX -
completely preventing boot on systems without RAM below 4GB.
Change the initial value to G
24 matches
Mail list logo
