Re: [PATCH v5] sim: bfin: new port

Mike Frysinger
2011-03-02T02:23:09Z

[-- Attachment #1: Type: Text/Plain, Size: 2509 bytes --]

On Tuesday, March 01, 2011 20:13:34 Pedro Alves wrote:
> On Tuesday 01 March 2011 22:02:21, Mike Frysinger wrote:
> > On Tuesday, March 01, 2011 16:19:25 Pedro Alves wrote:
> > > On Tuesday 22 February 2011 20:26:44, Mike Frysinger wrote:
> > > > --- /dev/null
> > > > +++ b/sim/bfin/linux-fixed-code.h
> > > > @@ -0,0 +1,23 @@
> > > > +/* DO NOT EDIT: Autogenerated. */
> > > > +/* Fixed code region of Linux userspace starting at 0x400. Last
> > > > produced + from Linux-2.6.37 (not that the fixed code region
> > > > changes often). */ +static const unsigned char
> > > > bfin_linux_fixed_code[] = { +0x28, 0xe1, 0xad, 0x00, 0xa0, 0x00,
> > > > 0x00, 0x20,
> > >
> > > (...)
> > >
> > > > +0xa4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > +};
> > >
> > > Now this kernel code in question was probably (haven't
> > > checked) largely written by ADI, and as such ADI could
> > > probably contribute a standalone version of its source
> > > to the FSF under GPLv3, along with some script or makefile
> > > that compiles it with a bfin-gcc and then generates
> > > the blob array. Or you could write simple dumb
> > > replacement implementations of the interface instead?
> >
> > this code was written purely by ADI employees (2 or 3 of them to be
> > exact), is written in pure Blackfin assembly, and we've explicitly
> > licensed this file under GPLv2 or later. so i dont think this is an
> > issue. it is not used by the kernel at all ... the code is placed in a
> > fixed location for userspace binaries to call and is defined as part of
> > the Blackfin ABI. see below.
>
> Thanks. Since the Linux kernel is a mixture of code under GPLv2
> and `GPLv2 or later', the resulting compiled binary is GPLv2
> only (not later), so it's still an issue to dump from
> the kernel binary. And I think only the interface is
> defined as part of the ABI, not the implementation?
>
> To comply with the GPL, we need to provide the source of
> that blob. I guess it's easy to do what I suggested
> above then? Then the GPLv2-only of the Linux kernel
> won't apply, and we're all happy.

i want to avoid gcc to avoid the chicken&egg issue. an .s should be fine
since gdb is in the same tree as the assembler (and this code doesnt really
need CPP magic).

but i'd like to avoid this step when possible, so how about including the
generated file too, and adding a makefile target so that it is regenerated
whenever the .s changes ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]