Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)
Anthony Ross wrote: ]Thanks for the heartiest reply. Well I have gone through the pros & cons of DUET & haven' t faced any hurdles thus ]successfully building it. Similarly getting to the EDK2 project I have successfully built OVMF 32 & 64 with secure boot ]configuration, integrating them with seabios as csm and initializing them in QEMU-kvm. I have also successfully built & ]booted the Coreboot Pkg IA32 encapsulating it in the coreboot.rom and booting it under QEMU-kvm except for the X64 ]architectures I faced certain toolchain errors. ] ]So if the Coreboot Pkg can boot so should DUET. I know there are both different but any how they both follow the same ]basis of the UEFI platform. I say this because the Coreboot Pkg (coreboot.rom) during its boot up shows signs of errors & ]debugging messages are worth noting but DUET (coreboot.rom) seems just absent.It also does not indicate any low ]memory problems in real mode, frankly speaking the coreboot.rom just boots as if it was built with just a seabios ]payload. Yes one thing can be noted when I had earlier booted DUET directly under QEMU it indicated something as ]'executing code out of memory' and it aborted there.Secondly taking again into concern the Coreboot Pkg it follows lzma ]compression and also DUET so any issue about that? & what about QEMU does it require any changes as for DUET It is good to hear you are you are building successfully. Here is an alternative method of booting the EDK2 Duet project. It uses the publically available AMD simnow in place of qemu. Simnow has the benefit of booting unmodified BIOS and other code. It boots the same BIOS image that is used on the real hardware. You can use simnow to ensure you have a working image. Then you can try it on real hardware. Simnow can be downloaded from here: http://developer.amd.com/tools-and-sdks/cpu-development/simnow-simulator/ I tested using the simnow model for an old AMD reference board named Solo. The limited virtual address space of the processor used in the Solo model avoids a memory overwrite bug in the Duet code. The limited DRAM of the Solo model avoids pointer truncation problems in the Duet code. Here is how I tested: 1) get EDK2 SVN version 14796 from one of the public servers. 2) build the Duet project and use the output to make a bootable hard disk image. 3) boot the hard disk image using the simnow solo model. The simulation will stop with a red screen register dump. This is due to a Duet bug where initialization of the 8254 timer while it is already running causes a spurious interrupt. Use the built-in debugger to continue out of the exception handler's hang loop. The simulation will continue and boot the UEFI shell. If you exit the shell, the UEFI menu system will run. Here it the bootable hard disk image and a Windows batch file for starting simnow. Some screen shots are also included. http://notabs.org/edk2-duet/ Once you have this much working, you could try real hardware or a different simnow model. This will expose some problems that need to be fixed in order to run on systems with larger memory and on processors with larger virtual address space. I have no experience with making SeaBIOS boot an embedded floppy image. I may be able to give this a try, but I would have to first overcome Windows build problems that have crept into both SeaBIOS and coreboot. Thanks, Scott On Wed, Oct 23, 2013 at 1:00 AM, Scott Duplichan <spambucket@notabs.org> wrote: Neo wrote: ]Hello ] ] There has been no response to my thread [Help required to initialize ]coreboot as Seabios (floppy mechanism for DUET) payload] since a long ]time.I have eagerly waited but no solutions have turned up. ] If Im mistaken in any way or the other please let know. ] ]Regards.... ] ]Neo. Hello, If this is really something you want I may be able to help. Be aware that Duet is not an active EDK2 project. Duet has many problems that you must solve before it is usable. The Duet concept is sound, and is a good match for coreboot. But it is not in general a usable project as it exists in the public EDK2 archive. Building Duet should be easy, relative to other EDK2 projects. Can you successfully build other EDK2 projects? From EFI's beginning in 1999 to recently, the only supported build toolset was Microsoft. Recently gnu build tool support was added. But because Duet is not an active project, it may not build easily with gnu tools. In addition, EDK2 does not properly support any Windows port of the gnu tools. So try building with Microsoft tools for a reference point. But be aware that EDK2 actually uses a hard-coded absolute path to the Microsoft tools. So unless your Microsoft build tools are installed in the same location as theirs, you will have to modify Basetools\Conf\ tools_def.template. Once Duet builds, there are some basic bugs to fix. There is a memory overlap problem for example. Duet cannot work with more than 4GB of RAM if I remember correctly. These are all easy to fix. Another problem is a limitation on the DXE image size. This limitation is due to the DOS 640 KB memory limit. The DOS 640 KB limit is relevant because the image is read from disk in 16-bit mode and low memory is the most convenient place to put it. This limitation must be removed before a full featured DXE can be used. Once all the problems are fixed, the reliance on legacy BIOS INT 13h can be removed. The image can be kept in flash and then copied to DRAM instead of reading it from a file. One of the bigger problems is that UEFI needs a large amount of NVRAM. The size is too big to fit into CMOS. That means you need to add code to write this data to flash memory. Normally a 64-KB block of the BIOS flash chip is set aside for this use. There are several more problems in addition to these. They can all be overcome, but it takes some time. The good thing about Duet is that it uses only the generic portion of UEFI, so it is easy to run on an emulator such as simnow or qemu for development and debug. Duet requires that DRAM init and any other chipset initialization be complete. Duet finds DRAM by calling E820, though passing the info directly is possible. Duet does not supply ACPI tables. It finds existing ACPI tables and uses those. Same for SMBIOS. Thanks, Scott
Scott Duplichan wrote: <..snip..> ]I have no experience with making SeaBIOS boot an embedded floppy ]image. I may be able to give this a try, but I would have to first overcome ]Windows build problems that have crept into both SeaBIOS and coreboot. I tested the SeaBIOS virtual floppy boot with EDK2 Duet and it worked for me. I tested with the ASRock e350M1 project. Here is the cbfstool output: scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build $ cbfstool.exe coreboot.rom print coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x400000 alignment: 0 bytes Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1776 pci1002,9802.rom 0x740 optionrom 57856 fallback/romstage 0xe980 stage 345432 fallback/coreboot_ram 0x62f40 stage 203312 fallback/payload 0x949c0 payload 53738 config 0xa1c00 raw 3831 (empty) 0xa2b40 null 3526744 scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build $ cbfstool.exe coreboot.rom add -f /d/duetfloppy.img -n floppyimg/duetfloppy.img -t raw scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build $ cbfstool.exe coreboot.rom print coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x400000 alignment: 0 bytes Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1776 pci1002,9802.rom 0x740 optionrom 57856 fallback/romstage 0xe980 stage 345432 fallback/coreboot_ram 0x62f40 stage 203312 fallback/payload 0x949c0 payload 53738 config 0xa1c00 raw 3831 floppyimg/duetfloppy.img 0xa2b40 raw 1474560 (empty) 0x20ab80 null 2052120 The serial port output is attached. Here is the part where the floppy image is found: Mapping CBFS floppy floppyimg/duetfloppy.img to addr 0xc7e53000 Searching bootorder for: /rom@floppyimg/duetfloppy.img The floppy image name passed to cbfstool must begin with floppyimg/ because SeaBIOS is expecting that prefix. The floppy image I tested with is here: http://notabs.org/edk2-duet/coreboot/e350/ Thanks, Scott On Wed, Oct 23, 2013 at 1:00 AM, Scott Duplichan <spambucket@notabs.org> wrote: Neo wrote: ]Hello ] ] There has been no response to my thread [Help required to initialize ]coreboot as Seabios (floppy mechanism for DUET) payload] since a long ]time.I have eagerly waited but no solutions have turned up. ] If Im mistaken in any way or the other please let know. ] ]Regards.... ] ]Neo. Hello, If this is really something you want I may be able to help. Be aware that Duet is not an active EDK2 project. Duet has many problems that you must solve before it is usable. The Duet concept is sound, and is a good match for coreboot. But it is not in general a usable project as it exists in the public EDK2 archive. Building Duet should be easy, relative to other EDK2 projects. Can you successfully build other EDK2 projects? From EFI's beginning in 1999 to recently, the only supported build toolset was Microsoft. Recently gnu build tool support was added. But because Duet is not an active project, it may not build easily with gnu tools. In addition, EDK2 does not properly support any Windows port of the gnu tools. So try building with Microsoft tools for a reference point. But be aware that EDK2 actually uses a hard-coded absolute path to the Microsoft tools. So unless your Microsoft build tools are installed in the same location as theirs, you will have to modify Basetools\Conf\ tools_def.template. Once Duet builds, there are some basic bugs to fix. There is a memory overlap problem for example. Duet cannot work with more than 4GB of RAM if I remember correctly. These are all easy to fix. Another problem is a limitation on the DXE image size. This limitation is due to the DOS 640 KB memory limit. The DOS 640 KB limit is relevant because the image is read from disk in 16-bit mode and low memory is the most convenient place to put it. This limitation must be removed before a full featured DXE can be used. Once all the problems are fixed, the reliance on legacy BIOS INT 13h can be removed. The image can be kept in flash and then copied to DRAM instead of reading it from a file. One of the bigger problems is that UEFI needs a large amount of NVRAM. The size is too big to fit into CMOS. That means you need to add code to write this data to flash memory. Normally a 64-KB block of the BIOS flash chip is set aside for this use. There are several more problems in addition to these. They can all be overcome, but it takes some time. The good thing about Duet is that it uses only the generic portion of UEFI, so it is easy to run on an emulator such as simnow or qemu for development and debug. Duet requires that DRAM init and any other chipset initialization be complete. Duet finds DRAM by calling E820, though passing the info directly is possible. Duet does not supply ACPI tables. It finds existing ACPI tables and uses those. Same for SMBIOS. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Oct 24, 2013 at 12:17:33AM -0500, Scott Duplichan wrote:
Scott Duplichan wrote:
<..snip..>
]I have no experience with making SeaBIOS boot an embedded floppy ]image. I may be able to give this a try, but I would have to first overcome ]Windows build problems that have crept into both SeaBIOS and coreboot.
I tested the SeaBIOS virtual floppy boot with EDK2 Duet and it worked for me. I tested with the ASRock e350M1 project. Here is the cbfstool output:
Thanks for confirming.
scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build $ cbfstool.exe coreboot.rom print coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x400000 alignment: 0 bytes
Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1776 pci1002,9802.rom 0x740 optionrom 57856 fallback/romstage 0xe980 stage 345432 fallback/coreboot_ram 0x62f40 stage 203312 fallback/payload 0x949c0 payload 53738 config 0xa1c00 raw 3831 (empty) 0xa2b40 null 3526744
scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build $ cbfstool.exe coreboot.rom add -f /d/duetfloppy.img -n floppyimg/duetfloppy.img -t raw
FYI, it's also possible to add an lzma compressed image (make sure the cbfs filename ends in ".lzma" then). -Kevin
Hello Coreboot Folks, Well Thanks for the suggestions. It seems that DUET boots but now a major problem has cropped up. It freezes at the main DUET-BIOS page not allowing to perform any further operations, like booting a HDD image or fingering around the EFI BIOS options. Similarly If I had the .lzma to the cbfs file name I face the same problem like earlier so having it as myfloppy.img makes it take effect. Any further Ideas about these problems..... Regards.. Neo On Sat, Oct 26, 2013 at 8:01 PM, Kevin O'Connor <kevin@koconnor.net> wrote:
On Thu, Oct 24, 2013 at 12:17:33AM -0500, Scott Duplichan wrote:
Scott Duplichan wrote:
<..snip..>
]I have no experience with making SeaBIOS boot an embedded floppy ]image. I may be able to give this a try, but I would have to first overcome ]Windows build problems that have crept into both SeaBIOS and coreboot.
I tested the SeaBIOS virtual floppy boot with EDK2 Duet and it worked for me. I tested with the ASRock e350M1 project. Here is the cbfstool output:
Thanks for confirming.
scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build $ cbfstool.exe coreboot.rom print coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x400000 alignment: 0 bytes
Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1776 pci1002,9802.rom 0x740 optionrom 57856 fallback/romstage 0xe980 stage 345432 fallback/coreboot_ram 0x62f40 stage 203312 fallback/payload 0x949c0 payload 53738 config 0xa1c00 raw 3831 (empty) 0xa2b40 null 3526744
scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build $ cbfstool.exe coreboot.rom add -f /d/duetfloppy.img -n floppyimg/duetfloppy.img -t raw
FYI, it's also possible to add an lzma compressed image (make sure the cbfs filename ends in ".lzma" then).
-Kevin
participants (3)
-
Anthony Ross -
Kevin O'Connor -
Scott Duplichan