Generic communication of boot loader state to the OS

Generic communication of boot loader state to the OS

[jonsmirl-Re5JQEeQqe8AvxtiuMwx3w]

New thread split off from the simple-framebuffer discussion....

Is there a generic, underlying problem here that needs to be solved?
AFAIK no one has designed a general purpose mechanism for
communicating boot loader state to the OS. There is the existing
device tree <chosen> node but it is limited compared to what is
needed. Maybe we should step back and first design a good solution to
this basic problem. Then specific solutions for things like
framebuffers would fall out of the basic design.

So what are the requirements?
1) Indicate that the boot loader has set up a device
2) Indicate the purpose of that device
3) Protect the resources in use
4) Provide for a handoff to the OS specific device driver
5) Communicate all of this via the device tree

So what is a device tree syntax that would solve this general problem?
As a first design attempt, I would propose <boot> (or <chosen>) child
nodes be added to the various core devices. By core device I mean the
top level device, like the framebuffer, not each dependent clock and
regulator.

Inside the <boot> nodes a compatible string would be used to designate
a device class the bootloader has assigned to the devices. For example
- serial, framebuffer, media, input, network.

Some examples, I've deleted a lot of properties to make them smaller.
The boot loader could add these nodes either statically or
dynamically.

uart0: uart@01c18000 {
        compatible = "allwinner,sun4i-a10-uart";
        clocks = <&ahb_gates 20>, <&uart2_clk>;
        clock-names = "ahb", "mod";
        boot {
                compatible = "boot,serial";
                baud = <192000>;
                console;
       };
};

reserved-memory {
        display_reserved: framebuffer@78000000 {
                reg = <0x78000000 0x800000>;
        };
};

fb0: fb@01c10000 {
        compatible = "allwinner,sun4i-a10-framebuffer";
        clocks = <&ahb_gates 18>, <&fb2_clk>;
        clock-names = "ahb", "mod";
        boot {
                compatible = "boot,framebuffer";
                memory-region = <&display_reserved>;
        };
};

spi1: spi@01c16000 {
        compatible = "allwinner,sun4i-a10-spi";
        clocks = <&ahb_gates 22>, <&spi2_clk>;
        clock-names = "ahb", "mod";

        flash0: flash@2 {
        compatible = "atmel,at12345";
        reg = <2>;
        spi-max-frequency = <100000>;
                boot {
                        compatible = "boot,media";
                };
        };
};

An OS booting off from a device tree like this can then implement
support for boot,xxxx drivers if it chooses. If it doesn't implement
support for the boot tags, nothing changes from the current situation.

The problem with clocks and regulators can be addressed by following
the chains of clocks/regulators in the parent nodes of the boot
sections. This would be implement by these frameworks providing a
"claim_all_xxx(DT node)" function.  A boot,framebuffer driver would
first call claim_all_clk(parent node) and claim_all_regulator(parent
node). Need to figure out exactly how these functions would work.

Driver handoff is the OS's problem. Under Linux the device specific
drivers could soft-link to the boot,xxx code. After the device
specific driver is fully initialized it would tell the boot,xxx driver
to let go.

As a side effect this will eliminate the need for kernel command line
parameters describing boot state. Like console="". Over time it might
even be able to pass a DHCP IP address from uboot into the kernel.

This is just a first attempt, how can we improve on this?

-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Generic communication of boot loader state to the OS

[Mark Rutland]

Hi Jon,

On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> New thread split off from the simple-framebuffer discussion....
> 
> Is there a generic, underlying problem here that needs to be solved?
> AFAIK no one has designed a general purpose mechanism for
> communicating boot loader state to the OS. There is the existing
> device tree <chosen> node but it is limited compared to what is
> needed. Maybe we should step back and first design a good solution to
> this basic problem. Then specific solutions for things like
> framebuffers would fall out of the basic design.

I think the fundamental problem here is unfortunately far too abstract
for the general solution to be any more concrete. The solution to "we
don't communicate boot state" is "we should communicate boot state".

We can perhaps come up with general guidelines (for instance, the clock
subsystem has assigned-* properties), but I don't think there's a
one-size-fits-all solution.

> So what are the requirements?
> 1) Indicate that the boot loader has set up a device
> 2) Indicate the purpose of that device
> 3) Protect the resources in use
> 4) Provide for a handoff to the OS specific device driver
> 5) Communicate all of this via the device tree
> 
> So what is a device tree syntax that would solve this general problem?
> As a first design attempt, I would propose <boot> (or <chosen>) child
> nodes be added to the various core devices. By core device I mean the
> top level device, like the framebuffer, not each dependent clock and
> regulator.
> 
> Inside the <boot> nodes a compatible string would be used to designate
> a device class the bootloader has assigned to the devices. For example
> - serial, framebuffer, media, input, network.

In general we should already know the class of device if we have a
driver for said device, no?

As far as I can tell all we need to have is a way of designating
preferred devices and their preferred/current configuration. We have
bits of that already (e.g. stdout-path, assigned-rate).

> Some examples, I've deleted a lot of properties to make them smaller.
> The boot loader could add these nodes either statically or
> dynamically.
> 
> uart0: uart@01c18000 {
>         compatible = "allwinner,sun4i-a10-uart";
>         clocks = <&ahb_gates 20>, <&uart2_clk>;
>         clock-names = "ahb", "mod";
>         boot {
>                 compatible = "boot,serial";
>                 baud = <192000>;
>                 console;
>        };
> };

There's already the stdout-path (and stdin-path) binding for designating
a serial port. I think we should improve support for those rather than
introducing a new binding. The only painful part is describing the
pre-configured rate if the OS needs to know.

> reserved-memory {
>         display_reserved: framebuffer@78000000 {
>                 reg = <0x78000000 0x800000>;
>         };
> };
> 
> fb0: fb@01c10000 {
>         compatible = "allwinner,sun4i-a10-framebuffer";
>         clocks = <&ahb_gates 18>, <&fb2_clk>;
>         clock-names = "ahb", "mod";
>         boot {
>                 compatible = "boot,framebuffer";
>                 memory-region = <&display_reserved>;
>         };
> };

I was under the impression that the reserved-memory binding could be
used for handing over the memory in use by a framebuffer, so as far as I
can see we only new thing to communicate would be the configured mode of
the display.

Do we have any systems with multiple displays where we need to specify
which is preferred?

> spi1: spi@01c16000 {
>         compatible = "allwinner,sun4i-a10-spi";
>         clocks = <&ahb_gates 22>, <&spi2_clk>;
>         clock-names = "ahb", "mod";
> 
>         flash0: flash@2 {
>         compatible = "atmel,at12345";
>         reg = <2>;
>         spi-max-frequency = <100000>;
>                 boot {
>                         compatible = "boot,media";
>                 };
>         };
> };

Is this a problem on existing systems? Do we need a DT property?

If so, this would be better as something like /chosen/root-device (so
you can't accidentally describe multiple devices as the boot medium).

> An OS booting off from a device tree like this can then implement
> support for boot,xxxx drivers if it chooses. If it doesn't implement
> support for the boot tags, nothing changes from the current situation.
> 
> The problem with clocks and regulators can be addressed by following
> the chains of clocks/regulators in the parent nodes of the boot
> sections. This would be implement by these frameworks providing a
> "claim_all_xxx(DT node)" function.  A boot,framebuffer driver would
> first call claim_all_clk(parent node) and claim_all_regulator(parent
> node). Need to figure out exactly how these functions would work.

I'm not sure I follow. What is the problem with clocks and regulators
that this tries to solve?

Are we just trying to leave them in their current configuration (rather
than disabling)? Are we trying to prevent other drivers from fiddling
with them? Something else?

> Driver handoff is the OS's problem. Under Linux the device specific
> drivers could soft-link to the boot,xxx code. After the device
> specific driver is fully initialized it would tell the boot,xxx driver
> to let go.

I'm not sure I follow why we need the stub drivers at all. Is the idea
to just have them hog resources until the real driver comes up?

> As a side effect this will eliminate the need for kernel command line
> parameters describing boot state. Like console="". Over time it might
> even be able to pass a DHCP IP address from uboot into the kernel.

We have a generic mechanism for communicating the MAC address of an
ethernet adapter. I don't see a fundamental reason we can't add
properties to communicate a DHCP lease and associated information. Is
anyone looking into that?

Thanks,
Mark.

Re: Generic communication of boot loader state to the OS

[jonsmirl-Re5JQEeQqe8AvxtiuMwx3w]

On Tue, Aug 26, 2014 at 1:16 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi Jon,
>
> On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>> New thread split off from the simple-framebuffer discussion....
>>
>> Is there a generic, underlying problem here that needs to be solved?
>> AFAIK no one has designed a general purpose mechanism for
>> communicating boot loader state to the OS. There is the existing
>> device tree <chosen> node but it is limited compared to what is
>> needed. Maybe we should step back and first design a good solution to
>> this basic problem. Then specific solutions for things like
>> framebuffers would fall out of the basic design.
>
> I think the fundamental problem here is unfortunately far too abstract
> for the general solution to be any more concrete. The solution to "we
> don't communicate boot state" is "we should communicate boot state".
>
> We can perhaps come up with general guidelines (for instance, the clock
> subsystem has assigned-* properties), but I don't think there's a
> one-size-fits-all solution.
>
>> So what are the requirements?
>> 1) Indicate that the boot loader has set up a device
>> 2) Indicate the purpose of that device
>> 3) Protect the resources in use
>> 4) Provide for a handoff to the OS specific device driver
>> 5) Communicate all of this via the device tree
>>
>> So what is a device tree syntax that would solve this general problem?
>> As a first design attempt, I would propose <boot> (or <chosen>) child
>> nodes be added to the various core devices. By core device I mean the
>> top level device, like the framebuffer, not each dependent clock and
>> regulator.
>>
>> Inside the <boot> nodes a compatible string would be used to designate
>> a device class the bootloader has assigned to the devices. For example
>> - serial, framebuffer, media, input, network.
>
> In general we should already know the class of device if we have a
> driver for said device, no?
>
> As far as I can tell all we need to have is a way of designating
> preferred devices and their preferred/current configuration. We have
> bits of that already (e.g. stdout-path, assigned-rate).
>
>> Some examples, I've deleted a lot of properties to make them smaller.
>> The boot loader could add these nodes either statically or
>> dynamically.
>>
>> uart0: uart@01c18000 {
>>         compatible = "allwinner,sun4i-a10-uart";
>>         clocks = <&ahb_gates 20>, <&uart2_clk>;
>>         clock-names = "ahb", "mod";
>>         boot {
>>                 compatible = "boot,serial";
>>                 baud = <192000>;
>>                 console;
>>        };
>> };
>
> There's already the stdout-path (and stdin-path) binding for designating
> a serial port. I think we should improve support for those rather than
> introducing a new binding. The only painful part is describing the
> pre-configured rate if the OS needs to know.
>
>> reserved-memory {
>>         display_reserved: framebuffer@78000000 {
>>                 reg = <0x78000000 0x800000>;
>>         };
>> };
>>
>> fb0: fb@01c10000 {
>>         compatible = "allwinner,sun4i-a10-framebuffer";
>>         clocks = <&ahb_gates 18>, <&fb2_clk>;
>>         clock-names = "ahb", "mod";
>>         boot {
>>                 compatible = "boot,framebuffer";
>>                 memory-region = <&display_reserved>;
>>         };
>> };
>
> I was under the impression that the reserved-memory binding could be
> used for handing over the memory in use by a framebuffer, so as far as I
> can see we only new thing to communicate would be the configured mode of
> the display.
>
> Do we have any systems with multiple displays where we need to specify
> which is preferred?
>
>> spi1: spi@01c16000 {
>>         compatible = "allwinner,sun4i-a10-spi";
>>         clocks = <&ahb_gates 22>, <&spi2_clk>;
>>         clock-names = "ahb", "mod";
>>
>>         flash0: flash@2 {
>>         compatible = "atmel,at12345";
>>         reg = <2>;
>>         spi-max-frequency = <100000>;
>>                 boot {
>>                         compatible = "boot,media";
>>                 };
>>         };
>> };
>
> Is this a problem on existing systems? Do we need a DT property?
>
> If so, this would be better as something like /chosen/root-device (so
> you can't accidentally describe multiple devices as the boot medium).
>
>> An OS booting off from a device tree like this can then implement
>> support for boot,xxxx drivers if it chooses. If it doesn't implement
>> support for the boot tags, nothing changes from the current situation.
>>
>> The problem with clocks and regulators can be addressed by following
>> the chains of clocks/regulators in the parent nodes of the boot
>> sections. This would be implement by these frameworks providing a
>> "claim_all_xxx(DT node)" function.  A boot,framebuffer driver would
>> first call claim_all_clk(parent node) and claim_all_regulator(parent
>> node). Need to figure out exactly how these functions would work.
>
> I'm not sure I follow. What is the problem with clocks and regulators
> that this tries to solve?
>
> Are we just trying to leave them in their current configuration (rather
> than disabling)? Are we trying to prevent other drivers from fiddling
> with them? Something else?

The current problem with simple-fb is that the clock subsystem
contains code to automatically shut off clocks that aren't in use. A
similar problem exists for regulators. And I agree that code like that
makes sense.

Simplefb does not mark these items as being in use, so they get shut
off. So how can we communicate to these subsystems that these
clocks/regulators are actually in use by simple-fb? Simple-fb is
generic code and it does not know about specific devices or clocks or
regulators.

Uboot could individually mark each one.  But then how does uboot tell
the OS that a simple-fb has been set up? You could make a node like
'chosen/framebuffer'. But then how do you tell where the reserved
memory is? Making a <boot> node inside the specific device makes more
sense to me. That also makes it easy to determine what
clock/regulators apply.

Also note that things like the console are also vulnerable to this. If
I switch from a built-in serial driver over to a modprobe one, the
UART clocks will get disabled in the interval between the clk shut off
code and the loading of the module. This is the same window that makes
the framebuffer flicker during boot.  And generic ARM kernels modprobe
in all of their drivers.

>
>> Driver handoff is the OS's problem. Under Linux the device specific
>> drivers could soft-link to the boot,xxx code. After the device
>> specific driver is fully initialized it would tell the boot,xxx driver
>> to let go.
>
> I'm not sure I follow why we need the stub drivers at all. Is the idea
> to just have them hog resources until the real driver comes up?
>
>> As a side effect this will eliminate the need for kernel command line
>> parameters describing boot state. Like console="". Over time it might
>> even be able to pass a DHCP IP address from uboot into the kernel.
>
> We have a generic mechanism for communicating the MAC address of an
> ethernet adapter. I don't see a fundamental reason we can't add
> properties to communicate a DHCP lease and associated information. Is
> anyone looking into that?
>
> Thanks,
> Mark.



-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Generic communication of boot loader state to the OS

[Russell King - ARM Linux]

On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> As a side effect this will eliminate the need for kernel command line
> parameters describing boot state. Like console="". Over time it might
> even be able to pass a DHCP IP address from uboot into the kernel.

Err no.  Don't even think about that.  DHCP may be wonderful and all,
but there's a fundamental issue with it: entries time out unless they
are renewed.

Why is that a problem?  Well, take a DHCP server which hands out
dynamic addresses, and updates the DNS.  When the lease expires, it
tears down the DNS entry.

Now take a target booting using DHCP in uboot, which then mounts its
root NFS.  If it tries to startup a DHCP client, the first thing the
DHCP client does is to clean up the interface... resulting in it
killing the root NFS connection.  If that doesn't happen, then you
end up with a problem at shutdown, because DHCP clients always
deconfigure the interface when they're killed off - resulting in
"reboot" not being functional.

Here, I run exactly that setup, and I have found that ubuntu suffers
quite a bit from problems if you don't tell it to keep its fingers
off the ethernet device configuration when running root-NFS - and
believe me, when I'm working on something, I probably do several
tens of remote reboots of targets via "reboot" - I know I've done
about fifty today so far (many of them having to resort to the reset
button because the kernel seems to be locking up rather than rebooting
at the final stage.)

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: Generic communication of boot loader state to the OS

[jonsmirl-Re5JQEeQqe8AvxtiuMwx3w]

On Tue, Aug 26, 2014 at 1:16 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi Jon,
>
> On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>> New thread split off from the simple-framebuffer discussion....
>>
>> Is there a generic, underlying problem here that needs to be solved?
>> AFAIK no one has designed a general purpose mechanism for
>> communicating boot loader state to the OS. There is the existing
>> device tree <chosen> node but it is limited compared to what is
>> needed. Maybe we should step back and first design a good solution to
>> this basic problem. Then specific solutions for things like
>> framebuffers would fall out of the basic design.
>
> I think the fundamental problem here is unfortunately far too abstract
> for the general solution to be any more concrete. The solution to "we
> don't communicate boot state" is "we should communicate boot state".
>
> We can perhaps come up with general guidelines (for instance, the clock
> subsystem has assigned-* properties), but I don't think there's a
> one-size-fits-all solution.

I think it worth taking some time to consider if a one-size-fits-all
solution exists for the general issues of communicating between the
boot loader and the OS. Things are a lot better now, but I can
remember have 20K byte long kernel command lines in the past.  Some
random thoughts...

Do we even need a kernel command line any more?
Could EARLY_PRINTK be made automatic with cooperation from the bootloader?
Can we make it all the way from the boot loader to the GUI without
having the display flash from mode setting?
Can I not auto-negotiate network links speed twice (a slow process)?
Can 23 years of different solutions be collapsed into a general framework?

-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Generic communication of boot loader state to the OS

[jonsmirl-Re5JQEeQqe8AvxtiuMwx3w]

On Tue, Aug 26, 2014 at 2:28 PM, Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>> As a side effect this will eliminate the need for kernel command line
>> parameters describing boot state. Like console="". Over time it might
>> even be able to pass a DHCP IP address from uboot into the kernel.
>
> Err no.  Don't even think about that.  DHCP may be wonderful and all,
> but there's a fundamental issue with it: entries time out unless they
> are renewed.
>
> Why is that a problem?  Well, take a DHCP server which hands out
> dynamic addresses, and updates the DNS.  When the lease expires, it
> tears down the DNS entry.
>
> Now take a target booting using DHCP in uboot, which then mounts its
> root NFS.  If it tries to startup a DHCP client, the first thing the
> DHCP client does is to clean up the interface... resulting in it
> killing the root NFS connection.  If that doesn't happen, then you
> end up with a problem at shutdown, because DHCP clients always
> deconfigure the interface when they're killed off - resulting in
> "reboot" not being functional.

I run the same configuration  -  uboot in flash, tftp to load kernel,
nfs mount the root. And I do reboot fifty times a day too.  I just put
everything on static IPs to avoid problems.

Would this work if the DHCP client was notified that there already was
an IP lease in place?  It could remember that lease and then be
responsible for setting it into the interface and renewing it. Right
now there is no way to pass this information.

Doesn't the DHCP client do the wrong thing simply because it lacks the
info to do something better?

>
> Here, I run exactly that setup, and I have found that ubuntu suffers
> quite a bit from problems if you don't tell it to keep its fingers
> off the ethernet device configuration when running root-NFS - and
> believe me, when I'm working on something, I probably do several
> tens of remote reboots of targets via "reboot" - I know I've done
> about fifty today so far (many of them having to resort to the reset
> button because the kernel seems to be locking up rather than rebooting
> at the final stage.)
>
> --
> FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Generic communication of boot loader state to the OS

[Mark Rutland]

On Tue, Aug 26, 2014 at 07:31:09PM +0100, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> On Tue, Aug 26, 2014 at 1:16 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > Hi Jon,
> >
> > On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >> New thread split off from the simple-framebuffer discussion....
> >>
> >> Is there a generic, underlying problem here that needs to be solved?
> >> AFAIK no one has designed a general purpose mechanism for
> >> communicating boot loader state to the OS. There is the existing
> >> device tree <chosen> node but it is limited compared to what is
> >> needed. Maybe we should step back and first design a good solution to
> >> this basic problem. Then specific solutions for things like
> >> framebuffers would fall out of the basic design.
> >
> > I think the fundamental problem here is unfortunately far too abstract
> > for the general solution to be any more concrete. The solution to "we
> > don't communicate boot state" is "we should communicate boot state".
> >
> > We can perhaps come up with general guidelines (for instance, the clock
> > subsystem has assigned-* properties), but I don't think there's a
> > one-size-fits-all solution.
> 
> I think it worth taking some time to consider if a one-size-fits-all
> solution exists for the general issues of communicating between the
> boot loader and the OS. Things are a lot better now, but I can
> remember have 20K byte long kernel command lines in the past.  Some
> random thoughts...

As I mentioned, I think we can set general guidelines. Some information
is just going to be device-specific, so enforcing a particular format
for everything is going to get in the way. There's no reason there can't
be common conventions, however.

> Do we even need a kernel command line any more?

I quite like being able to override options for test purposes, but we
don't necessarily have to require a non-empty command line.

> Could EARLY_PRINTK be made automatic with cooperation from the bootloader?

I believe Rob Herring's earlycon patches can set up an earlycon based on
stdout-path.

> Can we make it all the way from the boot loader to the GUI without
> having the display flash from mode setting?

If we communicate the display mode and the configuration of the clocks,
regulators, and memory allocations, probably. We already have the basic
bindings for all of these, so I think the bulk of the work would be
convincing the subsystems to do interact in the right way.

> Can I not auto-negotiate network links speed twice (a slow process)?

Perhaps. It depends on what information your particular network
controller setup needs to pass along (perhaps nothing whatsoever).

> Can 23 years of different solutions be collapsed into a general framework?

I think the only common thing here is that something in a subsystem
needs to parse the DT early and act on it. We already have initcalls.

Thanks,
Mark.

Re: Generic communication of boot loader state to the OS

[Russell King - ARM Linux]

On Tue, Aug 26, 2014 at 02:39:45PM -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> On Tue, Aug 26, 2014 at 2:28 PM, Russell King - ARM Linux
> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> > On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >> As a side effect this will eliminate the need for kernel command line
> >> parameters describing boot state. Like console="". Over time it might
> >> even be able to pass a DHCP IP address from uboot into the kernel.
> >
> > Err no.  Don't even think about that.  DHCP may be wonderful and all,
> > but there's a fundamental issue with it: entries time out unless they
> > are renewed.
> >
> > Why is that a problem?  Well, take a DHCP server which hands out
> > dynamic addresses, and updates the DNS.  When the lease expires, it
> > tears down the DNS entry.
> >
> > Now take a target booting using DHCP in uboot, which then mounts its
> > root NFS.  If it tries to startup a DHCP client, the first thing the
> > DHCP client does is to clean up the interface... resulting in it
> > killing the root NFS connection.  If that doesn't happen, then you
> > end up with a problem at shutdown, because DHCP clients always
> > deconfigure the interface when they're killed off - resulting in
> > "reboot" not being functional.
> 
> I run the same configuration  -  uboot in flash, tftp to load kernel,
> nfs mount the root. And I do reboot fifty times a day too.  I just put
> everything on static IPs to avoid problems.
> 
> Would this work if the DHCP client was notified that there already was
> an IP lease in place?  It could remember that lease and then be
> responsible for setting it into the interface and renewing it. Right
> now there is no way to pass this information.
> 
> Doesn't the DHCP client do the wrong thing simply because it lacks the
> info to do something better?

It can get the already configured IP address if the kernel (or initramfs)
has already configured the interface - it's already available from the
interface itself.  So it's not that there's no way to pass this to DHCP,
it's that DHCP always starts out assuming that it's the new kid on the
block.

Solving that problem doesn't get away from the shutdown problem though.
You can partially avoid it by not having interfaces brought down, but
one of the things that distros commonly do is kill all processes during
shutdown... which kills the DHCP client, and then causes the interface
to be deconfigured... which then stalls the reboot operation because
suddenly the root-NFS server is no longer available... Gosh, why did
that happen I wonder...

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: Generic communication of boot loader state to the OS

[jonsmirl-Re5JQEeQqe8AvxtiuMwx3w]

On Tue, Aug 26, 2014 at 3:02 PM, Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Tue, Aug 26, 2014 at 02:39:45PM -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>> On Tue, Aug 26, 2014 at 2:28 PM, Russell King - ARM Linux
>> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
>> > On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>> >> As a side effect this will eliminate the need for kernel command line
>> >> parameters describing boot state. Like console="". Over time it might
>> >> even be able to pass a DHCP IP address from uboot into the kernel.
>> >
>> > Err no.  Don't even think about that.  DHCP may be wonderful and all,
>> > but there's a fundamental issue with it: entries time out unless they
>> > are renewed.
>> >
>> > Why is that a problem?  Well, take a DHCP server which hands out
>> > dynamic addresses, and updates the DNS.  When the lease expires, it
>> > tears down the DNS entry.
>> >
>> > Now take a target booting using DHCP in uboot, which then mounts its
>> > root NFS.  If it tries to startup a DHCP client, the first thing the
>> > DHCP client does is to clean up the interface... resulting in it
>> > killing the root NFS connection.  If that doesn't happen, then you
>> > end up with a problem at shutdown, because DHCP clients always
>> > deconfigure the interface when they're killed off - resulting in
>> > "reboot" not being functional.
>>
>> I run the same configuration  -  uboot in flash, tftp to load kernel,
>> nfs mount the root. And I do reboot fifty times a day too.  I just put
>> everything on static IPs to avoid problems.
>>
>> Would this work if the DHCP client was notified that there already was
>> an IP lease in place?  It could remember that lease and then be
>> responsible for setting it into the interface and renewing it. Right
>> now there is no way to pass this information.
>>
>> Doesn't the DHCP client do the wrong thing simply because it lacks the
>> info to do something better?
>
> It can get the already configured IP address if the kernel (or initramfs)
> has already configured the interface - it's already available from the
> interface itself.  So it's not that there's no way to pass this to DHCP,
> it's that DHCP always starts out assuming that it's the new kid on the
> block.
>
> Solving that problem doesn't get away from the shutdown problem though.
> You can partially avoid it by not having interfaces brought down, but
> one of the things that distros commonly do is kill all processes during
> shutdown... which kills the DHCP client, and then causes the interface
> to be deconfigured... which then stalls the reboot operation because
> suddenly the root-NFS server is no longer available... Gosh, why did
> that happen I wonder...

I wonder if DHCP client couldn't be replaced with a udev event. Set a
timer in the kernel for the length of the lease. Then generate a udev
event when it is ready to expire. Udev event runs an app that gets a
new lease.  Now there is no process to kill on reboot and everyone is
happy.



>
> --
> FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: Re: Generic communication of boot loader state to the OS

[Henrik Nordström]

tis 2014-08-26 klockan 16:50 -0400 skrev jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org:

> I wonder if DHCP client couldn't be replaced with a udev event. Set a
> timer in the kernel for the length of the lease. Then generate a udev
> event when it is ready to expire. Udev event runs an app that gets a
> new lease.  Now there is no process to kill on reboot and everyone is
> happy.

DHCP clients should release their IP back to the DHCP pool when no
longer in use and is why this is normally down on shutdown/reboot.
Special care is needed for doing this when your rootfs is on NFS, but
that's all an OS support issue in how to properly supporting NFS root,
not at all related to devicetree or bootloaders.

The question on communicating DHCP lease details between bootloader and
OS is partially valid for this discussion as an example of possible user
of such communication. It is not strictly required as we can have (and
do have) an initrd that requests a dhcp lease before kernel needs IP
running for NFS etc, but reusing the existing lease is faster (in the
range of seconds in many networks). There is however a lot of small
details in DHCP that may make that infeasible in the end, but those are
again all OS implementation details not related to how to communicate
existing lease information from bootloader to OS.

Regards
Henrik