Oliver, I have to completely disagree with you that U-Boot source code is even required for the board - let alone something based on mainline. This is not some crazy little embedded board like Beagle where the updates come fast and there are 10 forks, and to be honest we would be doing a great disservice to customers by making it as such. Ubuntu has absolutely no benefit and no business updating the core boot firmware on a board.
We are porting to U-Boot 2010.12-rc3 right now on the sole basis that it is less maintenance for us, and source *is* available, we are simply not in the frame of mind to publish this for everyone to mess around with. GPL compliance is one thing (ask and ye shall receive :) but *packaging* it is egregious. flash-kernel support for vfat is, in that sense, an egregious hack we know works on omap3 boards, but wanted to do away with. vfat support for booting on the latest unpublished U-Boot (2009.01-2.0.6) is a capitulation to the fact that we would like to run kernels and boot scripts from clean unboxed SD cards; just drop them in a reader, copy the files. No formatting, partitioning or anything. This works just because we use the same concept in our bootcmd as flash-kernel's Dove boot.scr, just built in to the firmware (it is a nested loop over devices, units and filesystems and it's not really fair to exclude vfat booting off PATA when systems shipped for a year already). What we would like is to get this U-Boot flashing problem fixed: this either means getting SPI NOR working correctly under 2.6.31, or 2.6.35 (ongoing) or mainline (ongoing) in order to get the older U-Boot revisions (2009.01-1.x.x) to automagically do it from their current boot scheme (look for devices that have "uImage" on them and boot it direct). Then every system on the planet can be upgraded and nobody will have to use VFAT as a /boot ever again, once booted, they may simply convert their filesystem with 3 or 4 lines in a terminal or run a script we may provide. I do not believe we should be hacking flash-kernel to support the seperate "U-Boot partition" just so we can patch it out again. We have to work on unifying the behavior of the systems. What we can do, is provide you guys with U-Boot source code for the update, which will probably happen in the next few days, if not an automatic installer SD which will refresh Maverick.. As it stands the patch supports the board fine as long as you are using the required ext2 partition for /boot - this includes every Smartbook given out at UDS. If you are unlucky enough to use vfat, then unfortunately you will need to migrate here for it to work ideally. We are willing to help people migrate. By the time Natty rolls around this thing will be settled. In the meantime send me a mail and I'll make sure you guys can get U-Boot and give instructions on how to manually update it on a Smarttop. -- Add Efika MX Smartbook/Smarttop support https://bugs.launchpad.net/bugs/671027 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
