Re: [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups

[Paulo Alcantara <pcacjr@zytor.com>]

On 10/09/2017 11:27, Shi, Steven wrote:
> OK. Does the UDF image you created correctly show up as CD-ROM content in Linux, e.g Fedora?

The Fedora image I have (Fedora-Workstation-Live-x86_64-26-1.5.iso) does 
not contain a valid UDF file system, so you cannot use it for testing.

To make sure it really doesn't, I used a "Philips UDF Conformance Tool" 
that you can grab in [1], and the tool didn't find any valid UDF file 
system in it.

I've been using an unmodified Windows 10 Enterprise image that does 
contain a valid UDF bridge disk image (ISO9660+ElTorito+UDF) to perform 
my tests.

Additionally, I use an USB stick that I format it with 'sudo mkudffs -b 
512 --media-type=hd /dev/sdX' and copy some files to it for testing

BTW, when testing with OVMF AARCH64, I was using my USB stick that 
showed up correctly as 'fsX' in UEFI shell, but with the Windows 10 
Enterprise ISO image, it didn't. I looked at the logs to see what was 
going on and I found out that the emulated CD-ROM drive is reporting a 
block size of 512 instead of 2048 -- which seems wrong to me. With 
'qemu-system-x86_64 -cdrom', it reports a block size of 2048.

The Partition driver is still able to find a valid ElTorito partition 
because, regardless the device block size, it always use a logical block 
size of 2048 starting at 32K. In UDF, when searching for AVDPs (Anchor 
Volume Descriptor Pointers), we search for them at fixed locations: 256, 
N - 256, N and 512 -- but, with a block size of 512, the locations 
change to 1024, N - 1024, N and 2048 -- thus breaking the volume 
recognition sequence.

For testing the Windows image with a block size of 512, I used the 
comformance tool with './udf_test -verbose 60 -blocksize 512 
~/img/win_ent10.iso' and it failed to find a valid UDF file system. But 
with a block size of 2048, it worked.

Is there any reason for reporting a block size of 512 when using 
'-cdrom' option in qemu-system-aarch64? Is that a bug? Or am I missing 
something here?

Thanks!
Paulo

[1] - https://www.lscdweb.com/registered/udf_verifier.html

> 
> 
> Steven Shi
> Intel\SSG\STO\UEFI Firmware
> 
> Tel: +86 021-61166522
> iNet: 821-6522
> 
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Sunday, September 10, 2017 9:52 PM
>> To: Shi, Steven <steven.shi@intel.com>; edk2-devel-01 <edk2-
>> devel@lists.01.org>
>> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Dong, Eric <eric.dong@intel.com>; Zeng,
>> Star <star.zeng@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Subject: Re: [edk2] [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups
>>
>> Hi Steven,
>>
>> On 09/10/17 10:38, Laszlo Ersek wrote:
>>> On 09/10/17 06:24, Shi, Steven wrote:
>>>> Hi Laszlo,
>>>> How could we configure the Qemu and test the UDF driver on OVMF?
>>>
>>> I guess you would format e.g. a DVD image with UDF, and attach it to
>>> QEMU like any other CD-ROM.
>>
>> I tried to look into this -- I tried several things, but nothing
>> produced an UDF image file that, when attached to the VM, would show up
>> in the UEFI shell as FSn:
>>
>> Google returned a bunch of pages, but all I found was:
>> - tips that didn't work (see above),
>> - confused users (like me) looking for solutions.
>>
>> So, at the moment, I have no idea how authoring UDF DVD images is
>> possible on Linux, so that they'd be recognized in edk2.
>>
>> (I'm interested in the edk2 UDF driver not because I want to "author"
>> UDF DVD images (ISO9660+ElTorito works just fine), but because some
>> optical media images that were given to me are formatted UDF-only. They
>> can be translated into ISO9660+ElTorito off-line, but that's a chore.)
>>
>> Thanks,
>> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>