> >Every ARM gimmick you can find over the last 10 years runs either > >a custom configuration of RedBoot, or a custom configuration of U-Boot, > >or something different. There is no way to write a design-agnostic > >kernel which will be able to figure out its environment (firmware, > >configuration data, devices). Passing an FDT file to describe the > >devices is not an option, because there is no well-defined way to pass > >arguments to the kernel, due to all these conflicting and/or subtly > >incompatible firmwares. > > Actually, FDT's have a specific node which is used to pass argments > to the kernel, and arbitrary values are simple to pass via the > device tree. U-Boot in particular has FDT editing capabilities which > allow a run-time change to the kernel params via the FDT from the > console.
But how do you pass an FDT to the kernel? Oh, that's easy, it's at 0xff000000. Unless it's at 0xf0000000, that is. Which it is, except when it's at 0xf800f000. But did I mention it might reside at 0xfd000000? When it's not at 0xe2000000 of course, but you knew this because it was not at 0xc2001000. Or was it? > Given that Arm is fabless, perhaps *THEY* should be the ones to > drive a vendor agnostic boot platform?? Let me tell you a secret. But please don't tell anyone. THEY FSCKING DON'T CARE! ...because either way they'll sell their ugly chip anyway. > My latest experience in the PowerPC (Firmware/board bringup for a > new P4080/FPGA design) world was a positive one, and the key to this > is simple: > > - Adopt OpenFirmware This item currently does not fit the ARM world. Convince them to adopt sane standards and you'll be my hero (for at least a whole year). > Your perspective has more than a granule of truth to it. I know it > resonates for me, and I'd love to see the BSD's (all of them) band > together to solve the problem 8-). BSD bonding together? Even for something which would benefit them? You're smoking way too much weed. Miod
