On 21 April 2016 at 14:15, Sylvain Garrigues <sylv...@sylvaingarrigues.com> wrote: > Le 21 avr. 2016 à 14:54, Peter Maydell <peter.mayd...@linaro.org> a écrit : >> On 21 April 2016 at 13:50, Sylvain Garrigues >> <sylv...@sylvaingarrigues.com> wrote: >>> BTW, would be great to be able to set the load addr on the command >>> line, wouldn’t it? >> >> The booting protocol does not mandate any particular address >> that the kernel has to be loaded at: >> https://www.kernel.org/doc/Documentation/arm/Booting > > I didn’t know qemu would blindly follow and stick to Linux rules, > but I understand. I use qemu for baremetal and *BSD emulation, I wish > it would be easier to change the loading address (and not stick with > Linux rules like so many people again) :-)
-kernel for a non-ELF file is specifically "boot a Linux kernel according to the Linux kernel booting protocol". Your other options for booting are (1) provide -kernel with an ELF file, which we will load at whatever start address the ELF header specifies, or (2) on boards which have a flash device, use -bios or -pflash options to specify a flash image to go in that flash device (I don't think raspi2 has this yet though). For bare metal testing either of those last two seem like a better approach; you should also be able to wrap the FreeBSD kernel in an ELF file to get it to work like that (you'll need to handle SMP secondary boot yourself though; or just stick a relocation shim on the front of the FreeBSD kernel). The reason I'm a bit reluctant to add extra bells and whistles to the builtin bootloader is that it can quickly get out of hand: should we support all of Linux, FreeBSD, NetBSD, OpenBSD, Windows, etc etc etc? At some point the right answer becomes "run the real guest bootloader like u-boot from flash and let that start the kernel". There may be something we can do here to make FreeBSD's life easier, but we definitely can't do it on the eve of a release. >> If the FreeBSD kernel can't handle being loaded wherever >> we put it, that sounds like a FreeBSD bug to me… > > I would not say it is a bug, but an explicit assumption. Indeed, the > kernel expects it is loaded on a 2 MB page boundary. > I’m no expert, but I believe it was made so that we could remove the > need for setting the physical address in the building process. The > virtual to physical offset is computed more simply with that assumption. > With the patch you committed for me earlier today (b4850e5), the patch > we are talking about in this email (which is not a feature but a bug > fix in my opinion) FWIW, I agree this is a bug fix; it's just that we're hours away from tagging the final RC for this release cycle, so the bar for "is this bug important enough to put in now?" is quite high... thanks -- PMM
