FW: xM Help

This needs a bit of clean-up, but does anyone care to comment on using these patches to enable testing the user button in u-boot?

0001-Changed-mmc-device-from-0-to-1.patch (2.37 KB)

0001-Created-new-u-boot-command-to-detect-status-of-USER.patch (2.86 KB)

This needs a bit of clean-up, but does anyone care to comment on using these
patches to enable testing the user button in u-boot?

Had a quick peek at it. My comments
- it is unclear what u-boot version this patch is against
- the code adds a function do_userbutton in common/cmd_boot.c
I strongly doubt it will be possible to get this patch in the mainline
(especially with code like omap_free_gpio(4); in it), so this will
remain an out-of-mainline patch that has to be maintained by someone
(or we cannot keep up with mainline u-boot). Suggest to move it to the
omap specific section of u-boot
- personally I am not too happy with magical numbers like 4. Why not
use a macro with an explanatory name.
- why tie the pressing of the button to the execution of boot.scr or
user.src. It would be much more flexible if in u-boot I can read the
value and act upon it. In that case a user could also decide to couple
a u-boot command sequence to a button press (e.g. use different
bootargs, boot from different device/partition/kernel etc etc). (one
might be able to do that in boot.scr but it is much more flexible if
one can do so in u-boot.

Best regards, Frans.

- why tie the pressing of the button to the execution of boot.scr or
user.src. It would be much more flexible if in u-boot I can read the
value and act upon it. In that case a user could also decide to couple
a u-boot command sequence to a button press (e.g. use different
bootargs, boot from different device/partition/kernel etc etc). (one
might be able to do that in boot.scr but it is much more flexible if
one can do so in u-boot.

That is exactly the way our patch for the Openmoko Beagle Hybrid [1]
works. We have added some private commands to U-Boot so that a
boot.scr can check if this or that button is pressed by adding an if-
statement to the boot.scr:

if led check 1 # AUX button
then
...
fi

This gives us the highest flexibility with lowest impact on mainline U-
Boot code. We even managed to add a "GUI menu" to choose boot options
(by a command to initialize DSS and set the frame buffer base address
to a memory region where we load different images from MMC). If you
want to look into the project:

[2]: http://projects.goldelico.com/p/gta04-uboot/
[3]: http://download.goldelico.com/ombeagle/trunk/boot.cmd

So I would propose to simply add a "check-user-button-state" command
that returns 0 or 1 to U-Boot which does the magic in boot.scr.

Nikolaus Schaller

[1]: http://wiki.openmoko.org/wiki/Openmoko_Beagle_Hybrid

This needs a bit of clean-up, but does anyone care to comment on using these
patches to enable testing the user button in u-boot?

Had a quick peek at it. My comments
- it is unclear what u-boot version this patch is against
- the code adds a function do_userbutton in common/cmd_boot.c
I strongly doubt it will be possible to get this patch in the mainline
(especially with code like omap_free_gpio(4); in it), so this will
remain an out-of-mainline patch that has to be maintained by someone
(or we cannot keep up with mainline u-boot). Suggest to move it to the
omap specific section of u-boot
- personally I am not too happy with magical numbers like 4. Why not
use a macro with an explanatory name.

Not much to comment on the above comments other than I agree.

- why tie the pressing of the button to the execution of boot.scr or
user.src. It would be much more flexible if in u-boot I can read the
value and act upon it. In that case a user could also decide to couple
a u-boot command sequence to a button press (e.g. use different
bootargs, boot from different device/partition/kernel etc etc). (one
might be able to do that in boot.scr but it is much more flexible if
one can do so in u-boot.

That is exactly the case. It is only the default environment that
would have this behavior of looking for boot.scr or user.scr. On the
BeagleBoard-xM, we don't have on-board NAND flash, so we'll be
depending on the boot.scr on the microSD card based on the default
environment bootcmd.

Within the boot.scr or user.scr, it would also be possible to read the
USER button and act upon it. The reason we have this is so that we
can make a u-boot.bin that will look for user.scr when the button is
pressed to load a ramdisk.gz image that is capable of being used for
editing the boot.scr in case you were editing boot.scr in-system and
produced a setting that no longer boots into a usable state. It is
just another recovery mechanism available directly within the system
without needing to go to another computer.

- why tie the pressing of the button to the execution of boot.scr or
user.src. It would be much more flexible if in u-boot I can read the
value and act upon it. In that case a user could also decide to couple
a u-boot command sequence to a button press (e.g. use different
bootargs, boot from different device/partition/kernel etc etc). (one
might be able to do that in boot.scr but it is much more flexible if
one can do so in u-boot.

That is exactly the way our patch for the Openmoko Beagle Hybrid [1]
works. We have added some private commands to U-Boot so that a
boot.scr can check if this or that button is pressed by adding an if-
statement to the boot.scr:

if led check 1 # AUX button

So, you put this in the LED command? That sounds like it could work.

then
...
fi

This gives us the highest flexibility with lowest impact on mainline U-
Boot code. We even managed to add a "GUI menu" to choose boot options
(by a command to initialize DSS and set the frame buffer base address
to a memory region where we load different images from MMC). If you
want to look into the project:

[2]: http://projects.goldelico.com/p/gta04-uboot/
[3]: http://download.goldelico.com/ombeagle/trunk/boot.cmd

I looked around a bit and didn't find the u-boot sources quickly. Can
you point me to the patches that apply your modifications to the LED
command?

This needs a bit of clean-up, but does anyone care to comment on using these
patches to enable testing the user button in u-boot?

Had a quick peek at it. My comments
- it is unclear what u-boot version this patch is against
- the code adds a function do_userbutton in common/cmd_boot.c
I strongly doubt it will be possible to get this patch in the mainline
(especially with code like omap_free_gpio(4); in it), so this will
remain an out-of-mainline patch that has to be maintained by someone
(or we cannot keep up with mainline u-boot). Suggest to move it to the
omap specific section of u-boot
- personally I am not too happy with magical numbers like 4. Why not
use a macro with an explanatory name.

Not much to comment on the above comments other than I agree.

- why tie the pressing of the button to the execution of boot.scr or
user.src. It would be much more flexible if in u-boot I can read the
value and act upon it. In that case a user could also decide to couple
a u-boot command sequence to a button press (e.g. use different
bootargs, boot from different device/partition/kernel etc etc). (one
might be able to do that in boot.scr but it is much more flexible if
one can do so in u-boot.

That is exactly the case. It is only the default environment that
would have this behavior of looking for boot.scr or user.scr. On the
BeagleBoard-xM, we don't have on-board NAND flash, so we'll be
depending on the boot.scr on the microSD card based on the default
environment bootcmd.

I don't fully understand the part of the default environment.
Does that mean that it is possible to override the action coupled to
the button.within u-boot ?

Within the boot.scr or user.scr, it would also be possible to read the
USER button and act upon it. The reason we have this is so that we
can make a u-boot.bin that will look for user.scr when the button is
pressed to load a ramdisk.gz image that is capable of being used for
editing the boot.scr in case you were editing boot.scr in-system and
produced a setting that no longer boots into a usable state. It is
just another recovery mechanism available directly within the system
without needing to go to another computer.

I understand that, but I think users would like to have the option to
associate functionality to the user button key without modifying a
.scr file.
E.g. if I want to bind booting from tftp/nfs to the user button I
would like to be able to set the ip address within u-boot, not in
boot.scr (or user.scr) as the latter cannot be modified by me while
booting (but require an additional trip to another machine).
BTW I do not object to a default where pressing the user key executes
a user.scr, but I would like to be able to override the default (which
could be if I could specify the action in u-boot).
(and if someone mucked up the u-boot env vars: resetenv or so will
reset them to the initial values.

One other smallish comment to the code: if it is intended to be
mainlined it should adhere to the u-boot coding guidelines (which are
actually the same as the linux' one, eg if and { should go on the same
line)

Frans