From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] config_distro_defaults.h: add CONFIG_API
Date: Sat, 20 Sep 2014 22:02:58 +0200 [thread overview]
Message-ID: <541DDD72.5060006@myspectrum.nl> (raw)
In-Reply-To: <20140823174720.GI19374@bill-the-cat>
Hello Tom,
On 23-08-14 19:47, Tom Rini wrote:
> On Sun, Aug 10, 2014 at 12:30:56AM +0200, Jeroen Hofstee wrote:
>
>> Grub, FreeBSD ubldr, vxworks etc depend on the API
>>
>> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
ok, lets start with I hope what I hope config_distro_defaults is.
At the moment, if you buy a demo board and try to run a custom
image on it, chances are big it won't boot. Either because it
searches for a wrong file, commands are not supported, they have
different syntax, different image formats etc. It is not uncommon
that I need to update u-boot before I can run a simple custom image.
It would of course be a lot better if you can stick an image in a demo
board, which actually boots and even better optionally ask you what
to boot. And I am in the impression / hope config_distro_defaults is
for that purpose. Not the smallest / fastest u-boot, but one which can
actually boot different distro's, images, demos etc. (or at least an
attempt to do so). For completeness, this already holds for linux
distro's / images / buildtools.
The typical bootpath for FreeBSD images is:
[something] -> loader[1] -> FreeBSD
In case of u-boot "something" is u-boot and loader is ubldr (which is
loader to talk with u-boot by its API). It would be nice if this just
worked without modifying u-boot, as the image might be in nand etc.
> So I'm not 100% sold on this. A while back (it's in the archives) we
> had said no to CONFIG_API. Grub wasn't a good use-case
I couldn't find a good reason why grub is not an use-case.
(besides some complaining and no-funding)
> (esp since we're handling extlinux.conf files),
I am still in the dark with respect to extlinux.conf. There is no
documentation nor users for it in u-boot it seems. But even if
an FreeBSD boot would use a FreeBSD.conf or similiar it would
still need CONFIG_API to work correctly.
> VxWorks is bootm/bootelf.
grep said:
/* Boot FreeBSD/vxWorks from an ELF image */
#if defined(CONFIG_ZYNQ_BOOT_FREEBSD)
# define CONFIG_API
# define CONFIG_CMD_ELF
# define CONFIG_SYS_MMC_MAX_DEVICE 1
#endif
hence I assumed it needs the api as well.
>
> I am open to hearing how/why we need this for ubldr.
>
ublr depends on a u-boot with CONFIG_API enabled. It
won't work otherwise.
[2] contains some background about the boot process from
u-boot.
Regards,
Jeroen
[1] https://www.freebsd.org/cgi/man.cgi?loader(8)
[2]
http://www.bsdcan.org/2008/schedule/attachments/49_2008_uboot_freebsd.pdf
prev parent reply other threads:[~2014-09-20 20:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-09 22:30 [U-Boot] Add CONFIG_API to config_distribution Jeroen Hofstee
2014-08-09 22:30 ` [U-Boot] [PATCH 1/2] api: fix build without CMD_NET support Jeroen Hofstee
2014-08-23 12:42 ` [U-Boot] [U-Boot,1/2] " Tom Rini
2014-08-09 22:30 ` [U-Boot] [PATCH 2/2] config_distro_defaults.h: add CONFIG_API Jeroen Hofstee
2014-08-23 17:47 ` Tom Rini
2014-09-20 20:02 ` Jeroen Hofstee [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541DDD72.5060006@myspectrum.nl \
--to=jeroen@myspectrum.nl \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.