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