Re: x86 bootstrap features
Emile `iMil' Heitor wrote: > Is there any news on this front? The initial multiboot2 effort for amd64 has not yet been completed. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: x86 bootstrap features
On 20.01.2020 17:42, Emile `iMil' Heitor wrote: > > Hi Kamil, Emmanuel & all, > > On Tue, 24 Sep 2019, Kamil Rytarowski wrote: > >> On 24.09.2019 14:26, Emmanuel Dreyfus wrote: >>> On Tue, Sep 24, 2019 at 01:31:51PM +0200, Kamil Rytarowski wrote: My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with multiboot2 patches merged) it still did not work. >>> >>> I did not commit anything in multiboot support in the NetBSD kernel, >>> I only worked on bootstraps for now, hence the steady failure you >>> experience should come at no suprise. >>> >>> For now our kernel has support code for multiboot 1 for i386 only. >> >> qemu-system-i386 works, but -x86_64 not. >> >> Are there plans to add it to the amd64 kernel? > > Is there any news on this front? Being able to boot an amd64 kernel > directly > from kvm would give NetBSD the ability to be started by AWS > Firecracker[1] out > of the box which would be amazing. > > [1]: https://github.com/firecracker-microvm/firecracker > There was some work on multiboot but it was reverted. I consider qemu -kernel NetBSD/amd64 booting as a high priority. > > Emile `iMil' Heitor * > _ > | http://imil.net | ASCII ribbon campaign ( ) > | http://www.NetBSD.org | - against HTML email X > | http://gcu.info | & vCards / \ > > > !DSPAM:5e25d89018011320695049! > signature.asc Description: OpenPGP digital signature
Re: x86 bootstrap features
Hi Kamil, Emmanuel & all, On Tue, 24 Sep 2019, Kamil Rytarowski wrote: On 24.09.2019 14:26, Emmanuel Dreyfus wrote: On Tue, Sep 24, 2019 at 01:31:51PM +0200, Kamil Rytarowski wrote: My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with multiboot2 patches merged) it still did not work. I did not commit anything in multiboot support in the NetBSD kernel, I only worked on bootstraps for now, hence the steady failure you experience should come at no suprise. For now our kernel has support code for multiboot 1 for i386 only. qemu-system-i386 works, but -x86_64 not. Are there plans to add it to the amd64 kernel? Is there any news on this front? Being able to boot an amd64 kernel directly from kvm would give NetBSD the ability to be started by AWS Firecracker[1] out of the box which would be amazing. [1]: https://github.com/firecracker-microvm/firecracker Emile `iMil' Heitor * _ | http://imil.net| ASCII ribbon campaign ( ) | http://www.NetBSD.org | - against HTML email X | http://gcu.info| & vCards / \ !DSPAM:5e25d89018011320695049!
Re: x86 bootstrap features
On Tue, Sep 24, 2019 at 05:43:52PM +0200, Kamil Rytarowski wrote: > qemu-system-i386 works, but -x86_64 not. > > Are there plans to add it to the amd64 kernel? After considering the thing carefuly, I come to the conclusion that it will not work until multiboot 2 support is added to Qemu: multiboot 1 only specifies how to boot a 32 bit system. An alternative path would be to introduce in our amd64 kernel the same hack that exists in Xen: it is an amd64 binary that masquerades as a 32 bit ELF executable so that it can boot from multiboot 1. That does not look like a desirable way, though. -- Emmanuel Dreyfus m...@netbsd.org
Re: x86 bootstrap features
On Wed, Sep 25, 2019 at 02:53:44PM +0300, Andreas Gustafsson wrote: > Michael van Elst wrote: > > This assumes that code and data segment is the same and assigns > > the following 64k block to the stack. We switch to protected > > mode soon after, but the memory layout seems to stay the same. > > Maybe changing to > > > > addw$0x2001, %ax > > > > is all that is needed. > > I guess we also need to bump these definitions in the Makefile? > > SAMISCCPPFLAGS+= -DHEAP_START=0x1 -DHEAP_LIMIT=0x3 That even looks wrong now. The start address aligns with the stack area so that heap and stack grow into each other, but the limit is beyond the stack top. But revision 1.6 date: 2011-03-18 18:46:26 +0100; author: jakllsch; state: Exp; lines: +8 -6; Automatically adjust pxeboot(8) stack based on the end of .bss, like is already done in biosboot.S for boot(8). (The heap location will need to be adjusted if pxeboot expands much more.) confirms that the heap needs to be adjusted too. :) Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: x86 bootstrap features
Michael van Elst wrote: > This assumes that code and data segment is the same and assigns > the following 64k block to the stack. We switch to protected > mode soon after, but the memory layout seems to stay the same. > Maybe changing to > > addw$0x2001, %ax > > is all that is needed. I guess we also need to bump these definitions in the Makefile? SAMISCCPPFLAGS+= -DHEAP_START=0x1 -DHEAP_LIMIT=0x3 -- Andreas Gustafsson, g...@gson.org
Re: x86 bootstrap features
g...@gson.org (Andreas Gustafsson) writes: >matthew green wrote: >> more research with more systems would be good here, but perhaps >> we simply need to provide multiple versions of each style (eg, >> netboot + something, biosboot + something, etc.) >Does anyone know the reason for the pxeboot 64k limit, and if it might >be possible to increase it? The PXE spec has a 32k limit. If the downloaded code exceeds that size, it may not be able to return to BIOS on failure. Otherwise it can be larger (up to about 500kB). A 64k limit comes from 8086 real mode. # set up %ds mov %cs, %ax mov %ax, %ds # set up %ss and %sp movl$_end, %eax /* top of bss */ shrl$4, %eax/* as a segment */ addw$0x1001, %ax/* and + 64k */ movw%ax, %ss/* for stack */ movw$0xfffc, %sp/* %sp at top of it */ This assumes that code and data segment is the same and assigns the following 64k block to the stack. We switch to protected mode soon after, but the memory layout seems to stay the same. Maybe changing to addw$0x2001, %ax is all that is needed. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
re: x86 bootstrap features
matthew green wrote: > more research with more systems would be good here, but perhaps > we simply need to provide multiple versions of each style (eg, > netboot + something, biosboot + something, etc.) Does anyone know the reason for the pxeboot 64k limit, and if it might be possible to increase it? -- Andreas Gustafsson, g...@gson.org
Re: x86 bootstrap features
>> And last question; should we have a build-time check that >> pxeboot_ia32.bin is smaller than 64 kB? I recall, once, reading of someone who had packed some kind of CLI into an incredibly small space by realizing that speed was pretty close to the last consideration and had written it in an interpreted custom DSL written in an interpreted custom DSL. Perhaps the booters could be set up similarly (perhaps not quite to that extent, but something along thoe those lines)? It seems to me that they are another case where speed is distinctly secondary to size. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
re: x86 bootstrap features
Emmanuel Dreyfus writes: > Generally speaking, does anyone see any usage fpr GPT and RAIDframe > support, or multiboot 2 support for dosboot, pxeboot and netboot? If > not, we could disable the features for that boostraps, which would > save space for later. i use raidframe and gpt with pxeboot. i'm not sure i get the usefulness of multiboot in pxeboot, but perhaps just need to know about the missing link. > And last question; should we have a build-time check that pxeboot_ia32.bin > is smaller than 64 kB? more research with more systems would be good here, but perhaps we simply need to provide multiple versions of each style (eg, netboot + something, biosboot + something, etc.) this sucks, though. it would be great if someone looked at removing as much code here as possible -- growth shouldn't be that much for good long time once it works sanely with current systems. .mrg.
Re: x86 bootstrap features
Kamil Rytarowski wrote: > qemu-system-i386 works, but -x86_64 not. > > Are there plans to add it to the amd64 kernel? Yes, I am working on it, but don't hold your breath. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: x86 bootstrap features
On 24.09.2019 14:26, Emmanuel Dreyfus wrote: > On Tue, Sep 24, 2019 at 01:31:51PM +0200, Kamil Rytarowski wrote: >> My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with >> multiboot2 patches merged) it still did not work. > > I did not commit anything in multiboot support in the NetBSD kernel, > I only worked on bootstraps for now, hence the steady failure you > experience should come at no suprise. > > For now our kernel has support code for multiboot 1 for i386 only. > Reading Qemu sources, thare is only multiboot 1 support. Hence > qemu-system-i386 -kernel netbsd.bz2 should work, but I only had > this message: > SeaBIOS (version rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org) > Booting from ROM.. > > Reading the sources, it seems you can get more diagnostics by > rebuilding Qemu with higher CONFIG_DEBUG_LEVEL. > > qemu-system-i386 works, but -x86_64 not. Are there plans to add it to the amd64 kernel? signature.asc Description: OpenPGP digital signature
Re: x86 bootstrap features
On Tue, Sep 24, 2019 at 01:31:51PM +0200, Kamil Rytarowski wrote: > My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with > multiboot2 patches merged) it still did not work. I did not commit anything in multiboot support in the NetBSD kernel, I only worked on bootstraps for now, hence the steady failure you experience should come at no suprise. For now our kernel has support code for multiboot 1 for i386 only. Reading Qemu sources, thare is only multiboot 1 support. Hence qemu-system-i386 -kernel netbsd.bz2 should work, but I only had this message: SeaBIOS (version rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org) Booting from ROM.. Reading the sources, it seems you can get more diagnostics by rebuilding Qemu with higher CONFIG_DEBUG_LEVEL. -- Emmanuel Dreyfus m...@netbsd.org
Re: x86 bootstrap features
On 24.09.2019 13:28, Emmanuel Dreyfus wrote: > Hello > > I recently added features to x86 bootstraps (GPT and RAIDframe support, > multiboot 2), which caused the files to grow. That causes troubles: > > - I had to disable multiboot 2 for dosboot, otherwise the binary gets too > big and the build fails. > - In kern/54560, it seems we discovered pxeboot_ia32.bin should not get > bigger than 64 kB. We will have to disable multiboot 2 there too to > keep below 64 kB. > > The other boostraps where multiboot 2 is present are boot, efiboot and > netboot. It is desirable for the two formers, but I am less convinced > for the later. > > Generally speaking, does anyone see any usage fpr GPT and RAIDframe > support, or multiboot 2 support for dosboot, pxeboot and netboot? If > not, we could disable the features for that boostraps, which would > save space for later. > > And last question; should we have a build-time check that pxeboot_ia32.bin > is smaller than 64 kB? > My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with multiboot2 patches merged) it still did not work. signature.asc Description: OpenPGP digital signature
x86 bootstrap features
Hello I recently added features to x86 bootstraps (GPT and RAIDframe support, multiboot 2), which caused the files to grow. That causes troubles: - I had to disable multiboot 2 for dosboot, otherwise the binary gets too big and the build fails. - In kern/54560, it seems we discovered pxeboot_ia32.bin should not get bigger than 64 kB. We will have to disable multiboot 2 there too to keep below 64 kB. The other boostraps where multiboot 2 is present are boot, efiboot and netboot. It is desirable for the two formers, but I am less convinced for the later. Generally speaking, does anyone see any usage fpr GPT and RAIDframe support, or multiboot 2 support for dosboot, pxeboot and netboot? If not, we could disable the features for that boostraps, which would save space for later. And last question; should we have a build-time check that pxeboot_ia32.bin is smaller than 64 kB? -- Emmanuel Dreyfus m...@netbsd.org
