[PATCH 1/2] support netbooting on JS21 GA3 and older firmwares

[Scott Moser]

The patch below was originally submitted by Andrew Wray under subject
"Patch to allow netbooting with IBM JS21 GA3 firmware" [1].

I'm re-submitting it with the following description.

  modify of_net_open to add support for recent power openfirmware
  implementations.  This includes JS21 ("GA3" level), JS22, and power6
  hardware.  Newer firmware differs on how the following "load" command is
  handled
     <device>:,<file>
   Previous versions would do a bootp request to get the TCP/IP information
  and then tftp the my_file from the returned siaddr.  Newer versions will
  effectively ignore the '<file>', from the open command and simply download
  whatever file was listed in the bootp response.
 
    These changes break yaboot's of_net_open on networks where the bootp
  server is not the same system as the tftp server.  This is implemented
  by dhcpd's 'next-server' keyword.  This is because the older firmwares were
  really not capable of doing a tftp load.  Ie, the 'boot' command line:
    <device>:<siaddr>,<file>,<ciaddr>
    requires that <siaddr> to be running a bootp server, not simply a tftp
  server.  The above syntax works correctly with new firmwares.

  At the moment we do not expect firmware to change in the future.  In
  order to make network booting work on these systems these changes (or
  similar) will be needed.
--
[1] http://ozlabs.org/pipermail/yaboot-devel/2007-August/000156.html

diff --git a/include/prom.h b/include/prom.h
index f5ee88f..b48e230 100644
--- a/include/prom.h
+++ b/include/prom.h
@@ -154,5 +154,8 @@ struct bootp_packet {
 struct bootp_packet * prom_get_netinfo (void);
 char * prom_get_mac (struct bootp_packet * packet);
 char * prom_get_ip (struct bootp_packet * packet);
+char * prom_get_yiaddr (struct bootp_packet * packet);
+char * prom_get_siaddr (struct bootp_packet * packet);
+char * prom_get_giaddr (struct bootp_packet * packet);
 
 #endif
diff --git a/second/fs_of.c b/second/fs_of.c
index 76474ee..a9404f6 100644
--- a/second/fs_of.c
+++ b/second/fs_of.c
@@ -138,18 +138,29 @@ of_net_open(struct boot_file_t* file, const char* dev_name,
      static char buffer[1024];
      char               *filename;
      char               *p;
+     struct bootp_packet *packet;
 
      DEBUG_ENTER;
      DEBUG_OPEN;
 
+     packet = prom_get_netinfo();
+
      strncpy(buffer, dev_name, 768);
      if (file_name && strlen(file_name)) {
+  strcat(buffer, prom_get_siaddr(packet));
   strcat(buffer, ",");
   filename = strdup(file_name);
   for (p = filename; *p; p++)
        if (*p == '/')
     *p = '\\';
   strcat(buffer, filename);
+  strcat(buffer, ",");
+  strcat(buffer, prom_get_yiaddr(packet));
+  strcat(buffer, ",");
+  /* Hack required since giaddr not returned on some systems
+     and required to boot on those systems.  This should work
+     for the client and server on the same subnet. */
+  strcat(buffer, prom_get_siaddr(packet));
   free(filename);
      }
 
diff --git a/second/prom.c b/second/prom.c
index e9c5843..bd2451e 100644
--- a/second/prom.c
+++ b/second/prom.c
@@ -752,6 +752,78 @@ char * prom_get_ip (struct bootp_packet * packet)
 }
 
 /*
+ * prom_get_yiaddr()
+ * returns the ip addr of the client in dotted decimal format
+ */
+char * prom_get_yiaddr (struct bootp_packet * packet)
+{
+     char * conf_path;
+
+     if (!packet)
+        return NULL;
+
+     /* 15 chars in yiaddr + \0 */
+     conf_path = malloc(16);
+     if (!conf_path)
+         return NULL;
+     sprintf(conf_path, "%d.%d.%d.%d",
+         packet->yiaddr >> 24,
+         (packet->yiaddr << 8) >> 24,
+         (packet->yiaddr << 16) >> 24,
+         (packet->yiaddr << 24) >> 24);
+
+     return conf_path;
+}
+
+/*
+ * prom_get_siaddr()
+ * returns the ip addr of the server in dotted decimal format
+ */
+char * prom_get_siaddr (struct bootp_packet * packet)
+{
+     char * conf_path;
+
+     if (!packet)
+        return NULL;
+
+     /* 15 chars in siaddr + \0 */
+     conf_path = malloc(16);
+     if (!conf_path)
+         return NULL;
+     sprintf(conf_path, "%d.%d.%d.%d",
+         packet->siaddr >> 24,
+         (packet->siaddr << 8) >> 24,
+         (packet->siaddr << 16) >> 24,
+         (packet->siaddr << 24) >> 24);
+
+     return conf_path;
+}
+
+/*
+ * prom_get_giaddr()
+ * returns the ip addr of the gateway in dotted decimal format
+ */
+char * prom_get_giaddr (struct bootp_packet * packet)
+{
+     char * conf_path;
+
+     if (!packet)
+        return NULL;
+
+     /* 15 chars in giaddr + \0 */
+     conf_path = malloc(16);
+     if (!conf_path)
+         return NULL;
+     sprintf(conf_path, "%d.%d.%d.%d",
+         packet->giaddr >> 24,
+         (packet->giaddr << 8) >> 24,
+         (packet->giaddr << 16) >> 24,
+         (packet->giaddr << 24) >> 24);
+
+     return conf_path;
+}
+
+/*
  * Local variables:
  * c-file-style: "k&r"
  * c-basic-offset: 5

_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Doug Maxey-5]

On Fri, 05 Oct 2007 11:07:10 EDT, Scott Moser wrote:

> The patch below was originally submitted by Andrew Wray under subject
> "Patch to allow netbooting with IBM JS21 GA3 firmware" [1].
>
> I'm re-submitting it with the following description.
>
>   modify of_net_open to add support for recent power openfirmware
>   implementations.  This includes JS21 ("GA3" level), JS22, and power6
>   hardware.  Newer firmware differs on how the following "load" command is
>   handled
>      <device>:,<file>
>    Previous versions would do a bootp request to get the TCP/IP information
>   and then tftp the my_file from the returned siaddr.

This has never been true for IBM boxen, nothing new here.  Have you tested
any of this with the older apples that support yaboot?

> Newer versions will
>   effectively ignore the '<file>', from the open command and simply download
>   whatever file was listed in the bootp response.

This is still true.

>
>     These changes break yaboot's of_net_open on networks where the bootp
>   server is not the same system as the tftp server.  This is implemented
>   by dhcpd's 'next-server' keyword.

This is a limitation of IBM OFW.

> This is because the older firmwares were
>   really not capable of doing a tftp load.  Ie, the 'boot' command line:
>     <device>:<siaddr>,<file>,<ciaddr>
>     requires that <siaddr> to be running a bootp server, not simply a tftp
>   server.  The above syntax works correctly with new firmwares.

That is incorrect.  You have always had the ability to specify the
tftp server from the OFW command line.

Also, if you let the system boot without specifying (boot uses bootp),
the next-server is still ignored.  Just had this conversation with SFW
folks recently.  The bootp server is the bootp server.  :p

>
>   At the moment we do not expect firmware to change in the future.

I strongly disagree with that statement.  Not only will it change, but
we (being linux) may have little or no say in how or when.  The best
we can hope for is that some documentation will be provided on a
timely basis.  The effort is still proceeding at a glacial pace to get
the documentation out on the new IBM OFW network stack that supports
iSCSI booting.  Thats going on 18 months now.

More comments inline.

>   In
>   order to make network booting work on these systems these changes (or
>   similar) will be needed.
> --
> [1] http://ozlabs.org/pipermail/yaboot-devel/2007-August/000156.html
>
> diff --git a/include/prom.h b/include/prom.h
> index f5ee88f..b48e230 100644
> --- a/include/prom.h
> +++ b/include/prom.h
> @@ -154,5 +154,8 @@ struct bootp_packet {
>  struct bootp_packet * prom_get_netinfo (void);
>  char * prom_get_mac (struct bootp_packet * packet);
>  char * prom_get_ip (struct bootp_packet * packet);
> +char * prom_get_yiaddr (struct bootp_packet * packet);
> +char * prom_get_siaddr (struct bootp_packet * packet);
> +char * prom_get_giaddr (struct bootp_packet * packet);
>
>  #endif
> diff --git a/second/fs_of.c b/second/fs_of.c
> index 76474ee..a9404f6 100644
> --- a/second/fs_of.c
> +++ b/second/fs_of.c
> @@ -138,18 +138,29 @@ of_net_open(struct boot_file_t* file, const char* dev_name,
>       static char buffer[1024];
>       char               *filename;
>       char               *p;
> +     struct bootp_packet *packet;
>
>       DEBUG_ENTER;
>       DEBUG_OPEN;
>
> +     packet = prom_get_netinfo();

did it work?  for sure?

> +
>       strncpy(buffer, dev_name, 768);
>       if (file_name && strlen(file_name)) {
> +  strcat(buffer, prom_get_siaddr(packet));
>    strcat(buffer, ",");
>    filename = strdup(file_name);
>    for (p = filename; *p; p++)
>         if (*p == '/')
>      *p = '\\';
>    strcat(buffer, filename);
> +  strcat(buffer, ",");
> +  strcat(buffer, prom_get_yiaddr(packet));
> +  strcat(buffer, ",");
> +  /* Hack required since giaddr not returned on some systems
> +     and required to boot on those systems.  This should work
> +     for the client and server on the same subnet. */

You could set to zeros if on the same subnet.  That works from the
OFW CLI, so assume that it would work here.


> +  strcat(buffer, prom_get_siaddr(packet));

strncat never hurts.  :)

>    free(filename);
>       }
>
> diff --git a/second/prom.c b/second/prom.c
> index e9c5843..bd2451e 100644
> --- a/second/prom.c
> +++ b/second/prom.c
> @@ -752,6 +752,78 @@ char * prom_get_ip (struct bootp_packet * packet)
>  }
>
>  /*
> + * prom_get_yiaddr()
> + * returns the ip addr of the client in dotted decimal format
> + */
> +char * prom_get_yiaddr (struct bootp_packet * packet)
> +{
> +     char * conf_path;
> +
> +     if (!packet)
> +        return NULL;
> +
> +     /* 15 chars in yiaddr + \0 */
> +     conf_path = malloc(16);
> +     if (!conf_path)
> +         return NULL;
> +     sprintf(conf_path, "%d.%d.%d.%d",
> +         packet->yiaddr >> 24,
> +         (packet->yiaddr << 8) >> 24,
> +         (packet->yiaddr << 16) >> 24,
> +         (packet->yiaddr << 24) >> 24);

the binary to text transform could be factored out to a helper.

> +
> +     return conf_path;
> +}
> +
> +/*
> + * prom_get_siaddr()
> + * returns the ip addr of the server in dotted decimal format
> + */
> +char * prom_get_siaddr (struct bootp_packet * packet)
> +{
> +     char * conf_path;
> +
> +     if (!packet)
> +        return NULL;
> +
> +     /* 15 chars in siaddr + \0 */
> +     conf_path = malloc(16);
> +     if (!conf_path)
> +         return NULL;
> +     sprintf(conf_path, "%d.%d.%d.%d",
> +         packet->siaddr >> 24,
> +         (packet->siaddr << 8) >> 24,
> +         (packet->siaddr << 16) >> 24,
> +         (packet->siaddr << 24) >> 24);

ditto

> +
> +     return conf_path;
> +}
> +
> +/*
> + * prom_get_giaddr()
> + * returns the ip addr of the gateway in dotted decimal format
> + */
> +char * prom_get_giaddr (struct bootp_packet * packet)
> +{
> +     char * conf_path;
> +
> +     if (!packet)
> +        return NULL;
> +
> +     /* 15 chars in giaddr + \0 */
> +     conf_path = malloc(16);
> +     if (!conf_path)
> +         return NULL;
> +     sprintf(conf_path, "%d.%d.%d.%d",
> +         packet->giaddr >> 24,
> +         (packet->giaddr << 8) >> 24,
> +         (packet->giaddr << 16) >> 24,
> +         (packet->giaddr << 24) >> 24);

and again.

> +
> +     return conf_path;
> +}
> +
> +/*
>   * Local variables:
>   * c-file-style: "k&r"
>   * c-basic-offset: 5
>
> _______________________________________________
> Yaboot-devel mailing list
> Yaboot-devel@...
> https://ozlabs.org/mailman/listinfo/yaboot-devel
>

_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Scott Moser]

On Fri, 5 Oct 2007, Doug Maxey wrote:

>
> On Fri, 05 Oct 2007 11:07:10 EDT, Scott Moser wrote:
> > The patch below was originally submitted by Andrew Wray under subject
> > "Patch to allow netbooting with IBM JS21 GA3 firmware" [1].
> >
> > I'm re-submitting it with the following description.
> >
> >   modify of_net_open to add support for recent power openfirmware
> >   implementations.  This includes JS21 ("GA3" level), JS22, and power6
> >   hardware.  Newer firmware differs on how the following "load" command is
> >   handled
> >      <device>:,<file>
> >    Previous versions would do a bootp request to get the TCP/IP information
> >   and then tftp the my_file from the returned siaddr.
>
> This has never been true for IBM boxen, nothing new here.  Have you tested
> any of this with the older apples that support yaboot?

I have not tested with older apples.  I don't have access to any.
However, the second part of this patch that I posted keeps the old
behavior for older systems.

I guess I probably should have phrased that differently.  On older
systems:
   <device>:,file
resulted in 'file' being loaded from the bootp server (or, 'next-server'
if applicable).  This is the behavior that yaboot 1.3.14 relies on. In
newer systems:
   <device>:,file
results in a bootp request being done, and loading of whatever file is
present in the bootp response (not 'file').  The result, for most cases
in yaboot boot, is that when yaboot tries to load its config file, it
receives a yaboot binary.

> >     These changes break yaboot's of_net_open on networks where the bootp
> >   server is not the same system as the tftp server.  This is implemented
> >   by dhcpd's 'next-server' keyword.
>
> This is a limitation of IBM OFW.

IBM's OFW does support 'next-server'.  The setup I have here has a dhcpd
server that accepts all bootp requests and, for known ppc machines, has
a 'next-server' entry pointing to another system.  Old and new systems
can load the 'filename' that is returned in the bootp response from the
'next server'.  The following dhcpd configuration will work fine on
older hardware.  

group ppc {
  next-server tftp-server-host.somedomain.tld;
  host ppc-client {
    hardware ethernet 00:11:25:C0:25:E9;
    filename "yaboot";
  }
}

   Above, the host 'tftp-server-host' needs only to run a tftp server.
   ppc-client needs only to be configured via SMS menu for bootp
booting.
   With newer firmwares (GA3 on JS21), this configuration stops working,
as yaboot's attempt to get the config file with:
'<device>:,config-filename' returns the 'yaboot' file again.

> > This is because the older firmwares were
> >   really not capable of doing a tftp load.  Ie, the 'boot' command line:
> >     <device>:<siaddr>,<file>,<ciaddr>
> >     requires that <siaddr> to be running a bootp server, not simply a tftp
> >   server.  The above syntax works correctly with new firmwares.
>
> That is incorrect.  You have always had the ability to specify the
> tftp server from the OFW command line.

I'm confused as to what you're saying here.  The following definitely
does not work for me on older firmware, but do work on GA3 firmware.
The following is form a JS20:

0 > boot
/pci@8000000f8000000/pci@0/ethernet@1,1:192.168.79.239,yaboot,192.168.76.251,192.168.79.254
BOOTP: chosen-network-type = ethernet,auto,none,auto
BOOTP: server   IP =        192.168.79.239
BOOTP: requested filename = yaboot
BOOTP: client   IP =        192.168.76.251
BOOTP: client   HW addr =   0 d 60 1e e0 9b
BOOTP: gateway  IP =        192.168.79.254
BOOTP: device    /pci@8000000f8000000/pci@0/ethernet@1,1
BOOTP: loc-code  U8842.4TX.23GLF8K-P1-T7

icmp 3 : port unreachable
ERROR: icmp 3
BOOTP: BOOTP request fail: 0
<snip>
BOOTP ERROR: BOOTP request failed, QUIT

However, if I run a dhcpd server on 192.168.69.239, with the following
stanza, things start working:

group ppc {
   filename "/ppc/yaboot";
   allow bootp;
   host ibm-js20-05 {
      hardware ethernet 00:0d:60:1e:e0:9b;
      fixed-address ibm-js20-05.domain.com;
   }
}

That is what brought me to the conclusion that older firmwares do not
support pure tftp load, but require a bootp server running.  Similar
boot commands work without the tftp server on GA3 firmware for JS21.

> >   At the moment we do not expect firmware to change in the future.
>
> I strongly disagree with that statement.  Not only will it change, but
> we (being linux) may have little or no say in how or when.  The best
> we can hope for is that some documentation will be provided on a
> timely basis.  The effort is still proceeding at a glacial pace to get
> the documentation out on the new IBM OFW network stack that supports
> iSCSI booting.  Thats going on 18 months now.

I also disagree with my statement above as you read it (and as I wrote
it).  What I intended to say was :
   at the moment we do not expect firmware to return to the behavior of
   older firmware's where a request like '<device>:,filename' would load
   filename.

Ie, we don't expect firmware to change in a way that would make yaboot
1.3.14 work again.  Thus, we need some changes to yaboot so it continues
to function as a network bootloader on these newer firmwares.

> More comments inline.

The changes you suggested are reasonable and I can certainly make them
and resubmit.

Sorry I wasn't as clear as I could have been with my original post.

_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Benjamin Herrenschmidt]

Seeing patch flying on this list lately, I was wondering if there was
still an active maintainer for picking them up ? :-)

Cheers,
Ben.


_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Joel Schopp]

Word on the street is Paul Nasrat is still the man.  Paul, care to verify?

-Joel

Benjamin Herrenschmidt wrote:
> Seeing patch flying on this list lately, I was wondering if there was
> still an active maintainer for picking them up ? :-)
>
> Cheers,
> Ben.

_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Doug Maxey-5]

On Tue, 09 Oct 2007 15:58:34 CDT, Joel Schopp wrote:
> Word on the street is Paul Nasrat is still the man.  Paul, care to verify?
>


On Sept 20 pnasrat@... said:
> I'll try and dig up the details - I've just moved home so have
> intermittent b/w so you might not get a follow up to this until next
> week.

> -Joel
>
> Benjamin Herrenschmidt wrote:
> > Seeing patch flying on this list lately, I was wondering if there was
> > still an active maintainer for picking them up ? :-)
> >
> > Cheers,
> > Ben.
>
> _______________________________________________
> Yaboot-devel mailing list
> Yaboot-devel@...
> https://ozlabs.org/mailman/listinfo/yaboot-devel
>

_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Dustin Kirkland]

On Tue, 2007-10-09 at 14:45 +1000, Benjamin Herrenschmidt wrote:
> Seeing patch flying on this list lately, I was wondering if there was
> still an active maintainer for picking them up ? :-)

Paul Nasrat picked up my last patch set (boot a kernel just once) and
released yaboot 1.3.14 in May of 2007.


:-Dustin

_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Benjamin Herrenschmidt]

On Tue, 2007-10-09 at 16:13 -0500, Dustin Kirkland wrote:
> On Tue, 2007-10-09 at 14:45 +1000, Benjamin Herrenschmidt wrote:
> > Seeing patch flying on this list lately, I was wondering if there was
> > still an active maintainer for picking them up ? :-)
>
> Paul Nasrat picked up my last patch set (boot a kernel just once) and
> released yaboot 1.3.14 in May of 2007.

Ok, good. I've been told he wanted to get away from it, but maybe that's
unfounded rumors ... Paul ?

Cheers,
Ben.


_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel

[Paul Nasrat-2]

Dropped CC's last time ...

> Ok, good. I've been told he wanted to get away from it, but maybe that's
> unfounded rumors ... Paul ?

No, just moved house and had no internet for a bit, and been swamped
with life this month.

I'm hoping to spend some time on the weekend going over these patches
and setting up my test machines again (and sorting out my mail solution ...)

Paul
_______________________________________________
Yaboot-devel mailing list
Yaboot-devel@...
https://ozlabs.org/mailman/listinfo/yaboot-devel