Hi Vagrant, many thanks for the comprehensive answer and summary on how flash-kernel works.
Am Samstag, 17. Februar 2018, 16:22:06 CET schrieb Vagrant Cascadian: > > In Debian, using Debian-supplied u-boot and a boot script generated by > flash-kernel, hummingboard/mx6cuboxi variants run a > bootscript... flash-kernel defines in /usr/share/flash-kernel/db/all.db: > > Machine: SolidRun HummingBoard DL/Solo > Machine: SolidRun HummingBoard Solo/DualLite > Kernel-Flavors: armmp > DTB-Id: imx6dl-hummingboard.dtb > Boot-Script-Path: /boot/boot.scr > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > > Machine: SolidRun HummingBoard Dual/Quad > Kernel-Flavors: armmp > DTB-Id: imx6q-hummingboard.dtb > Boot-Script-Path: /boot/boot.scr > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > > > So, flash-kernel copies the .dtb file listed there to > /boot/dtbs/VERSION/ and symlinks /boot/dtb* to the .dtb in the versioned > directory, based on the machine name defined in /proc/device-tree/model. I replaced the dtb file in /boot/dtbs/VERSION/ that worked well. Thank you. Also mounting the sdcard and reverting back to the old one worked ;-) > All the above variants use the uboot-generic boot script, which can be > found and edited on an installed system in: > > /etc/flash-kernel/bootscript/ > > So you could edit the script to do whatever you want. > > > Can anybody tell, if it is possible to configure from u-boot shell to > > loada > > custom device treefile? > > To manually change it for a one-off boot: > > # disable the built-in setting of fdtfile > setenv findfdt > # manually set fdtfile > setenv fdtfile /path/to/your/custom.dtb Where is findfdt defined? $ grep findfdt /etc/flash-kernel/bootscript/* $ >From looking into the bootscr fdtfile needs only the filename: if test -n "${fdtfile}"; then setenv fdtpath dtbs/${fk_kvers}/${fdtfile} else setenv fdtpath dtb-${fk_kvers} fi Correct? > You could, of course, also manually load the kernel, initrd, fdt and use > bootz rather than trying to work around the defaults in the boot script. Hmm... not sure how that works, but would be worthwhile to document,. I assume I need to do something like load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${pathprefix} vmlinuz \ && load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${pathprefix}dtb \ && load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} ${pathprefix} initrd.img \ && echo "Booting Debian from ${devtype} ${devnum}:${partition}..." \ && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} I did not find an easy way to boot the .old kernel, just wondering if it would make sense to do add a kernelpostfix load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${pathprefix}vmlinuz$ {kernelpostfix} and similar for the other lines. Then it would be sufficient to set in the u- boot shell: kernelpostfix to .old > > Is that somewhere documented? The latest documentation on flash-kernelI > > found is from 2011... > > I'm not sure what sort of documentation you're looking for. > > You can learn about u-boot by looking in the source code for the README, > the doc/* files, and of course the source code itself. > > Many modern boards are using distro_bootcmd, which is documented in > doc/README.distro, which has improved the consistancy of behavior of > boards. I have never seen that, thanks for mentioning this. > There's the README for flash-kernel in > /usr/share/doc/flash-kernel/README* > > > https://wiki.debian.org/FlashKernelRework > > Some of the features documented there have been implemented, or don't > really apply to modern boards that make use of distro_bootcmd. > > Now that I'm on a roll and this email is getting really long... > > I do think we should consider replacing flash-kernel with something else > at this point. The tool has grown and evolved all sorts of features; I did not want to imply replacing flash-kernel.... > I've never used it to "flash a kernel". I've exclusively used it for > purposes other than it's original design (mostly just copying a .dtb and > generating a boot script that is essentially re-useable on most boards I > use it with). > > Scalability is a bit questionable; it actually cats the entire contents > of all.db and reads it into a variable, and then does "echo $VARIABLE | > grep FOO" type things in order to get data out of it. With new sunxi > boards coming out what *feels* like twice each week, grepping through an > echo'ed variable starts to seem like a bad idea to me. > > Of course, it also kind of works well enough for what it is... but > adding new features is, in my experience, an unpleasant task. And > occasionally those new features are really needed with modern changes. > > > I've used u-boot-menu on a handful of boards, although it also currently > has some limitations. For example, it doesn't support /boot on a > separate partition without manual configuration ... anyone remember the > lovely hack "ln -s . /boot/boot" ... well, yeah... using *that* > again. It also doesn't handle copying the .dtb into /boot, so I still > need flash-kernel for that. > > And then there's the support for u-boot emulating EFI so you could use > grub-efi-*, which has made great progress in recent u-boot versions. But > then we could use grub on more platforms ... that would be a nice goal > for buster, at least. > Many thanks for the detailed description, I bookmarked your post in the mailing list archive :-) Does it make sense to paste the big picture in a Debian wiki page (or multiple of them) and link the /usr/share/doc/... files? Thanks a lot again Rainer -- Rainer Dorsch http://bokomoko.de/