On Mon, 5 Aug 2013 16:25:45 -0400
Tom Rini <tr...@ti.com> wrote:
> On Mon, Aug 05, 2013 at 03:11:20PM -0500, Dennis Gilmore wrote:
> > On Mon, 5 Aug 2013 15:01:32 -0400
> > Tom Rini <tr...@ti.com> wrote:
> >
> > > On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
> [snip]
> > > > bootz and raw initrd support. not having to wrap kernels and
> > > > initrds really is a must. raw initrd support means that its
> > > > much simpler for a user to rebuild an initramfs if needed and
> > > > bootz means we do not need to worry about making sure that we
> > > > specify the correct addresses to load the kernel to when
> > > > calling mkimage.
> > >
> > > bootz is fine, raw initrd is fine. I would say that "updating the
> > > initramfs" is done by the distro scripts anyhow and not by hand
> > > from memory.
> > for the most part yes, its built at rpm install time. sometimes a
> > user decides to rebuild for different reasons.
>
> Right. So, lets me ask. In .deb-based land, I build my own kernels,
> and yelling cursing and screaming at the pains of doing things by
> hand, I use the 'deb-pkg' target in the kernel as that hooks into all
> the right things and I stop having to ^R/^O my history to not break my
> system (or look at my own script or whatever). What's it like in
> Fedora land, with initramfses? Do users do make
> bzImage/modules/install in the kernel or expect to use rpm-pkg to get
> something that hooks in just right?
generally we expect users to just do a yum update and the new kernel is
automatically installed and a new initramfs is made for the kernel.
they would run dracut to make a new initramfs if for instance they hit
a systemd bug and needed to get the newer systemd binaries into the
initramfs or in the case of when we dir the usr move feature and
moved /lib /bin and /sbin into /usr the user needed to rebuild the
initramfs including the module to do the conversion process.
> > > > when it comes to memory addressing a distro and user shouldn't
> > > > need to know anything. Ideally u-boot will auto allocate
> > > > addresses based on the size of loaded objects. starting with a
> > > > base address internal to u-boot you load a kernel, when loading
> > > > an initramfs u-boot automatically calculates an address that
> > > > ensures it does not overlap with the kernel. same for a fdt if
> > > > loaded. I say auto calculated because what we think today will
> > > > be enough room may not be tomorrow, dynamically calculating
> > > > gives the flexibility for whatever may come.
> > >
> > > Well, how does this happen on x86, specifically for dealing with
> > > the kernel?
> > I'm not entirely sure dynamically assigned may not be feasible. just
> > trying to avoid unexpected boot failure in the future because we
> > didnt make sure there was enough room for something.
>
> Well, this is an important thing. How does this work, or what are the
> limits on x86? If someone can go dig up the maximum uncompressed
> kernel size before grub/syslinux/whathaveyou start stomping on
> ramdisks, we can document that in whatever comes out of this saying
> that one must (using spec language) make sure there's $X between the
> kernel and ramdisk load addrs (and perhaps even X+Y so that we can
> place the device tree in not-going-to-end-up-in-CONFIG_HIGHMEM-area).
Sure, ill see what I can find out.
> > > > fdt will be automatically loaded and provided fedora ships dtbs
> > > > in /boot/dtb-<kernelver>/ I am not sure where other distros
> > > > provide them, however u-boot should automatically load dtb and
> > > > provide access to a fdt in a ${fdt_addr} variable that can be
> > > > used by pxe_cmd but still allows the user to specify their own
> > > > in extlinux.conf if desired.
> > >
> > > I know Ubuntu shoves them under /lib, so this is an area where the
> > > distro-policy side of things will have to do some of the work.
> > > U-Boot can say what the base-name is, but we need to be given the
> > > directory path. I would also suggest at first that we don't want
> > > the user providing us memory locations to write
> > > this/that/something else to.
> >
> > I totally agree distros need to come together here and agree on
> > something like we did with the hardware floating point linker
> > location. and memory locations need to be not provided.
> >
> > > > ideally the devicetree files need to be decoupled from the
> > > > kernel, along the lines of what is being discussed in the
> > > > kernel now[2].
> > >
> > > Ideally, yes. And for everyones sake I hope that when this does
> > > happen, some thought is given about how vendors should store
> > > things on the device.
> >
> > > > Distros should agree on a single location for the dtbs to be
> > > > placed. /boot/dtb/ or /boot/dtbs/ are probably good locations.
> > > > u-boot can then look in the path with and without /boot
> > >
> > > Yes, this is something the distros need to have a chat about and
> > > coordinate on.
> > >
> > > > output and input should happen on all possible devices and not
> > > > just the serial console. If a user has a trimslice with only a
> > > > HDMI monitor and usb keyboard they should be able to see the
> > > > menu listing their possible kernels and be able to choose which
> > > > one they want to boot.
> > >
> > > Sure, I believe this works today, for some values of boards with
> > > supported displays and USB keyboards.
> > >
> > > > longer term being able to edit the boot arguments should also
> > > > be an option with the menu functionality.
> > >
> > > Sure.
> > >
> > > >
> > > > """
> > > > # extlinux.conf generated by anaconda
> > > >
> > > > ui menu.c32
> > > >
> > > > menu autoboot Welcome to Fedora. Automatic boot in # second{,s}.
> > > > Press a key for options. menu title Fedora Boot Options.
> > > > menu hidden
> > > >
> > > > timeout 60
> > > > #totaltimeout 9000
> > > >
> > > >
> > > > label Fedora (3.9.9-302.fc19.armv7hl) 19 (Schr??dinger???s Cat)
> > > > kernel /vmlinuz-3.9.9-302.fc19.armv7hl
> > > > append console=ttyAMA0,115200
> > > > root=UUID=04f8c4be-2890-4d26-bb79-e5555060a142 ro rhgb quiet
> > > > LANG=en_US.UTF-8 initrd /initramfs-3.9.9-302.fc19.armv7hl.img
> > > >
> > > > label Fedora (3.9.4-301.fc19.armv7hl) 19 (Schr??dinger???s Cat)
> > > > kernel /vmlinuz-3.9.4-301.fc19.armv7hl
> > > > append console=ttyAMA0,115200
> > > > root=UUID=04f8c4be-2890-4d26-bb79-e5555060a142 ro rhgb quiet
> > > > LANG=en_US.UTF-8 initrd /initramfs-3.9.4-301.fc19.armv7hl.img
> > > > """ the above is an example of a extlinux.conf file on a fedora
> > > > 19 system that works with the u-boot as shipped by calxeda on
> > > > thier highbank energy cards. some of the valid extlinux options
> > > > written out by anaconda cause noise on ARM as they are not
> > > > implemented longer term it would be good to deal with them
> > > > correctly. """
> > > > Ignoring unknown command: ui
> > > > Ignoring malformed menu command: autoboot
> > > > Ignoring malformed menu command: hidden
> > > > Fedora Boot Options.
> > > > 1: Fedora (3.9.9-302.fc19.armv7hl) 19 (Schr??dinger???s
> > > > Cat) 2: Fedora (3.9.4-301.fc19.armv7hl) 19
> > > > (Schr??dinger???s Cat) Enter choice:
> > > > """
> > > > is the output on boot, the user can then enter 1 or 2 to select
> > > > a kernel to boot. if nothing is selected the first option is
> > > > booted after the timeout expires.
> > >
> > > Sure.
> > >
> > > Now, I'd like to make some, or at least one suggestion. Distros
> > > should make use of falcon mode (SPL boots Linux directly), or at
> > > least offer it to the user. Similar to how I can configure, in
> > > the distro, a grub menu to show up, timeout and boot a default,
> > > or just boot the default unless I'm spamming escape during
> > > boot-up.
> >
> > If that's an option absolutely. I didn't mention it because I did
> > not think it was an option and I do not see it as necessary to unify
> > things. but it is a great usability option to have for users. how
> > is it configured?
>
> See doc/README.falcon and then yes, we would need to say here are how
> some parts of that (such as the don't try kernel, do u-boot key) are
> set.
Great thank you
> > > Now, since most of what you ask for exists today, can you write up
> > > what config options you'd want enabled and what a default
> > > environment looks like, for highbank or wandboard so that it
> > > works for generic distros, and we can start talking about what
> > > fallbacks would be needed so they can still be used in other
> > > contexts just as easily?
> > >
> > > And when I say "Sure" above, I mean patches will be reviewed, if
> > > submitted.
> > >
> > > Thanks!
> > >
> > Thanks for the feedback. Most of what I want is there today and just
> > needs to be enabled.
>
> Good to hear!
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
