On Mon, Feb 11, 2008 at 09:32:11AM -0300, Werner Almesberger wrote: > Harald Welte wrote: > > Do you realize that you are just scrapping the ability to > > boot any different OS on the device? > > I wonder how you jump to this conclusion. It's not as if there'd be > some "secret trusted BIOS" that enforces signed binaries or such.
no. but it's something that is at the state of 'oh yes theoretically you can do XYZ, but we have not heard of anyone doing it so far, and we will not provide you all the tools you need.' > > By switching to kexec, you virtually remove that ability. Yes, people > > can still replace the linux kernel with a bootloader, but it is _MUCH_ > > harder since you have to do all the low-leve setup such as GPIO > > configuration, etc. again. A common bootloader for PLL/GPIO init helps > > a lot in that regard. > > They'll have to port tons of drivers anyway. that's easy. IF you have the GPIO/PLL right and get to a serial console, everything else is just a matter of systematic debugging. But up to that point, it's _really_ hard. > I doubt a few GPIOs, would break their back :-) If they're really > having too hard a time to bring up their kernel, they could even take > the old u-boot code and run that first. Or just bring up Linux and > dump the registers they're interested in. being a person who has ported linux to devices for which no existing bootloader was there, I assure you that if you don't have existing code that reliably puts the hardware in a working state, it makes a lot of difference. It's not the amount of time you spend to implement drivers, it's the amount of time you waste while not knowing anything for sure, not even if the GPIO pins are configured right. And yes, the difference is that the openmoko linux kernel is open source, and that it is possible to read all those bits from there in source, rather than object code. Still, there's a plethora of mistakes. > Yes, I can see how it might (*) make the effort of porting a non-Linux > system marginally easier. However, I don't see any sensible relation > between this and the drain of resources keeping u-boot around means > to us. To me, any effort is sensible if it makes the device easier to hack on, in whatever way. Please also factor in the knowledge curve. u-boot is well understood in the embedded world. Almost everyone has seen/used it, there's lots of documentation. Last, but not least, most of the existing openmoko developers in the community have experience with using it. Switching to a hyper-new kboot/kexec approach that has not seen widespread adoption in the embedded world will scrap all that. People first have to understand and learn how to work in that new world. To me, having a bootloader in an embedded device is just 'industry standard'. OF all the embedded Linux devices that I've seen on system level (mostly related to gpl-violations.org), 99% have a bootloader independent from the OS. A bootloader that can do tftp (in case of networked devices), boot from sd-card, ... Some use blob, some redboot, some u-boot, some others are proprietary. Now if you replace that with a 'linux based bootloader', I generally don't mind. But Linux is just a kernel, not a bootloader. Where is the standard commandset that the bootloader understands? Where is the standard solution for implementing things like the u-boot environment (aka config file) or the interactive shell with a standard set of commands? Basically I think you can very well replce bootloader X with bootloader Y. But at the moment I have the feeling you want to replace bootloader X with a toolkit-that-could-well-become-a-bootloader Y. I like the toolkit. And I like the idea of the flexibility that it has. But I dislike that all we then get is a kernel and busybox. Oh yes, one _could_ put this or that custom script in there. It's flexibility, but has a distinct loss of structure. >From a bootloader user perspective you don't want a general purpose shell into whcih you can put your own scripts. You want something concisive, tailored to your application. You don't want to fiddle around cycling throguh /proc, /sys and /dev, trying to figure out which bits you need where, trying to find the important in all the noise. Sure, all that can be implemented on top of the linux kernel. But will you do it? Where is the 'mmcload/ext2load/loadelf/...' level of abstraction? > (*) Actually, if I had to start from scratch, I'd probably just do all > the initialization myself anyway, so that it's done by code I > fully control. mh, yes. very convenient for the developer who does it. very sucking for the user who wants to see one of the standard three arm bootloaders out there, which he has worked on before, for which he can easily google all the questions and answers that he wants. > I can understand your decision for choosing u-boot when there was no > code at all that ran on our platform. But now we're in a much better > situation, and we can move on and use tools that fit our needs better. I think adhering to some 'best current practise' (how worse it might actually be) has way more advantages than switching to something hyper-cool, new, efficient, but little known/understood. > > Also, dual-booting different OS's is no longer possible. > > We obviously want to be able to choose kernels. yes, but we want to be able to boot things that don't behave like a linux kernel. You cannot expect everyone to accomodate their boot/calling/parameter passsing conventions how you like them. Traditionally it has been the task of the bootloader to accomodate/implement those different booting conventions. If you now expect everything to look like a linux image, then you either force the other ones to adopt, or somebody would have to add an intermediate shim layer. If that latter shim layer came as a standard with whatever-on-top-of-kboot-kexec, it would be acceptable. > So any other OS would just be another binary that you load and jump > to. No discrimination there. (BTW, you're already talking about the > next step, which would be NAND booting. For now, we're just thinking > about NOR.) so you want a kernel in nor and u-boot in NAND? Well, in that case, if its just for the emergency, I don't particularly care what is booted there. -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone
