can we include dosfs?

Joel Sherrill joel at rtems.org
Mon Jun 20 02:55:01 UTC 2016


On Jun 19, 2016 8:51 PM, "Ben Gras" <beng at shrike-systems.com> wrote:
>
> 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.
> >
> >
> > Great.
> >
> >> 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
> 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?

Looks like MIT more or less to me. So no license issues that I see.

Review the one Chris suggested though.

> 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.

What's the license say?

> > 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.:
>
>
http://users.ece.utexas.edu/~mcdermot/arch/projects_fall_09/Team_07/umon-1.17/umon_main/target/common/fatfs.c

+1

>
> > Chris
> > _______________________________________________
> > umon-devel mailing list
> > umon-devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/umon-devel
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/umon-devel/attachments/20160619/c6729602/attachment-0002.html>


More information about the umon-devel mailing list