[U-Boot] u-boot - raspberry pi

[dh at synoia.com]

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 at wwwdotorg.org>
 To: Simon Glass <sjg at chromium.org>; dh at synoia.com 
Cc: "u-boot at lists.denx.de" <u-boot at lists.denx.de>; Stephen Warren <swarren at 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 at 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.md

I haven't tried this yet, but it sounds good.