Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Anthony Ross]

Hello Folks

Well Im still trying to figure out how to get the debug messages of
updatememorymap () written to the serial port. If any help could be
provided.

Secondly since I'm facing the same freeze problem I would like to try
something different.I need the code to execute DUET as a coreboot payload
as spoken earlier by Partick Georgi

Thirdly since I already have the latest seabios  prepped I would like to
prepare a HDD image with duet  installed to its mbr and the efi loaders set
to its active partitions.

Thanks

Neo..


On Thu, Nov 7, 2013 at 3:00 AM, Patrick Georgi wrote:

> Am 2013-11-06 14:55, schrieb Scott Duplichan:
>
>  ]We had that 4 years ago or so. Want me to look up the code?
>>
>> Yes, I would be interested to see how others approach it,
>> though I have the payload support working now.
>>
> I'll take a look, but it can take some days.
>
>
>  1) Hack in a change to make it use the proper I/O port when
>> reading the ACPI power management timer. The ideal solution
>> is to get the ACPI PM timer address from the ACPI tables,
>> which is what Duet does.
>>
> I started work on FixedAtBuild Pcds that teach the various table managers
> in UEFI to inherit existing tables (SMBIOS, ACPI). That way we could pass
> the coreboot tables into UEFI, making the payload even more independent.
> The change might also be useful for DUET, but I don't know if upstream is
> actually still interested in it.
>
>
>  2) Change PCI device and function numbers hard-coded in
>> bdsplatform.h from 440BX values to AMD SB800 values. Not
>> sure if this is essential for shell boot.
>> 3) Disable PCI ARI support to eliminate some EDK2 code
>> crashes. Not sure if the cause of the problem is an EDK2
>> problem or a simnow model problem.
>> 4) Work around a crash in SmbiosDxe.c. I didn't investigate
>> the cause.
>> 5) Expand the temporary identity mapped page tables. I
>> believe they map up to 1GB, and I am using more.
>> 6) Big changes to make it build on Windows using Microsoft
>> tools. It is really unfortunate that as of 2013, Microsoft
>> doesn't support C99. I used fasm in place of Microsoft's
>> assembler because it can assemble a module containing both
>> 32-bit and 64-bit code.
>>
> Any chance you could publish these somewhere?
>
>
>  might even be possible to extract the native UEFI GOP video driver
>> from an OEM UEFI ROM for reuse. But I believe in the case of my
>> ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.
>>
> Another alternative would be graphics init in coreboot, setting up a frame
> buffer. UEFI could parse out the cbtables to figure out the position and
> layout of the framebuffer in a primitive GOP driver.
>
> Unfortunately my time for UEFI work is rather limited these days.
>
>
>  The biggest work is going to be support for the large NVRAM
>> area needed by EDK2 UEFI. A generic solution is not possible.
>>
> Not totally generic, but I guess we could carve out some space by adding a
> CBFS file (with proper alignment) whose content is managed as nv variable
> storage (similar to how the MRC stuff on both intel and AMD works now).
> For security, I'd also propose doing the actual flash access from SMM in
> coreboot code (which can reuse the existing flash drivers) - but maybe
> that's something for later.
>
>
>  I will start with support for AMD systems.
>>
> Great!
>
>
> Regards,
>
> Patrick
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Patrick Georgi wrote:

]Am 2013-11-06 14:55, schrieb Scott Duplichan:
]> ]We had that 4 years ago or so. Want me to look up the code?
]> 
]> Yes, I would be interested to see how others approach it,
]> though I have the payload support working now.
]I'll take a look, but it can take some days.

No need to dig it up. 

]> 1) Hack in a change to make it use the proper I/O port when
]> reading the ACPI power management timer. The ideal solution
]> is to get the ACPI PM timer address from the ACPI tables,
]> which is what Duet does.
]I started work on FixedAtBuild Pcds that teach the various table 
]managers in UEFI to inherit existing tables (SMBIOS, ACPI). That way we 
]could pass the coreboot tables into UEFI, making the payload even more 
]independent.

Sounds good.

]The change might also be useful for DUET, but I don't know if upstream 
]is actually still interested in it.
]
]> 2) Change PCI device and function numbers hard-coded in
]> bdsplatform.h from 440BX values to AMD SB800 values. Not
]> sure if this is essential for shell boot.
]> 3) Disable PCI ARI support to eliminate some EDK2 code
]> crashes. Not sure if the cause of the problem is an EDK2
]> problem or a simnow model problem.
]> 4) Work around a crash in SmbiosDxe.c. I didn't investigate
]> the cause.
]> 5) Expand the temporary identity mapped page tables. I
]> believe they map up to 1GB, and I am using more.
]> 6) Big changes to make it build on Windows using Microsoft
]> tools. It is really unfortunate that as of 2013, Microsoft
]> doesn't support C99. I used fasm in place of Microsoft's
]> assembler because it can assemble a module containing both
]> 32-bit and 64-bit code.
]Any chance you could publish these somewhere?

OK, I put it here:
http://notabs.org/coreboot/e350m1-edk2corebootpkg.7z

The original and modified projects are included for diffing.

I added NOOPT to the dsc file for easier debug.

The size adjustments to the fdf file are to prevent a
build fail when the NOOPT target is built.

Changes to the C code are work-arounds for Microsoft's
lack of C99 support.

corebootPkg\Sec\X64\SecEntry.asm is a port of SecEntry.asm
for use in the Windows build environment. I used the fasm
assembler to minimize changes. Unfortunately the Microsoft
linker won't accept relocations between 32 and 64 bit code
due to pointer truncation concern. I couldn't find a link
solution, so I had to change the code to position independent.
I didn't try to port the asm support for PCDs and replaced
them with hard coded constants.

]> might even be possible to extract the native UEFI GOP video driver
]> from an OEM UEFI ROM for reuse. But I believe in the case of my
]> ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.
]Another alternative would be graphics init in coreboot, setting up a 
]frame buffer. UEFI could parse out the cbtables to figure out the 
]position and layout of the framebuffer in a primitive GOP driver.
]
]Unfortunately my time for UEFI work is rather limited these days.
]
]> The biggest work is going to be support for the large NVRAM
]> area needed by EDK2 UEFI. A generic solution is not possible.
]Not totally generic, but I guess we could carve out some space by adding 
]a CBFS file (with proper alignment) whose content is managed as nv 
]variable storage (similar to how the MRC stuff on both intel and AMD 
]works now).
]For security, I'd also propose doing the actual flash access from SMM in 
]coreboot code (which can reuse the existing flash drivers) - but maybe 
]that's something for later.
]
]> I will start with support for AMD systems.
]Great!
]
]
]Regards,
]Patrick



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Patrick Georgi]

Am 2013-11-06 14:55, schrieb Scott Duplichan:

]We had that 4 years ago or so. Want me to look up the code?

Yes, I would be interested to see how others approach it,
though I have the payload support working now.

I'll take a look, but it can take some days.


1) Hack in a change to make it use the proper I/O port when
reading the ACPI power management timer. The ideal solution
is to get the ACPI PM timer address from the ACPI tables,
which is what Duet does.
I started work on FixedAtBuild Pcds that teach the various table 
managers in UEFI to inherit existing tables (SMBIOS, ACPI). That way we 
could pass the coreboot tables into UEFI, making the payload even more 
independent.
The change might also be useful for DUET, but I don't know if upstream 
is actually still interested in it.



2) Change PCI device and function numbers hard-coded in
bdsplatform.h from 440BX values to AMD SB800 values. Not
sure if this is essential for shell boot.
3) Disable PCI ARI support to eliminate some EDK2 code
crashes. Not sure if the cause of the problem is an EDK2
problem or a simnow model problem.
4) Work around a crash in SmbiosDxe.c. I didn't investigate
the cause.
5) Expand the temporary identity mapped page tables. I
believe they map up to 1GB, and I am using more.
6) Big changes to make it build on Windows using Microsoft
tools. It is really unfortunate that as of 2013, Microsoft
doesn't support C99. I used fasm in place of Microsoft's
assembler because it can assemble a module containing both
32-bit and 64-bit code.

Any chance you could publish these somewhere?


might even be possible to extract the native UEFI GOP video driver
from an OEM UEFI ROM for reuse. But I believe in the case of my
ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.
Another alternative would be graphics init in coreboot, setting up a 
frame buffer. UEFI could parse out the cbtables to figure out the 
position and layout of the framebuffer in a primitive GOP driver.


Unfortunately my time for UEFI work is rather limited these days.


The biggest work is going to be support for the large NVRAM
area needed by EDK2 UEFI. A generic solution is not possible.
Not totally generic, but I guess we could carve out some space by adding 
a CBFS file (with proper alignment) whose content is managed as nv 
variable storage (similar to how the MRC stuff on both intel and AMD 
works now).
For security, I'd also propose doing the actual flash access from SMM in 
coreboot code (which can reuse the existing flash drivers) - but maybe 
that's something for later.



I will start with support for AMD systems.

Great!


Regards,
Patrick

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Anthony Ross wrote:

]Dear Folks
]
]Thanks for the suggestions. Well this is how I debug 
]
]qemu-system-x86_64 -no-kvm -net none -bios build/coreboot.rom
] -s -global isa-serial.iobase=0x3f8 -serial file:/new/serial8.log
] -monitor stdio
]
] (Don' t consider the 8)
]
]
]Please correct me if Im mistaken
]
]By the way by freeze I meant is that the DUET BIOS page gets displayed but it 
does not ]allow to select anything. If I use the down
arrow key there is no effect...So still ]facing the same problem.
]
]
]Any suggestions...

UEFI is not easy to debug. I do see that both PS/2
and USB keyboard support module load messages in your log file:

Loading driver at 0x000173D5000 EntryPoint=0x000173D52C0 UsbKbDxe.efi
Loading driver at 0x000173C7000 EntryPoint=0x000173C72C0 Ps2KeyboardDxe.efi

Though bdsdxe loads...
Loading driver at 0x00017428000 EntryPoint=0x000174282C0 BdsDxe.efi
... I do not see its debug messages.

You could would step through the code of PlatformBdsInit
to see why the messages from UpdateMemoryMap() are not displayed.
Thanks,
Scott
]
]
]Neo...
]
]
](Attached serial log) 
]
]
]
]
]On Wed, Nov 6, 2013 at 4:58 AM, Scott Duplichan  wrote:
]Anthony Ross wrote:
]
]]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 
]For your freeze problem, how are you debugging? The usual way
]is to enable and capture debug messages written to a serial
]port. I believe the standard Duet settings make it write
]debugging messages to a serial port at 3F8 (115200,8,N,1).
]Because halt for assert is enabled by default on Duet, an
]assert is the most likely reason for a freeze. The assert
]will log details to the serial port.
]
]If your hardware doesn't have a serial port, you can use
]an emulator such as simnow or qemu. A good thing about
]Duet is that it is generic and in theory can run on
]different systems without porting. If I remember correctly,
]the current Duet project can boot to the UEFI shell and
]menu system on AMD simnow using the Solo board model.
]
]I am working on a project to allow Duet to run as a
]coreboot payload, and to fix the major Duet problems.
]It will also continue to support bootable image form.
]It may take me a few weeks to reach the goal of booting
]operating systems in UEFI mode on real hardware though.
]
]Thanks,
]Scott
]
]On Sat, Oct 26, 2013 at 8:01 PM, Kevin O'Connor  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 0x40
]> 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



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Patrick Georgi wrote:

]Am 2013-11-06 00:28, schrieb Scott Duplichan:
]> I am working on a project to allow Duet to run as a
]> coreboot payload, and to fix the major Duet problems.
]We had that 4 years ago or so. Want me to look up the code?

Yes, I would be interested to see how others approach it,
though I have the payload support working now.

]> It will also continue to support bootable image form.
]> It may take me a few weeks to reach the goal of booting
]> operating systems in UEFI mode on real hardware though.
]corebootPkg boots the Fedora 19 Live DVD on QEmu.
]](http://www.coreboot.org/~patrick/coreboot/2013-10-29-coreboot%2btianocore%2bcsm-qemu-]]i440fx.rom)
]Could you try on real hardware? I'm away from mine for the next couple 
]of days.

I did get this going on ASRock E350M1, at least on simnow.
The biggest problem is that parts are taken from the OVMF
project, which is hard-coded for Intel 440BX chipset in
some aspects. I got it to boot the shell with these changes:

1) Hack in a change to make it use the proper I/O port when
reading the ACPI power management timer. The ideal solution
is to get the ACPI PM timer address from the ACPI tables,
which is what Duet does.
2) Change PCI device and function numbers hard-coded in
bdsplatform.h from 440BX values to AMD SB800 values. Not
sure if this is essential for shell boot.
3) Disable PCI ARI support to eliminate some EDK2 code
crashes. Not sure if the cause of the problem is an EDK2
problem or a simnow model problem.
4) Work around a crash in SmbiosDxe.c. I didn't investigate
the cause.
5) Expand the temporary identity mapped page tables. I
believe they map up to 1GB, and I am using more.
6) Big changes to make it build on Windows using Microsoft
tools. It is really unfortunate that as of 2013, Microsoft
doesn't support C99. I used fasm in place of Microsoft's
assembler because it can assemble a module containing both
32-bit and 64-bit code.

These changes are enough to get the shell on the serial
console. Exiting the shell runs into trouble though.

]edk2 source with (some) documentation can be found at
]https://github.com/pgeorgi/edk2/tree/coreboot-pkg
]
]The image above was built with the GCC47 toolchain, the 64bit issues it 
]had are now fixed.
]
]Like Duet, the resulting payload should be portable across boards since 
]coreboot does the initialization part.
]CSM is useful to initialize video if you only have a PCBIOS style 
]VGABIOS (eg. on QEmu).

I am hoping to avoid use of full CSM. corebootPkg/Csm/CsmSupportLib
has a lot of hard-coding for Intel 440BX. The Duet project uses
an INT 10h wrapper called BiosVideoThunkDxe which can make legacy
video usable. UEFI has native support for most other devices. It
might even be possible to extract the native UEFI GOP video driver
from an OEM UEFI ROM for reuse. But I believe in the case of my
ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.

The biggest work is going to be support for the large NVRAM
area needed by EDK2 UEFI. A generic solution is not possible.
I will start with support for AMD systems.

Thanks,
Scott


]Patrick




-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Patrick Georgi]

Am 2013-11-06 00:28, schrieb Scott Duplichan:

I am working on a project to allow Duet to run as a
coreboot payload, and to fix the major Duet problems.

We had that 4 years ago or so. Want me to look up the code?


It will also continue to support bootable image form.
It may take me a few weeks to reach the goal of booting
operating systems in UEFI mode on real hardware though.

corebootPkg boots the Fedora 19 Live DVD on QEmu.
(http://www.coreboot.org/~patrick/coreboot/2013-10-29-coreboot%2btianocore%2bcsm-qemu-i440fx.rom)
Could you try on real hardware? I'm away from mine for the next couple 
of days.


edk2 source with (some) documentation can be found at
https://github.com/pgeorgi/edk2/tree/coreboot-pkg

The image above was built with the GCC47 toolchain, the 64bit issues it 
had are now fixed.


Like Duet, the resulting payload should be portable across boards since 
coreboot does the initialization part.
CSM is useful to initialize video if you only have a PCBIOS style 
VGABIOS (eg. on QEmu).



Patrick

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Anthony Ross wrote:

]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 

For your freeze problem, how are you debugging? The usual way
is to enable and capture debug messages written to a serial
port. I believe the standard Duet settings make it write
debugging messages to a serial port at 3F8 (115200,8,N,1).
Because halt for assert is enabled by default on Duet, an 
assert is the most likely reason for a freeze. The assert
will log details to the serial port.

If your hardware doesn't have a serial port, you can use
an emulator such as simnow or qemu. A good thing about
Duet is that it is generic and in theory can run on 
different systems without porting. If I remember correctly,
the current Duet project can boot to the UEFI shell and
menu system on AMD simnow using the Solo board model.

I am working on a project to allow Duet to run as a
coreboot payload, and to fix the major Duet problems.
It will also continue to support bootable image form.
It may take me a few weeks to reach the goal of booting
operating systems in UEFI mode on real hardware though.

Thanks,
Scott

On Sat, Oct 26, 2013 at 8:01 PM, Kevin O'Connor  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 0x40
> 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



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Anthony Ross]

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  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 0x40
> > alignment: 0 bytes
> >
> > Name   Offset Type Size
> > cmos_layout.bin0x0cmos_layout  1776
> > pci1002,9802.rom   0x740  optionrom57856
> > fallback/romstage  0xe980 stage345432
> > fallback/coreboot_ram  0x62f40stage203312
> > fallback/payload   0x949c0payload  53738
> > config 0xa1c00raw  3831
> > (empty)0xa2b40null 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
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Kevin O'Connor]

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 0x40
> alignment: 0 bytes
> 
> Name   Offset Type Size
> cmos_layout.bin0x0cmos_layout  1776
> pci1002,9802.rom   0x740  optionrom57856
> fallback/romstage  0xe980 stage345432
> fallback/coreboot_ram  0x62f40stage203312
> fallback/payload   0x949c0payload  53738
> config 0xa1c00raw  3831
> (empty)0xa2b40null 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

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

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  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. 

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Patrick Georgi]

Am Mittwoch, den 23.10.2013, 19:30 +0530 schrieb Anthony Ross:
> 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.
I think I fixed the toolchain error on X64 (now that I finally managed
to reproduce it) and pushed it on my github repo.

You'll need to rebuild the BaseTools:
$ cd BaseTools/Source/C
$ make

Afterwards, corebootPkg should build with the GCC46 toolchain (I used
GCC47) for X64, too.


Patrick



signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Anthony Ross]

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


Well I await for a reply.


Regards


Neo








On Wed, Oct 23, 2013 at 1:00 AM, Scott Duplichan 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

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

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

[coreboot] Help required to boot DUET (Seabios floppy mechanism)

[D945GCCR]

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.








-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot