On Thu, 8 Aug 2013 20:48:24 +0200 Dirk Müller <d...@dmllr.de> wrote:
> Hi Dennis, > > > right or wrong we want things to be simple for the user and to > > largely look like a linux system on x86 would. The user and distro > > should never need to worry about memory locations > > > > so this would mean similar partitioning. i.e. /boot on ext4 root and > > swap on lvm or as raw partitions. people should be able to have > > just / on ext4 also. Down the road xfs /boot support would be a > > nice to have. > > I personally don't see a reason for xfs on /boot (or the journalling > nature of ext4, but thats besides the point). I agree though that a > filesystem that supports symlinks is a must for being able to > reasonably well install a regular kernel image (or multiple parallel) > on /boot. you are free to make that choice. I don't want to close doors or force people to do things only one way. > Therefore, the openSUSE on ARM team has a locally patched version of > u-boot that handles booting from extX directly, because we did not > like to use FAT or anything similar for /boot, and didn't see the need > for adding a special /load (or similar) partition that is only there > to make u-boot happy. I've seen the patch and it is a start but it needs a bit of work to support all the options people could want from it. > We've not always received love for this patch, given that all the > people who "know how to do things" where confused because our way of > building an image was so different than what is documented on the net > everywhere, but it makes the layout feel more natural for somebody > coming from non-ARM architectures. Right that is the ultimate goal. > > 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. > > on openSUSE for ARM, we're converging to using only one boot.scr > template, that is > only templatized on the various addresses that are needed to be passed > down and the flavor name (mostly for being able to print the right > information during boot). my proposal should enable you to use one boot.scr with variables. however my goal is to use a extlinux.conf file that is exactly the same format as those used for years in syslinux on install cd/dvds. I would love all distros to move this way as it gives you a nice menu and a simple interface with the option to select any installed kernel. > If it is reasonably possible to avoid the templatisation of the > addresses, I'm all for it. I don't know if it is feasible, and for us > it is not really an issue (unless it is a board supported by the > zimage flavor). > > > 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. > > True. not easy to detect though which input/outputs are connected. We > have issues due to that as well. sure, some of it is definitely things that are down the road nice to haves. Dennis _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
