Hello, 2010/3/3 Oliver Kiddle <[email protected]>: > If you consider what makes the non-x86 hardware different it is the lack > of a standard way to boot an alternate OS. With a PC BIOS you can instruct > a PC to boot from a floppy/CD/whatever and we only need a single CD image > to boot most PCs. Even for headless x86 servers, it's never hard to get > whatever OS on. > > If ARM really think they can challenge Intel Atoms in the netbook market, > then I think they need to address this because a significant number of > people will care about being able to upgrade the OS or to choose between > Android, WinCE, Ubuntu Netbook Remix or MeeGo.
At least some people is aware of such issues and are trying to convince (arm) kernel people to introduce device trees[0], whilst it has been widely used by powerpc people (also xilinx is adopting it[1], I *guess* they'll *probably* use it for new AMBA bus design for their ARM+FPGA). > Most of these devices use u-boot (or RedBoot) and as these are > open source, perhaps it would be wise to make them (in their default > configuration) do things to make life easy for us. As far as I can tell > from a quick scan of the documentation, u-boot has support for putting a > logo on an LCD during boot but not for using that screen and a keyboard as > a console. If a certain key press during boot switched u-boot to providing > a console then many manufacturers might leave it in (either intentionally > or due to ignorance). For me the hardest part of implementing a text > console or even BIOS style menus in an open source bootloader would be > getting a setup where I'm not going to brick my shiny new netbook. The non-x86 installer shall have an interface to customize any kind of loader or pre-loader, at least have an option to pass a configuration file for it. I also believe environment variables should be kept in a separated partition so those can be easily accesible from kernel land. > Other similar features would be supporting consoles with USB-serial > converters and network connections at carefully timed points in the boot > process. Network/SD/MMC/USB boot is surely a must and those should be first devices to tackle. Then we also have MTD to think about. Having a serial debug port is desirable. > For any device where the manufacturers try to close it off to hackers, > we're always going to have to jump through hoops specific to that device > to get Debian installed. They can easily disable bootloader > features but on netbooks, maybe they won't: PC makers are used to having > a BIOS with screens saying "Press F1 to enter Setup". It is nice if we can hack manufacturers toys, but if those are non-free to hackers, why should we "officially" support them? Best regards, [0] http://marc.info/?l=linux-kernel&m=126660762616227&w=2 [1] http://git.xilinx.com/cgi-bin/gitweb.cgi?p=device-tree.git;a=summary -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
