can we include dosfs?

Ben Gras beng at
Mon Jun 20 02:51:10 UTC 2016

On Mon, Jun 20, 2016 at 4:33 AM, Chris Johns <chrisj at> 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.
> Great.
>> It seems umon doesn't read FAT filesystems. Does anyone see any
>> license objection to including
>> dosfs.c ( as seems to have happened
>> with the original umon?
> How does that implementation compare with
> This is used by Xilinx in the
> first stage bootloader.

They look similar enough. They both rely on some low-level device
access functions
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,
clearer with
the no-strings-attached language, and I know it has been hooked up to
umon before,
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.:

> Chris
> _______________________________________________
> umon-devel mailing list
> umon-devel at

More information about the umon-devel mailing list