Hi,
This is my first query on this list. I apologize for any mistake.
I have some queries on following patch : https://lists.linaro.org/pipermail/boot-architecture/2013-June/000325.html
I am not able to see this patch in master branch. Is this patch tested? Also I want to know the underline firmware volume on which this patch has been tested?
Thanks & regards Meenakshi Aggarwal
+ edk2 list and authors of the patch
Regards, Bhupesh
-----Original Message----- From: boot-architecture [mailto:boot-architecture- bounces@lists.linaro.org] On Behalf Of Meenakshi Aggarwal Sent: Wednesday, July 01, 2015 6:29 PM To: boot-architecture@lists.linaro.org Subject: Ext2/Ext3 filesystem support
Hi,
This is my first query on this list. I apologize for any mistake.
I have some queries on following patch :
https://lists.linaro.org/pipermail/boot-architecture/2013- June/000325.html
I am not able to see this patch in edk2 master branch. Is this patch tested? Also I want to know the underline firmware volume on which this patch has been tested?
Thanks & regards Meenakshi Aggarwal
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Hi Meenakshi,
On Wed, Jul 01, 2015 at 12:59:12PM +0000, Meenakshi Aggarwal wrote:
This is my first query on this list. I apologize for any mistake.
None spotted.
I have some queries on following patch : https://lists.linaro.org/pipermail/boot-architecture/2013-June/000325.html
I am not able to see this patch in master branch.
Correct.
It was dropped from the release tree since it contains code under a different license (GPL) than upstream EDK2 or our platform support code (BSD).
Is this patch tested?
Yes.
Also I want to know the underline firmware volume on which this patch has been tested?
We verified it (at least) on the microSD card on the Samsung Arndale board.
Regards,
Leif
On 07/08/2015 07:24 AM, Leif Lindholm wrote:
On Wed, Jul 01, 2015 at 12:59:12PM +0000, Meenakshi Aggarwal wrote:
This is my first query on this list. I apologize for any mistake.
This is also my first query on the list. :-)
Is this patch tested?
Yes.
Also I want to know the underline firmware volume on which this patch has been tested?
We verified it (at least) on the microSD card on the Samsung Arndale board.
Forgetting the licensing issue, would the Ext2 FS driver need to be embedded in the main firmware volume, or could it be in a .efi file in a FAT-based ESP? I am wondering if it'd be technically possible for a system with a main firmware volume that only recognizes FAT would be able to load and use the Ext2 FS driver, since most IBVs only ship FAT support (except Apple which apparently supports both FAT and HFS+) for ESP.
What about UDF for non-FAT ESP FS? UDF was checked into TianoCore a while ago, so BSD licensed. Unlike FAT, I am not aware of any UDF IP issues. UDF has OS-level FS/tool issues, but some of those edge cases could be fixed. UDF also supports large files, which would be useful for some pre-OS config issues where you need to mess with .ISO or .img files to setup a system, FAT-only FS support would be not helpful. Mainstream IBVs will not likely support a Linux-only FS, but UDF is a lot more neutral and less scary, Microsoft already supports UDF. Anyway, just a thought, for a more IP-free ESP FS... http://sourceforge.net/p/edk2/mailman/message/33187675/
Thanks, Lee RSS: http://firmwaresecurity.com/feed
-----Original Message----- From: boot-architecture [mailto:boot-architecture- bounces@lists.linaro.org] On Behalf Of Blibbet Sent: Wednesday, July 08, 2015 9:53 PM On 07/08/2015 07:24 AM, Leif Lindholm wrote:
On Wed, Jul 01, 2015 at 12:59:12PM +0000, Meenakshi Aggarwal wrote:
This is my first query on this list. I apologize for any mistake.
This is also my first query on the list. :-)
Is this patch tested?
Yes.
Also I want to know the underline firmware volume on which this patch has been tested?
We verified it (at least) on the microSD card on the Samsung Arndale board.
Forgetting the licensing issue, would the Ext2 FS driver need to be embedded in the main firmware volume, or could it be in a .efi file in a FAT-based ESP? I am wondering if it'd be technically possible for a system with a main firmware volume that only recognizes FAT would be able to load and use the Ext2 FS driver, since most IBVs only ship FAT support (except Apple which apparently supports both FAT and HFS+) for ESP.
What about UDF for non-FAT ESP FS? UDF was checked into TianoCore a while ago, so BSD licensed. Unlike FAT, I am not aware of any UDF IP issues. UDF has OS-level FS/tool issues, but some of those edge cases could be fixed. UDF also supports large files, which would be useful for some pre- OS config issues where you need to mess with .ISO or .img files to setup a system, FAT-only FS support would be not helpful. Mainstream IBVs will not likely support a Linux-only FS, but UDF is a lot more neutral and less scary, Microsoft already supports UDF. Anyway, just a thought, for a more IP-free ESP FS... http://sourceforge.net/p/edk2/mailman/message/33187675/
Hmmm. Does UDF support flash devices like a NOR or NAND flash, which is usually the default booting source on most ARM based boards. AFAIK, UDF is mainly a mechanism suited best for optical disks and DVDs, so I am not sure it can support the usual boot devices on ARM based boards, like: - NOR flash. - NAND flash. - SD card. - SPI flash.
So, while we are on the right track when we say that Linux-only FS, may not find many takers in the EDK2 world, but does UDF solve the issue of handling flashes which are the primary boot sources on ARM platforms, rather than HDDs or Optical Disks on a x86?
Or, should we be looking at the GPIL + X11 dual-licensed licensing format for such components like ext2/ext3 support in future. This dual-license is already used for licensing Linux Device-tree (see [1]). Since X11 is pretty similar to BSD licensing, the prospect of work licensed under this dual-license are better in terms of re-use.
[1] http://lxr.free-electrons.com/source/arch/arm64/boot/dts/freescale/fsl-ls208...
On Wed, Jul 08, 2015 at 09:22:32AM -0700, Blibbet wrote:
On 07/08/2015 07:24 AM, Leif Lindholm wrote:
On Wed, Jul 01, 2015 at 12:59:12PM +0000, Meenakshi Aggarwal wrote:
This is my first query on this list. I apologize for any mistake.
This is also my first query on the list. :-)
Is this patch tested?
Yes.
Also I want to know the underline firmware volume on which this patch has been tested?
We verified it (at least) on the microSD card on the Samsung Arndale board.
Forgetting the licensing issue, would the Ext2 FS driver need to be embedded in the main firmware volume, or could it be in a .efi file in a FAT-based ESP?
Should work. Don't know if anyone tested it.
I am wondering if it'd be technically possible for a system with a main firmware volume that only recognizes FAT would be able to load and use the Ext2 FS driver, since most IBVs only ship FAT support (except Apple which apparently supports both FAT and HFS+) for ESP.
Yes, that should be doable. I think that's how rEFInd works.
What about UDF for non-FAT ESP FS? UDF was checked into TianoCore a while ago, so BSD licensed. Unlike FAT, I am not aware of any UDF IP issues.
FAT is still the filesystem mandated by the spec, so without FAT support, it's not really UEFI.
/ Leif
On 07/08/2015 09:19 PM, Sharma Bhupesh wrote: ...
What about UDF for non-FAT ESP FS? [...] http://sourceforge.net/p/edk2/mailman/message/33187675/
Hmmm. Does UDF support flash devices like a NOR or NAND flash, which
is usually
the default booting source on most ARM based boards. AFAIK, UDF is
mainly a mechanism
suited best for optical disks and DVDs, so I am not sure it can
support the
usual boot devices on ARM based boards, like: - NOR flash. - NAND flash. - SD card. - SPI flash.
So, while we are on the right track when we say that Linux-only FS,
may not find many
takers in the EDK2 world, but does UDF solve the issue of handling
flashes which are the primary
boot sources on ARM platforms, rather than HDDs or Optical Disks on a x86?
Or, should we be looking at the GPIL + X11 dual-licensed licensing
format for such components like
ext2/ext3 support in future. This dual-license is already used for
licensing Linux Device-tree (see [1]).
Since X11 is pretty similar to BSD licensing, the prospect of work
licensed under this dual-license
are better in terms of re-use.
[1]
http://lxr.free-electrons.com/source/arch/arm64/boot/dts/freescale/fsl-ls208...
I've only used UDF on hard drives and discs, not flash, so I don't have an answer for you, sorry.
Note that in addition to UDF, Intel also recently contributed another UFS (Universal Flash Storage) file system to UEFI, which might be more appropriate answer.
Having an existing BSD-licensed UDF and UFS in TianoCore is nice.
http://sourceforge.net/p/edk2/mailman/message/34067176/ https://en.wikipedia.org/wiki/Universal_Flash_Storage
I'm also replying to a follow-up comment:
On 07/09/2015 06:18 AM, Leif Lindholm wrote: ...
What about UDF for non-FAT ESP FS? UDF was checked into TianoCore a while ago, so BSD licensed. Unlike FAT, I am not aware of any UDF IP issues.
FAT is still the filesystem mandated by the spec, so without FAT support, it's not really UEFI.
But that's just what UEFI currently is, defined by Microsoft, who gains from the IP issues by forcing all to use FAT forever. Linux vendors can change things by joining UEFI Forum, filing an issue, and changing UEFI. Currently, Linaro, Canonical, Red Hat, and SuSE are members of the UEFI Forum, so they can help change things. Microsoft will likely add new restrictions for Windows OEMs, but that's only the bulled section of the playground, other OEMs don't have to follow those restrictions. Convincing generic BIOS vendors to support non-FAT file systems of any type will be hard.
For some server and embedded solutions, where vendor can build their own firmware, and use won't attempt to install Windows on it, a FAT-free solution with an appropriate FS for the task would seem like an improvement to FAT-only for all future UEFI hardware (except for Apple).
boot-architecture@lists.linaro.org
-
Blibbet -
Leif Lindholm -
Meenakshi Aggarwal -
Sharma Bhupesh