Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
Thanks Michael, I will bring this point to have the discussion with our customer. Thanks, Jim -Original Message- From: Michael Brown [mailto:mc...@ipxe.org] Sent: Friday, January 22, 2016 4:31 PM To: Fu, Siyuan Cc: Jim Hung (洪銘駿); edk2-devel@lists.01.org Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address On 22/01/16 02:59, Fu, Siyuan wrote: > Thanks Michael, maybe use UUID is a good way to solve this issue. But I still > curious why the server has such requirement which is apparent violate the RFC > requirement. Could you provide more details? The DHCPv6 RFC was designed without taking network boot into account. There is no way, for example, for a network bootloader to use the same DUID as the operating system that is going to be booted, since the DUID includes elements of arbitrary choice (e.g. which network device to use for a DUID-LL, and which time to use in a DUID-LLT). RFC 6355 attempts to improve this situation, by suggesting that all DHCPv6 clients should converge on the use of DUID-UUID. This at least eliminates the elements of arbitrary choice, and makes it possible for a bootloader to use the same DUID as the booted operating system. However, many customers (such as yours) are used to creating reservations by MAC address rather than by UUID. With DUID-UUID, the MAC address is not exposed anywhere in the DHCPv6 packet. There is no good solution to this problem at present. Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
On 22/01/16 02:59, Fu, Siyuan wrote: Thanks Michael, maybe use UUID is a good way to solve this issue. But I still curious why the server has such requirement which is apparent violate the RFC requirement. Could you provide more details? The DHCPv6 RFC was designed without taking network boot into account. There is no way, for example, for a network bootloader to use the same DUID as the operating system that is going to be booted, since the DUID includes elements of arbitrary choice (e.g. which network device to use for a DUID-LL, and which time to use in a DUID-LLT). RFC 6355 attempts to improve this situation, by suggesting that all DHCPv6 clients should converge on the use of DUID-UUID. This at least eliminates the elements of arbitrary choice, and makes it possible for a bootloader to use the same DUID as the booted operating system. However, many customers (such as yours) are used to creating reservations by MAC address rather than by UUID. With DUID-UUID, the MAC address is not exposed anywhere in the DHCPv6 packet. There is no good solution to this problem at present. Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] RELEASE build fails due excessive size in FVMAIN_COMPAT
Hello, I have been trying to set up and build ovmf in release mode with FD_SIZE_2MB and SECURE_BOOT_ENABLE set trough GCC49. This used to result in a working build until some time ago, when I started having errors in the final part of the build, due to the size constraints put on FVMAIN_COMPACT. I would need to host a size of 0xcc7b8, while there are only 0xcc000 available. I have been unable to change the configuration to avoid the error, and the few similar happenings on this mailing list refer to config files that no longer exist or have changed deeply enough. Debug build, which I take doesn't include secure boot and other features, fits in fine and successfully build. I would appreciate if someone pointed me in the right direction to build successfully even in release mode. Thanks in advance, Zycorax ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] RELEASE build fails due excessive size in FVMAIN_COMPAT
On 01/22/16 11:19, Zycorax Tokoroa wrote: > Hello, > > I have been trying to set up and build ovmf in release mode with > FD_SIZE_2MB and SECURE_BOOT_ENABLE set trough GCC49. This used to result > in a working build until some time ago, when I started having errors in > the final part of the build, due to the size constraints put on > FVMAIN_COMPACT. I would need to host a size of 0xcc7b8, while there are > only 0xcc000 available. I have been unable to change the configuration > to avoid the error, and the few similar happenings on this mailing list > refer to config files that no longer exist or have changed deeply > enough. Debug build, which I take doesn't include secure boot and other > features, fits in fine and successfully build. I would appreciate if > someone pointed me in the right direction to build successfully even in > release mode. You are using incorrect build options. The (not really intuitive) trick is that the DEBUG build defaults to a 2MB (unified) flash image file, whereas the RELEASE build defaults to a 1MB (unified) flash image file. In each case (DEBUG vs. RELEASE), if you'd like to diverge from the default implied by the build target, you have to specify that explicitly. These would be: - less relevantly: build ... -b DEBUG -D FD_SIZE_1MB - relevantly: build ... -b RELEASE -D FD_SIZE_2MB I claim that you are using the wrong options because you mention while there are only 0xcc000 available Opening "OvmfPkg/OvmfPkg.fdf.inc", you find: !ifdef $(FD_SIZE_1MB) ... DEFINE FVMAIN_SIZE = 0x000CC000 ... !else ... DEFINE FVMAIN_SIZE = 0x001AC000 ... !endif Hence I can tell you are not passing "-D FD_SIZE_2MB" in addition to "-b RELEASE". I've just booted my Fedora 21 virtual machine that I only keep for test-building OVMF with gcc-4.9 if necessary. At git commit 0179180d6dba: pushd CryptoPkg/Library/OpensslLib wget -q -O - http://www.openssl.org/source/openssl-1.0.2e.tar.gz \ | tar -z -x pushd openssl-1.0.2e patch -p 0 -i ../EDKII_openssl-1.0.2e.patch popd ./Install.sh popd source edksetup.sh make -C "$EDK_TOOLS_PATH" build \ -a X64 \ -p OvmfPkg/OvmfPkgX64.dsc \ -t GCC49 \ -n $(getconf _NPROCESSORS_ONLN) \ -b RELEASE \ -D SECURE_BOOT_ENABLE \ -D HTTP_BOOT_ENABLE \ -D FD_SIZE_2MB The build succeeds; the "FV Space Information" is SECFV [11%Full] 212992 total, 25504 used, 187488 free FVMAIN_COMPACT [61%Full] 1753088 total, 1071464 used, 681624 free DXEFV [60%Full] 9437184 total, 5747080 used, 3690104 free PEIFV [16%Full] 917504 total, 154992 used, 762512 free Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/.../IdeMode: correctly report length of returned data
On 21/01/2016 02:27, Tian, Feng wrote: > Paolo, > > I think for short write case it means the data length to be written in > AtaPacketReadWrite, that is ByteCount, is less than the one shipped in ATA > cmd, for example, CDB (READ10.byte7&8). > > For such case, it should jump out the while loop in AtaPacketReadWrite and > send EFI_DEVICE_ERROR as DRQ is not clear. > > IMHO, Laszo & your patch all looks ok to me. of course, your patch did an > enhancement on how to reflect the real transfer data length :) Thanks! Laszlo, can you commit it? Paolo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/.../IdeMode: correctly report length of returned data
On 01/22/16 15:23, Paolo Bonzini wrote: > > > On 21/01/2016 02:27, Tian, Feng wrote: >> Paolo, >> >> I think for short write case it means the data length to be written >> in AtaPacketReadWrite, that is ByteCount, is less than the one >> shipped in ATA cmd, for example, CDB (READ10.byte7&8). >> >> For such case, it should jump out the while loop in >> AtaPacketReadWrite and send EFI_DEVICE_ERROR as DRQ is not clear. >> >> IMHO, Laszo & your patch all looks ok to me. of course, your patch >> did an enhancement on how to reflect the real transfer data length >> :) > > Thanks! Laszlo, can you commit it? Absolutely; I haven't done it already only because Feng didn't send a formal R-b. That fact, combined with "it should ..." in the second paragraph, told me that there were further details to iron out. If that's not the case: Feng, can you please post your Reviewed-by as usual? Then I'll add my own T-b as well (already posted) and commit Paolo's patch. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] RELEASE build fails due excessive size in FVMAIN_COMPAT
(adding back the list, if you don't mind, because this is a good observation you make) On 01/22/16 16:04, Zycorax Tokoroa wrote: >> >> You are using incorrect build options. >> > That seems to be the case. I wasn't using the build -D syntax anymore, > but had added "FD_SIZE_2MB = TRUE SECURE_BOOT_ENABLE = TRUE" to > Conf/target.txt. That seems not to be enough. Correct, Conf/target.txt controls different things. If you reach back to the command line I wrote: build \ -a X64 \ -p OvmfPkg/OvmfPkgX64.dsc \ -t GCC49 \ -n $(getconf _NPROCESSORS_ONLN) \ -b RELEASE \ -D SECURE_BOOT_ENABLE \ -D HTTP_BOOT_ENABLE \ -D FD_SIZE_2MB Conf/target.txt controls the arguments to the options that the "build" utility itself consumes: -a <--> TARGET_ARCH -p <--> ACTIVE_PLATFORM -t <--> TOOL_CHAIN_TAG -n <--> MAX_CONCURRENT_THREAD_NUMBER -b <--> TARGET These are not specific to any platform DSC file. The various macro definitions are however consumed by the specific platform DSC that you designate with the -p (ACTIVE_PLATFORM) option, plus by the FDF file that the platform DSC itself designates with FLASH_DEFINITION. For setting such macros in "Conf/target.txt", you would need some (repeatable) keyword in there that stood for the -D option of "build". I don't think one exists. If you'd like to make the macro definitions permanent, you'll have to carry a patch that modifies the macro defaults in OvmfPkg/OvmfPkgX64.dsc: [Defines] ... # # Defines for default states. These can be changed on the command line. # -D FLAG=VALUE # DEFINE SECURE_BOOT_ENABLE = FALSE DEFINE NETWORK_IP6_ENABLE = FALSE DEFINE HTTP_BOOT_ENABLE= FALSE DEFINE SMM_REQUIRE = FALSE ... In any case, your recent addition makes me check another thing: namely, if you tried to set SECURE_BOOT_ENABLE *also* in the "Conf/target.txt" file only, then it didn't take effect, similarly to FD_SIZE_2MB. Which tells me that "-b RELEASE" doesn't build with GCC49 (due to size) even without including secure boot support. It works with gcc-4.8 -- the following succeeds: build \ -a X64 \ -p OvmfPkg/OvmfPkgX64.dsc \ -t GCC48 \ -n $(getconf _NPROCESSORS_ONLN) \ -b RELEASE but it is getting tight in the 1MB unified flash image: FV Space Information SECFV [30%Full] 81920 total, 25312 used, 56608 free FVMAIN_COMPACT [99%Full] 835584 total, 832728 used, 2856 free DXEFV [44%Full] 9437184 total, 4230752 used, 5206432 free PEIFV [16%Full] 917504 total, 151440 used, 766064 free (See 99% full, 2856 free.) Trying the same command with gcc-4.9: build \ -a X64 \ -p OvmfPkg/OvmfPkgX64.dsc \ -t GCC49 \ -n $(getconf _NPROCESSORS_ONLN) \ -b RELEASE I do get the build failure you reported: the required fv image size 0xccaf8 exceeds the set fv image size 0xcc000 (I haven't encountered this earlier because I exclusively build for -b DEBUG, with its default 2MB unified flash image size. Plus, I'm on RHEL-7.2.z, which provides gcc-4.8 by default.) Jordan, do you have a suggestion how to deal with this? I think the simplest would be to default to FD_SIZE_2MB for -b RELEASE as well. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
