Add four main boot methods to developer build

Add four main boot methods to developer build

This adds DHCP/NFS boot, USB key/NFS boot, USB boot and MMC boot to the
developer build via easy-to-use commands. To cope with the DHCP server
providing less than useful data, we allow configuration of tfpserverip
and nfsserverip.

To allow users to share a single tftp and NFS server, we append the user,
board and serial number to tftpboot and NFS filenames.

The developer build progresses through dhcp, keynfs, usb and mmc boot in
order until a kernel is found.

BUG=chromium-os:9574
TEST=build U-Boot for developer and try: usb start, run dhcp_boot,
run keynfs_boot, run usb_boot, run mmc_boot. All should boot to a
working system on Seaboard.

Change-Id: I452b7df0fcf5ab204017d5d38873ae1a4e6751d5

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=5197178

[sjg, 2011-02-15 21:45:33]

This enables useful booting modes in U-Boot. Also please take a look at
documentation here if you have time:

https://sites.google.com/a/chromium.org/dev/network-based-development

[robotboy, 2011-02-17 17:51:45]

LGTM, with addition of developer boot config for all boards.

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/teg...
File include/configs/chromeos/tegra2/seaboard/developer.h (right):

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/teg...
include/configs/chromeos/tegra2/seaboard/developer.h:26: "run mmc_boot"
Please add this for all of the boards?

[vb, 2011-02-17 18:00:20]

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
File include/configs/chromeos/developer.h (right):

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:80: #define CONFIG_IPADDR		10.0.0.2
why is this default setting required? You mention some DHCP server problems
without much elaborating, but giving out ip addreses/masks/dns/gateway configs
are very basic features of pretty much any DHCP server.

It is going to be a mess when several targets on the same network try using the
default IP config.

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:91: #define
CONFIG_ROOTPATH		"/export/nfsroot-${user}-${board}-${serial#}"
how about pulling these from build environment?

[sjg, 2011-02-17 18:55:47]

I have added the bootcmd to the shared Tegra2 developer.h file.

Re the need for ignoring the DHCP's serverip, etc. perhaps I should explain this
more in the online docs? I don't like it either.

PTAL thanks

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
File include/configs/chromeos/developer.h (right):

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:80: #define CONFIG_IPADDR		10.0.0.2
On 2011/02/17 18:00:20, vb wrote:
> why is this default setting required? You mention some DHCP server problems
> without much elaborating, but giving out ip addreses/masks/dns/gateway configs
> are very basic features of pretty much any DHCP server.
> 
> It is going to be a mess when several targets on the same network try using
the
> default IP config.

The problem is not DHCP server support, but access to it. For example at many
companies it is difficult to get the DHCP server to do what we want. It can
provide an IP address but everything else it sends is bogus.

I agree this is horrible, but we do have to work in this situation.

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:91: #define
CONFIG_ROOTPATH		"/export/nfsroot-${user}-${board}-${serial#}"
On 2011/02/17 18:00:20, vb wrote:
> how about pulling these from build environment? 

Can you explain that, please? Not sure what you mean. I am wanting a standard
format for this root path which serve multiple users at a site.

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/teg...
File include/configs/chromeos/tegra2/seaboard/developer.h (right):

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/teg...
include/configs/chromeos/tegra2/seaboard/developer.h:26: "run mmc_boot"
On 2011/02/17 17:51:45, robotboy wrote:
> Please add this for all of the boards?

I will move it to tegra2/developer.h, as thinking about it this should work fine
on all the boards. Of course it should be tested.

[vb, 2011-02-17 19:07:24]

I am not insisting on these changes, will leave them to your/other reviewer's
discretion.

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
File include/configs/chromeos/developer.h (right):

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:80: #define CONFIG_IPADDR		10.0.0.2
On 2011/02/17 18:55:47, sjg wrote:
> On 2011/02/17 18:00:20, vb wrote:
> > why is this default setting required? You mention some DHCP server problems
> > without much elaborating, but giving out ip addreses/masks/dns/gateway
configs
> > are very basic features of pretty much any DHCP server.
> > 
> > It is going to be a mess when several targets on the same network try using
> the
> > default IP config.
> 
> The problem is not DHCP server support, but access to it. For example at many
> companies it is difficult to get the DHCP server to do what we want. It can
> provide an IP address but everything else it sends is bogus.
> 
> I agree this is horrible, but we do have to work in this situation.

I am almost splitting hairs here, but it could be a config flag for places where
the DHCP server is so deficient, all others should just work without any static
config. It sure would work just fine here.

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:91: #define
CONFIG_ROOTPATH		"/export/nfsroot-${user}-${board}-${serial#}"
On 2011/02/17 18:55:47, sjg wrote:
> On 2011/02/17 18:00:20, vb wrote:
> > how about pulling these from build environment? 
> 
> Can you explain that, please? Not sure what you mean. I am wanting a standard
> format for this root path which serve multiple users at a site.

What I mean to say is that ${user} could be ${USER} from the build environment
and ${board} could be CONFIG_IMAGE_NAME generated by mkconfig. This way even a
default env would point at a specific directory.
 
Of course it should be possible to overwrite these with explicit environment
settings.

[sjg, 2011-02-17 19:35:51]

Here are my thoughts. Please let me know - thanks, Simon

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
File include/configs/chromeos/developer.h (right):

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:80: #define CONFIG_IPADDR		10.0.0.2
On 2011/02/17 19:07:24, vb wrote:
> On 2011/02/17 18:55:47, sjg wrote:
> > On 2011/02/17 18:00:20, vb wrote:
> > > why is this default setting required? You mention some DHCP server
problems
> > > without much elaborating, but giving out ip addreses/masks/dns/gateway
> configs
> > > are very basic features of pretty much any DHCP server.
> > > 
> > > It is going to be a mess when several targets on the same network try
using
> > the
> > > default IP config.
> > 
> > The problem is not DHCP server support, but access to it. For example at
many
> > companies it is difficult to get the DHCP server to do what we want. It can
> > provide an IP address but everything else it sends is bogus.
> > 
> > I agree this is horrible, but we do have to work in this situation.
> 
> I am almost splitting hairs here, but it could be a config flag for places
where
> the DHCP server is so deficient, all others should just work without any
static
> config. It sure would work just fine here.

Sadly it doesn't work here.

It is pretty common for a DHCP server to be set up for pxelinux for example. In
any case we typically want our local workstation to be the tfto and NFS server,
which the DHCP will not know about.

http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
include/configs/chromeos/developer.h:91: #define
CONFIG_ROOTPATH		"/export/nfsroot-${user}-${board}-${serial#}"
On 2011/02/17 19:07:24, vb wrote:
> On 2011/02/17 18:55:47, sjg wrote:
> > On 2011/02/17 18:00:20, vb wrote:
> > > how about pulling these from build environment? 
> > 
> > Can you explain that, please? Not sure what you mean. I am wanting a
standard
> > format for this root path which serve multiple users at a site.
> 
> What I mean to say is that ${user} could be ${USER} from the build environment
> and ${board} could be CONFIG_IMAGE_NAME generated by mkconfig. This way even a
> default env would point at a specific directory.
>  
> Of course it should be possible to overwrite these with explicit environment
> settings.

OK I see. I think this is a good idea. However U-Boot doesn't have USER or BOARD
in its config - CONFIG_IMAGE_NAME is 'chromeos/tegra2/seaboard/developer' which
is not suitable as a tftp filename (we just want 'seaboard'.

Do you want to add these things to U-Boot's mkconfig? If so I am happy to come
back later and move to using it. But I am a little concerned about what upstream
might think.

[vb, 2011-02-17 20:21:59]

LGTM

Simon, these are good points, this definitely could be checked in and
then amended as we start using it,

cheers,
/v


On Thu, Feb 17, 2011 at 11:35 AM,  <sjg@chromium.org> wrote:
> Here are my thoughts. Please let me know - thanks, Simon
>
>
>
>
http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
> File include/configs/chromeos/developer.h (right):
>
>
http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
> include/configs/chromeos/developer.h:80: #define CONFIG_IPADDR
>  10.0.0.2
> On 2011/02/17 19:07:24, vb wrote:
>>
>> On 2011/02/17 18:55:47, sjg wrote:
>> > On 2011/02/17 18:00:20, vb wrote:
>> > > why is this default setting required? You mention some DHCP server
>
> problems
>>
>> > > without much elaborating, but giving out ip
>
> addreses/masks/dns/gateway
>>
>> configs
>> > > are very basic features of pretty much any DHCP server.
>> > >
>> > > It is going to be a mess when several targets on the same network
>
> try using
>>
>> > the
>> > > default IP config.
>> >
>> > The problem is not DHCP server support, but access to it. For
>
> example at many
>>
>> > companies it is difficult to get the DHCP server to do what we want.
>
> It can
>>
>> > provide an IP address but everything else it sends is bogus.
>> >
>> > I agree this is horrible, but we do have to work in this situation.
>
>> I am almost splitting hairs here, but it could be a config flag for
>
> places where
>>
>> the DHCP server is so deficient, all others should just work without
>
> any static
>>
>> config. It sure would work just fine here.
>
> Sadly it doesn't work here.
>
> It is pretty common for a DHCP server to be set up for pxelinux for
> example. In any case we typically want our local workstation to be the
> tfto and NFS server, which the DHCP will not know about.
>
>
http://codereview.chromium.org/6480056/diff/7002/include/configs/chromeos/dev...
> include/configs/chromeos/developer.h:91: #define
> CONFIG_ROOTPATH         "/export/nfsroot-${user}-${board}-${serial#}"
> On 2011/02/17 19:07:24, vb wrote:
>>
>> On 2011/02/17 18:55:47, sjg wrote:
>> > On 2011/02/17 18:00:20, vb wrote:
>> > > how about pulling these from build environment?
>> >
>> > Can you explain that, please? Not sure what you mean. I am wanting a
>
> standard
>>
>> > format for this root path which serve multiple users at a site.
>
>> What I mean to say is that ${user} could be ${USER} from the build
>
> environment
>>
>> and ${board} could be CONFIG_IMAGE_NAME generated by mkconfig. This
>
> way even a
>>
>> default env would point at a specific directory.
>
>> Of course it should be possible to overwrite these with explicit
>
> environment
>>
>> settings.
>
> OK I see. I think this is a good idea. However U-Boot doesn't have USER
> or BOARD in its config - CONFIG_IMAGE_NAME is
> 'chromeos/tegra2/seaboard/developer' which is not suitable as a tftp
> filename (we just want 'seaboard'.
>
> Do you want to add these things to U-Boot's mkconfig? If so I am happy
> to come back later and move to using it. But I am a little concerned
> about what upstream might think.
>
> http://codereview.chromium.org/6480056/
>