[U-Boot] u-boot - raspberry pi
We have u-boot working on a raspberry pi, but need to append our kernel parms to those built by the firmware.
is there a version of u-boot for the pi 3, with this support, and some doc (the variable name for the firmware built kernel parms), a github link would be perfect.
We have an order of 400 PIs for a hospital in S America, and want to supply net boot, including kernels. Duncan Hare
714 931 7952
+Stephen
On 25 August 2016 at 22:12, dh@synoia.com wrote:
We have u-boot working on a raspberry pi, but need to append our kernel parms to those built by the firmware.
is there a version of u-boot for the pi 3, with this support, and some doc (the variable name for the firmware built kernel parms), a github link would be perfect.
We have an order of 400 PIs for a hospital in S America, and want to supply net boot, including kernels. Duncan Hare
714 931 7952 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 08/26/2016 08:39 AM, Simon Glass wrote:
+Stephen
On 25 August 2016 at 22:12, dh@synoia.com wrote:
We have u-boot working on a raspberry pi, but need to append our kernel parms to those built by the firmware.
is there a version of u-boot for the pi 3, with this support, and some doc (the variable name for the firmware built kernel parms), a github link would be perfect.
We have an order of 400 PIs for a hospital in S America, and want to supply net boot, including kernels. Duncan Hare
The current port of U-Boot to the Pi is intended to replace the operations that the binary FW performs rather than add to them. As such, there's currently no easy way to do what you need with U-Boot.
Two potential options exist:
1) Update U-Boot so that it saves the DTB pointer the binary FW passes at boot, parses this DTB, and exposes various properties (its address, the command-line embodied within it) as environment variables. U-Boot scripts could then use those environment variables as they see fit (e.g. ignore them to be compatible with current U-Boot behaviour, or set $bootargs by appending the extracted cmdline to whatever you want to add).
2) The binary FW recently grew a network boot feature itself. Perhaps this will fulfil your network boot needs by itself, so you don't need to use U-Boot.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net...
I haven't tried this yet, but it sounds good.
Stephen Thank you for your response.
The Rasbberry Pi approach, using the serial number imposes very difficult and expensive requirements on an enterprise. Model number or model number-rev number to identify the firmware kernel would be a better approach. If a PI does not work, that is it does not have a directory in the file service, the serial number needs to be visible on an unpowered machine. If the serial number is burnt into the silicon, or NVRAM on the board, how does the use access the serial number when on the phone to the help desk? Silkscreen on the board is a bad idea. Now the user has to open the case. Labels which peel off do not help, inconsistencies happen.
We believe the serial number based solution does not scale, managing the boot directories for 500 or 1,000 people would create a new industry by itself.
We should not confuse asset management with version management. Where do we raise this concern? Thanks Duncan Hare
714 931 7952
From: Stephen Warren swarren@wwwdotorg.org To: Simon Glass sjg@chromium.org; dh@synoia.com Cc: "u-boot@lists.denx.de" u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Sent: Friday, August 26, 2016 9:00 AM Subject: Re: [U-Boot] u-boot - raspberry pi
On 08/26/2016 08:39 AM, Simon Glass wrote:
+Stephen
On 25 August 2016 at 22:12, dh@synoia.com wrote:
We have u-boot working on a raspberry pi, but need to append our kernel parms to those built by the firmware.
is there a version of u-boot for the pi 3, with this support, and some doc (the variable name for the firmware built kernel parms), a github link would be perfect.
We have an order of 400 PIs for a hospital in S America, and want to supply net boot, including kernels. Duncan Hare
The current port of U-Boot to the Pi is intended to replace the operations that the binary FW performs rather than add to them. As such, there's currently no easy way to do what you need with U-Boot.
Two potential options exist:
1) Update U-Boot so that it saves the DTB pointer the binary FW passes at boot, parses this DTB, and exposes various properties (its address, the command-line embodied within it) as environment variables. U-Boot scripts could then use those environment variables as they see fit (e.g. ignore them to be compatible with current U-Boot behaviour, or set $bootargs by appending the extracted cmdline to whatever you want to add).
2) The binary FW recently grew a network boot feature itself. Perhaps this will fulfil your network boot needs by itself, so you don't need to use U-Boot.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net...
I haven't tried this yet, but it sounds good.
On 08/26/2016 10:51 AM, dh@synoia.com wrote:
Stephen
Thank you for your response.
The Rasbberry Pi approach, using the serial number imposes very difficult and expensive requirements on an enterprise.
I assume you're talking about the Raspberry Pi binary FW?
I haven't tried that yet as I mentioned, but my reading of the link I quoted before is that the serial number is included in the TFTP filename on the first attempt, and if no serial-number-specific file is found, the FW falls back to a generic filename that doesn't include the serial number. I think this addresses your concerns.
Model number or model number-rev number to identify the firmware kernel would be a better approach.
At least when booting from an SD card, the binary FW already optionally supports a different filename for the kernel based on the model of the Pi; kernel.img vs kernel7.img vs. kernel8-32.img vs. kernel8.img IIRC. Also, there's a config.txt syntax that allows certain settings to be activated based on the model of the Pi that's interpreting it. Presumably (and this is an assumption on my part) the TFTP boot mode works the same way.
If a PI does not work, that is it does not have a directory in the file service, the serial number needs to be visible on an unpowered machine. If the serial number is burnt into the silicon, or NVRAM on the board, how does the use access the serial number when on the phone to the help desk?
Silkscreen on the board is a bad idea. Now the user has to open the case. Labels which peel off do not help, inconsistencies happen.
We believe the serial number based solution does not scale, managing the boot directories for 500 or 1,000 people would create a new industry by itself.
We should not confuse asset management with version management.
Where do we raise this concern?
The Pi's binary FW is provided by the Raspberry Pi Foundation. You'd need to contact them for questions about it. You could try the Pi web forums; I know at least some people from the Foundation are active there and do answer questions (https://www.raspberrypi.org/forums/), or if that doesn't work out perhaps try contacting them directly; there's a "contact us" page on their website.
Thanks Duncan Hare
714 931 7952
*From:* Stephen Warren swarren@wwwdotorg.org *To:* Simon Glass sjg@chromium.org; dh@synoia.com *Cc:* "u-boot@lists.denx.de" u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com *Sent:* Friday, August 26, 2016 9:00 AM *Subject:* Re: [U-Boot] u-boot - raspberry pi
On 08/26/2016 08:39 AM, Simon Glass wrote:
+Stephen
On 25 August 2016 at 22:12, <dh@synoia.com mailto:dh@synoia.com> wrote:
We have u-boot working on a raspberry pi, but need to append our kernel parms to those built by the firmware.
is there a version of u-boot for the pi 3, with this support, and
some doc
(the variable name for the firmware built kernel parms), a github
link would
be perfect.
We have an order of 400 PIs for a hospital in S America, and want to
supply
net boot, including kernels. Duncan Hare
The current port of U-Boot to the Pi is intended to replace the operations that the binary FW performs rather than add to them. As such, there's currently no easy way to do what you need with U-Boot.
Two potential options exist:
- Update U-Boot so that it saves the DTB pointer the binary FW passes
at boot, parses this DTB, and exposes various properties (its address, the command-line embodied within it) as environment variables. U-Boot scripts could then use those environment variables as they see fit (e.g. ignore them to be compatible with current U-Boot behaviour, or set $bootargs by appending the extracted cmdline to whatever you want to add).
- The binary FW recently grew a network boot feature itself. Perhaps
this will fulfil your network boot needs by itself, so you don't need to use U-Boot.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net...
I haven't tried this yet, but it sounds good.
Thanks for the response. We like what you do with u-boot, we believe it is a better solution.
We've reviewed the PI netboot project and have come to the conclusion that even with modifications it will not provide the flexibility of u-boot, due to the proprietary nature of the PI firmware.
With the current PI implementation we have to configure the hardware on each and every PI, and cannot ship them and the sd card to a customer and have them installed. There is the extra step of configuring the hardware. After configuring the hardware a customer has the potential of having two identical devices which work differently, non-netboot and netboot, with no visible way to tell the difference. Back to what it would take for u-boot to fill this need? The u-boot portion of the kernel parms needs to be appended to the firmware portion of the kernel pams which are in the directory:
/proc/device-tree/chosen/bootargs where device-tree is a link to /sys/firmware/devicetree/base it appears the parsing requirement may be limited, although I do not know how these files are written, by firmware or by the kernel. How can we get your help? Thanks
Duncan Hare
714 931 7952
From: Stephen Warren swarren@wwwdotorg.org To: Simon Glass sjg@chromium.org; dh@synoia.com Cc: "u-boot@lists.denx.de" u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Sent: Friday, August 26, 2016 9:00 AM Subject: Re: [U-Boot] u-boot - raspberry pi
On 08/26/2016 08:39 AM, Simon Glass wrote:
+Stephen
On 25 August 2016 at 22:12, dh@synoia.com wrote:
We have u-boot working on a raspberry pi, but need to append our kernel parms to those built by the firmware.
is there a version of u-boot for the pi 3, with this support, and some doc (the variable name for the firmware built kernel parms), a github link would be perfect.
We have an order of 400 PIs for a hospital in S America, and want to supply net boot, including kernels. Duncan Hare
The current port of U-Boot to the Pi is intended to replace the operations that the binary FW performs rather than add to them. As such, there's currently no easy way to do what you need with U-Boot.
Two potential options exist:
1) Update U-Boot so that it saves the DTB pointer the binary FW passes at boot, parses this DTB, and exposes various properties (its address, the command-line embodied within it) as environment variables. U-Boot scripts could then use those environment variables as they see fit (e.g. ignore them to be compatible with current U-Boot behaviour, or set $bootargs by appending the extracted cmdline to whatever you want to add).
2) The binary FW recently grew a network boot feature itself. Perhaps this will fulfil your network boot needs by itself, so you don't need to use U-Boot.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net...
I haven't tried this yet, but it sounds good.
participants (3)
-
dh＠synoia.com -
Simon Glass -
Stephen Warren