can we include dosfs?
beng at shrike-systems.com
Mon Jun 20 02:51:10 UTC 2016
On Mon, Jun 20, 2016 at 4:33 AM, Chris Johns <chrisj at rtems.org> wrote:
> On 20/06/2016 12:24, Ben Gras wrote:
>> I'm looking at building umon from RSB, to replace uboot, the next step
>> to mainlining all the beagle bsp support.
>> It seems umon doesn't read FAT filesystems. Does anyone see any
>> license objection to including
>> dosfs.c (http://www.zws.com/products/dosfs/) as seems to have happened
>> with the original umon?
> How does that implementation compare with
> http://elm-chan.org/fsw/ff/00index_e.html? This is used by Xilinx in the
> first stage bootloader.
They look similar enough. They both rely on some low-level device
to be provided by the user, which is fine. The license isn't terribly
clear I think:
/ FatFs module is a free software that opened under license policy of
/ following conditions.
/ Copyright (C) 2016, ChaN, all right reserved.
/ 1. Redistributions of source code must retain the above copyright notice,
/ this condition and the following disclaimer.
/ This software is provided by the copyright holder and contributors "AS IS"
/ and any warranties related to this software are DISCLAIMED.
/ The copyright owner or contributors be NOT LIABLE for any damages caused
/ by use of this software.
Do you think we can include it?
The dosfs license is, though unfortunately not any standard license,
the no-strings-attached language, and I know it has been hooked up to
so that seems lower-risk to me at the moment.
> I also have a JFFS bootloader implementation that can be added so umon can
> be booted from a JFFS2.
>> Can we then include the original umon CLI interface or is that a
>> license issue? If so I can re-implement it.
> I do not know and yes it would be nice to use what is available.
Let's see what Ed says about including the CLI code. It is e.g.:
> umon-devel mailing list
> umon-devel at rtems.org
More information about the umon-devel