Hi,
I am Luke Yang, an engineer from Analog Devices Inc. We ported
uclinux to our Blackfin cpu. Now we updated our architecture code for
kernel-2.6.13. I will send out a patch to this list.
I know kernel-2.6.14 is coming. Will the linux kernel accept our
patch for 2.6.13?
Regards,
Luke Yang
On Sep 20 2005, at 14:33, Luke Yang was caught saying:
> Hi,
>
> I am Luke Yang, an engineer from Analog Devices Inc. We ported
> uclinux to our Blackfin cpu. Now we updated our architecture code for
> kernel-2.6.13. I will send out a patch to this list.
>
> I know kernel-2.6.14 is coming. Will the linux kernel accept our
> patch for 2.6.13?
Nope. 2.6.13 is now closed to new features as is 2.6.14 (unless it is
a really sper special case that Linus feels is important enough to slip
in). At this point the best thing to do is to post your patches for review,
make the changes that are asked, and be ready to post a patch vs 2.6.14
within the first week after it is released so that it might be be picked
up for 2.6.15.
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
Even a stopped clock gives the right time twice a day.
Hi all,
This is the ADI Blackfin patch for kernel 2.6.13. I know this
patch doesn' meet the kernel patch submission format, but this patch
is only for reviewing, shows the changes we made. And I'll send new
patch for kernel 2.6.14 for you to merge into kernel.
This patch mainly includes the arch/bfinnommu architecture files
and some blackfin specific drivers. The only change to the common
files is that we change binfmt.c and related header file, added one
flat binary format for blackfin. We are considering removing this
change in next release.
The patch is too big to put here , url is
http://blackfin.uclinux.org/frs/download.php/570/bfinnonnu-linux-2.6.13.patch
Thanks!
Luke
On 9/20/05, Deepak Saxena <[email protected]> wrote:
> On Sep 20 2005, at 14:33, Luke Yang was caught saying:
> > Hi,
> >
> > I am Luke Yang, an engineer from Analog Devices Inc. We ported
> > uclinux to our Blackfin cpu. Now we updated our architecture code for
> > kernel-2.6.13. I will send out a patch to this list.
> >
> > I know kernel-2.6.14 is coming. Will the linux kernel accept our
> > patch for 2.6.13?
>
> Nope. 2.6.13 is now closed to new features as is 2.6.14 (unless it is
> a really sper special case that Linus feels is important enough to slip
> in). At this point the best thing to do is to post your patches for review,
> make the changes that are asked, and be ready to post a patch vs 2.6.14
> within the first week after it is released so that it might be be picked
> up for 2.6.15.
>
> ~Deepak
>
> --
> Deepak Saxena - [email protected] - http://www.plexity.net
>
> Even a stopped clock gives the right time twice a day.
>
On Fri, Sep 23, 2005 at 01:37:03PM +0800, Luke Yang wrote:
> This patch mainly includes the arch/bfinnommu architecture files and
> some blackfin specific drivers.
Having in mind the pain with arm and m68k with and without MMU, could
you structure that thing in a way that it will be able to share the
current nommu code with (hopefully coming) code for blackfins which
might have a MMU? So it would be something like arch/blackfin.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
On Friday 23 September 2005 07:37, Luke Yang wrote:
> Hi all,
>
> This is the ADI Blackfin patch for kernel 2.6.13. I know this
> patch doesn' meet the kernel patch submission format, but this patch
> is only for reviewing, shows the changes we made. And I'll send new
> patch for kernel 2.6.14 for you to merge into kernel.
>
> This patch mainly includes the arch/bfinnommu architecture files
> and some blackfin specific drivers. The only change to the common
> files is that we change binfmt.c and related header file, added one
> flat binary format for blackfin. We are considering removing this
> change in next release.
>
> The patch is too big to put here , url is
> http://blackfin.uclinux.org/frs/download.php/570/bfinnonnu-linux-2.6.13.patch
>
Hi Luke,
Since you ask for review I decided to give you a hand.
I've started to look through your patch and started out by looking through
the documentation bits
Documentation/blackfin/00-INDEX
Documentation/blackfin/Filesystems
Documentation/blackfin/cache-lock.txt
Documentation/uml/UserModeLinux-HOWTO.txt
and I have a few suggested changes (see attached patch).
I'll be taking a look at the rest of the patch as well, just wanted to send you
the bits I'd already done for the documentation - its a pretty large patch, so
I'm going through it in little bits :)
Hope this is useful to you. More feedback on its way.
--
Jesper Juhl <[email protected]>
On Friday 23 September 2005 07:37, Luke Yang wrote:
> Hi all,
>
> This is the ADI Blackfin patch for kernel 2.6.13. I know this
> patch doesn' meet the kernel patch submission format, but this patch
> is only for reviewing, shows the changes we made. And I'll send new
> patch for kernel 2.6.14 for you to merge into kernel.
>
> This patch mainly includes the arch/bfinnommu architecture files
> and some blackfin specific drivers. The only change to the common
> files is that we change binfmt.c and related header file, added one
> flat binary format for blackfin. We are considering removing this
> change in next release.
>
> The patch is too big to put here , url is
> http://blackfin.uclinux.org/frs/download.php/570/bfinnonnu-linux-2.6.13.patch
>
Ok, I went through the files in arch/bfinnommu/kernel/ and I have some
comments (I don't have the time to look at the rest of it).
I think you need to do some work before merging this.
I've attached a patch (compressed due to its size) that contain all the
changes I refer to below. It's just one big patch with all the changes I
made while I went through the files. It's not split out into logically
seperate changes - sorry. I just made different types of changes along the
way, and the attached patch is the result.
You need to clean this stuff up with respect to CodingStyle. Currently the
files are quite inconsistent in the style(s) they use, and they don't follow
the kernels CodingStyle very closely either.
You have a lot of very deeply nested code (especially in dma.c) that is quite
hard to follow and also violates the 80column rule. Try to reduce the nesting
depth.
I've made most of the code fit in 80 columns, but I've probably missed a few
spots.
the *_interrupt functions in dma.c are just begging for a few helper functions
to share common code and reduce complexity. I've reordered them a bit to make
them more readable, but there's lots more that could be done.
There's *lots* of trailing whitespace all over the place. Please get rid of
that prior to merging.
There's *lots* of cases of mixing of spaces and tabs for indentation. Indent
with tabs only please, and certainly don't have lines like
"<space><tab><space><space><space><space><tab>code"
like you have at the moment.
I've cleaned up all the trailing whitespace, and some of the other space+tab
braindamage, but there's probably still something left to do.
There are quite a lot of casts in the code, and some of them are completely
pointless. There's no need to cast the return value of kmalloc(), there's no
need to cast assignments to/from void pointers, there's no need to cast
assignments between types where normal C promotion rules obtain the same
result.
Such unnesesary casting is harmful. It defeats what limited typechecking C
has, so the compiler can't help and warn when you do something bad, it also
lessens the usefullnes of tools such as sparse.
I've cleaned up some of this, but not everything.
You seem to be quite fond of MixingCapsAndLowercaseChars in variable names.
Please don't unless you really have to. Stick to purely lowercase for variable
names as much as possible.
I've renamed a few vars, just as examples.
I stumbled across some unused variables as well that I removed, but there may
be more.
I've cleaned up a lot of other CodingStyle issues as well. Check the attached
patch and you'll see.
In dma.c :
DMA_RESULT set_dma_transfer_size(unsigned int channel, char size)
DMA_RESULT get_dma_transfer_size(unsigned int channel, unsigned short *size)
Seems inconsistent. Why "char size" for set_dma_transfer_size(), but
"unsigned short *size" for get_dma_transfer_size() ??
An if char is what you want to use for size in set_dma_transfer_size(), then
shouldn't that be "unsigned char" ?
I think that's all, read the patch (or apply it and look at the results) to
get all the details. Now I'll go get some sleep...
Ohh, before I leave, one more note: I have no way at all to test this code,
so it's quite possible I've made mistakes in the patch I'm attaching, so do
review it carefully before applying bits from it.
--
Jesper Juhl <[email protected]>
We really don't have plan about Blackfin with a MMU now. So do you
beleve it is necessary to change the name to arch/blackfin?
On 9/24/05, Robert Schwebel <[email protected]> wrote:
> On Fri, Sep 23, 2005 at 01:37:03PM +0800, Luke Yang wrote:
> > This patch mainly includes the arch/bfinnommu architecture files and
> > some blackfin specific drivers.
>
> Having in mind the pain with arm and m68k with and without MMU, could
> you structure that thing in a way that it will be able to share the
> current nommu code with (hopefully coming) code for blackfins which
> might have a MMU? So it would be something like arch/blackfin.
>
> Robert
> --
> Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
>
>
On Tue, Sep 27, 2005 at 09:37:59AM +0800, Luke Yang wrote:
> We really don't have plan about Blackfin with a MMU now. So do you
> beleve it is necessary to change the name to arch/blackfin?
Hmm, as far as I know there are at least plans for variants with memory
protection units (but without virtual addressing), but anyway - why put
the mmu into the architecture name? If you use "blackfin" you are open
to everything and no non dsp guru has to guess what bf might be ;)
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
>Hi,
Hi,
> I am Luke Yang, an engineer from Analog Devices Inc. We ported
>uclinux to our Blackfin cpu. Now we updated our architecture code for
>kernel-2.6.13. I will send out a patch to this list.
Does this patch is only for Blackfin processor or it add some support for fusiv
[1] communications processor that are in residential Gateway ?
If no, do you know if analog plans to realease the linux 2.4/2.6 modification
that have been made in order to support these processors ?
IRRC some Sagem residential Gateways[2] (will) run on
Linux OS and the users sould be able ask for the GPL code.
Jacques
[1] http://www.analog.com/en/prod/0,2877,AD6502,00.html
[2] http://www.sagem.com/index.php?id=193&L=0
On Sat 10/22/2005, Jacques asked:
>Does this patch is only for Blackfin processor or it add some support for
>fusiv [1] communications processor that are in residential Gateway ?
The Blackfin/uClinux 2.6.x patch which was prepared (and will be
maintained) by a separate team(1) who is not working on any fusiv
processors (which are MIPS-based).
>If no, do you know if analog plans to realease the linux 2.4/2.6
>modification that have been made in order to support these processors ?
Not sure - Since the two groups are separate, no one on the team here knows
the plans of the Fusiv team.
>IRRC some Sagem residential Gateways (will) run on Linux OS and the users
>sould be able ask for the GPL code.
So, the best place to go would be to Sagem (or any company shipping a
product with Embedded Linux/uClinux). Since they are responsible for
distributing the binary, it is their responsibility to make the source
released under GPL or derived from previously GPL'ed software available.
If you received a product from Sagem, which you believe includes GPL'ed
software - call them and ask for the source:
http://www.sagem.com/index.php?id=445&L=0
If you received a development kit, or other reference design from ADI,
which you believe includes GPL'ed software, call them and ask for the source:
http://www.analog.com/salesdir/continent.asp
Thanks
-Robin
<shameless plug>
(1)There is a small group of open source developers inside of ADI, focusing
on the support of the Blackfin processor with various open source projects.
We have people dedicated to:
- the FSF's Toolchain (gcc, gdb, binutils) where our patches have
been accepted into the mainline projects (still working on the
last kinks gdb pthreads support).
- Das U-Boot as our chip initialization and bootloader. Booting from the
network is very powerful in many embedded environments.
- the GNU/uClinux kernel (Luke's recent patch for 2.6.14), where end
products are beginning to ship in volume.
- open source hardware design - free (speech) software isn't any good
on closed hardware. All of our schematics, gerbers, PCB manufacturing
files are released under the GPL, and are mostly avalible from
Digikey, at sub $225 price points.
- Simulation support with Skyeye
http://gro.clinux.org/forum/forum.php?forum_id=2619
Our team completely embraces the open source model (release early, release
often) - using open source tools (GForge, Tinderbox, cvs, dokuwiki),
publishing everything we do/understand on the web(2). We have been
responsible for contributions in other open source projects:
- helped port Linux Test Project (LTP) so it could run on a
uClinux/uclibc/no-mmu environment
- helped port Speex to the Blackfin, to run a completely open
source embedded VoIP phone, based on Linphone.
- helping update uClinux-dist to other main-line projects.
- others, but I am starting to get a little wordy.
The combination of Blackfin/uClinux is pretty compelling - the hardware(3)
has a pretty good span of price(as low as $4.95)/performance(BF561 include
Dual Core, 600MHz each) & I won't go into the benefits of uClinux and open
source here :)
If anyone is interested in looking at things running on real hardware, I do
have a limited amount of hardware I can lend people for poking/porting.
Some of the things we have working are pretty cool[4]. Send me a private email.
</shameless plug>
[2]http://blackfin.uclinux.org
[2]http://docs.blackfin.uclinux.org
[2]http://cvs.blackfin.uclinux.org
[3]http://www.analog.com/processors/processors/blackfin/index.html
[4]http://www.linuxdevices.com/articles/AT9272421886.html