Hi all,
This is the Blackfin archtecture patch for kernel 2.6.16. This
patch include header files and arch files, which are hard to split.
Thus the patch size is big, I hope that is OK for a new architecture
patch. For the other driver patches, I'll send them one by one in
small size. Thanks!
Because of the big size, I put it here:
http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2
Signed off by: Luke Yang <[email protected]>
--
Best regards,
Luke Yang
[email protected]; [email protected]
Hi,
Anyone like to review this patch? Any comment or suggestion is
appreciated. If you have questions, send me mails.
Thank you in advance!
Regards,
Luke Yang <[email protected]>
On 3/20/06, Luke Yang <[email protected]> wrote:
> Hi all,
>
> This is the Blackfin archtecture patch for kernel 2.6.16. This
> patch include header files and arch files, which are hard to split.
> Thus the patch size is big, I hope that is OK for a new architecture
> patch. For the other driver patches, I'll send them one by one in
> small size. Thanks!
>
> Because of the big size, I put it here:
> http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2
>
> Signed off by: Luke Yang <[email protected]>
>
> --
> Best regards,
> Luke Yang
> [email protected]; [email protected]
>
--
Best regards,
Luke Yang
[email protected]; [email protected]
"Luke Yang" <[email protected]> wrote:
>
> This is the Blackfin archtecture patch for kernel 2.6.16.
>
There are few practical issues we need to be concerned about with new
architectures.
- We don't want to be putting 44000 lines of new code in the kernel and
then have it rot. Who will support this in the long-term? What
resources are behind it? IOW: what can you say to convince us that it
won't rot?
The lack of a MAINTAINERS entry doesn't inspire confidence..
- How widespread/popular is the blackfin? Are many devices using it?
How old/mature is it? Is it a new thing or is it near end-of-life?
It's a cost/benefit thing. It costs us to add code to the kenrel. How
many people would benefit from us doing that?
- Are easy-to-install x86 cross-build packages available? If not, are
there straightforward instructions anywhere to guide people in generating
a cross-build setup?
<looks>
OK, blackfin.uclinux.org seems to have that. Does binutils support
blackfin?
- A lot of this code appears to come from Analog Devices, but you don't ;)
We'd need to see some sort of authorisation from the original authors
for the inclusion of their code. Preferably in the form of
Signed-off-by:s.
> http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2
As I said, 44kloc ;)
- Do you really need to support old_mmap()?
- It would be preferable to use the generic IRQ infrastructure in kernel/irq/
- Too much use of open-coded `volatile'. The objective should be to have
zero occurrences in .c files. And volatile sometimes creates suspicion
even when it's used in .h files.
- bug: coreb_ioctl() does copy_from_user() and down() inside spinlock.
- err, coreb_ioctl() does down(&file->f_dentry->d_inode->i_sem); but
that's a mutex now, so I assume that's actually dead code?
Luke is probably still asleep at this time of night, so I'll try to
answer what I can...
Andrew Morton wrote:
> "Luke Yang" <[email protected]> wrote:
>> This is the Blackfin archtecture patch for kernel 2.6.16.
>
> - We don't want to be putting 44000 lines of new code in the kernel and
> then have it rot. Who will support this in the long-term? What
> resources are behind it? IOW: what can you say to convince us that it
> won't rot?
We're a team inside Analog Devices who are maintaining a GNU toolchain,
uClinux kernel, and user space apps for the Blackfin. All of this is
available on our blackfin.uclinux.org site. We do not expect to go away
anytime soon.
> The lack of a MAINTAINERS entry doesn't inspire confidence..
That should probably be fixed.
> - How widespread/popular is the blackfin? Are many devices using it?
> How old/mature is it? Is it a new thing or is it near end-of-life?
Neither, really. It's been around for a bit, but the uClinux port is
only now beginning to really take off, and we certainly hope that more
and more devices will begin using it.
> - Are easy-to-install x86 cross-build packages available? If not, are
> there straightforward instructions anywhere to guide people in generating
> a cross-build setup?
>
> <looks>
>
> OK, blackfin.uclinux.org seems to have that. Does binutils support
> blackfin?
On blackfin.uclinux.org you'll find our local trees and the RPM releases
we recommend to users. The Blackfin port is in gcc and binutils
mainline; we hope to be able to get into the kernel mainline as well.
If you have additional questions about the chip, please ask.
> - A lot of this code appears to come from Analog Devices, but you don't ;)
We do, actually. We just don't like Outlook.
> We'd need to see some sort of authorisation from the original authors
> for the inclusion of their code. Preferably in the form of
> Signed-off-by:s.
I'll pass that along to the right people. Would a "Signed-off-by:
Analog Devices" (similar to our FSF copyright assignments) be ok or does
it have to be individuals? I believe the port actually predates the
involvement of most of the people working on it now.
> - Do you really need to support old_mmap()?
From what I can tell, no we don't, although we'll have to make a small
change to our uClibc. (A lot of this code got copied from the m68k port
initially... that may explain a few things).
> - Too much use of open-coded `volatile'. The objective should be to have
> zero occurrences in .c files. And volatile sometimes creates suspicion
> even when it's used in .h files.
Are you referring to the ones in
include/asm-blackfin/mach-bf533/cdefBF532.h? These are memory-mapped
hardware registers (MMRs); do you have any better suggestions how to
access these? That file actually comes from our in-house Visual DSP
compiler, and while there may be better ways of accessing the register
than those macros, there is something to be said for being able to drop
in a replacement if future chips have different addresses for these
registers.
The Blackfin has a lot of peripherals sitting on the same die as the
core, and they're all accessed through MMRs.
Bernd
Bernd Schmidt <[email protected]> wrote:
>
> Luke is probably still asleep at this time of night, so I'll try to
> answer what I can...
>
> Andrew Morton wrote:
> > "Luke Yang" <[email protected]> wrote:
> >> This is the Blackfin archtecture patch for kernel 2.6.16.
> >
> > - We don't want to be putting 44000 lines of new code in the kernel and
> > then have it rot. Who will support this in the long-term? What
> > resources are behind it? IOW: what can you say to convince us that it
> > won't rot?
>
> We're a team inside Analog Devices who are maintaining a GNU toolchain,
> uClinux kernel, and user space apps for the Blackfin. All of this is
> available on our blackfin.uclinux.org site. We do not expect to go away
> anytime soon.
OK. Thanks for the contributions.
> ...
> > We'd need to see some sort of authorisation from the original authors
> > for the inclusion of their code. Preferably in the form of
> > Signed-off-by:s.
>
> I'll pass that along to the right people. Would a "Signed-off-by:
> Analog Devices" (similar to our FSF copyright assignments) be ok or does
> it have to be individuals? I believe the port actually predates the
> involvement of most of the people working on it now.
I think names of individuals would be preferred - the Signed-off-by: is
often used when hunting down maintainers/developers to bug about problems.
Although as it's a single megapatch, that's less useful in this case.
If we go with the single signed-off-by: I guess it would be best if that
was a person within AD who is in a position to authorise the merge. If you
say that person is yourself or Luke then fine.
> > - Do you really need to support old_mmap()?
>
> From what I can tell, no we don't, although we'll have to make a small
> change to our uClibc. (A lot of this code got copied from the m68k port
> initially... that may explain a few things).
>
> > - Too much use of open-coded `volatile'. The objective should be to have
> > zero occurrences in .c files. And volatile sometimes creates suspicion
> > even when it's used in .h files.
>
> Are you referring to the ones in
> include/asm-blackfin/mach-bf533/cdefBF532.h? These are memory-mapped
> hardware registers (MMRs); do you have any better suggestions how to
> access these? That file actually comes from our in-house Visual DSP
> compiler, and while there may be better ways of accessing the register
> than those macros, there is something to be said for being able to drop
> in a replacement if future chips have different addresses for these
> registers.
>
> The Blackfin has a lot of peripherals sitting on the same die as the
> core, and they're all accessed through MMRs.
readl/writel and friends would be the preferred way of accessing
memory-mapped registers. If that doesn't work then at least you should
wrap the volatile cast into a single inlined function somewhere so it's not
splattered everywhere. That way the code is more pleasing to read and we
eliminate the risk that someone forgets to add the cast.
Thanks for your reply. See below.
On 3/21/06, Andrew Morton <[email protected]> wrote:
> "Luke Yang" <[email protected]> wrote:
> >
> > This is the Blackfin archtecture patch for kernel 2.6.16.
> >
>
> There are few practical issues we need to be concerned about with new
> architectures.
>
> - We don't want to be putting 44000 lines of new code in the kernel and
> then have it rot. Who will support this in the long-term? What
> resources are behind it? IOW: what can you say to convince us that it
> won't rot?
>
> The lack of a MAINTAINERS entry doesn't inspire confidence..
As Bernd said, Analog Device has a group maintaining linux for
Blackfin. Now I am the one who in charge of committing patches into
mainline, other developers may do the same thing later. By
MAINTAINERS entry do you mean the linux-2.6/MAINTAINER? Or shall I
list maintainers name in the patch mail?
>
> - How widespread/popular is the blackfin? Are many devices using it?
> How old/mature is it? Is it a new thing or is it near end-of-life?
As a DSP, Blackfin has been there for years and is somewhat popular.
But as a CPU which can run Linux, we are trying to make it popular.
Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy
to play with.
>
> It's a cost/benefit thing. It costs us to add code to the kenrel. How
> many people would benefit from us doing that?
As multimedia is becoming popular in embedded world, I believe many
people would benefit from a DSP running Linux.
>
> - Are easy-to-install x86 cross-build packages available? If not, are
> there straightforward instructions anywhere to guide people in generating
> a cross-build setup?
http://docs.blackfin.uclinux.org/ is a good place to find documents.
In my opinion, not many CPU has such good documents site. Even a
beginner will find it as a good linux and embedded training place.
>
> <looks>
>
> OK, blackfin.uclinux.org seems to have that. Does binutils support
> blackfin?
>
> - A lot of this code appears to come from Analog Devices, but you don't ;)
Actually I am. Just perfer gmail than outlook web (I don't use
window$, so don't have outlook to access company mailbox).
> We'd need to see some sort of authorisation from the original authors
> for the inclusion of their code. Preferably in the form of
> Signed-off-by:s.
For this patch it is Luke Yang, then for other drivers or patches,
it would be the maintainer. All our work(software or even hardware) is
opened, our group don't do any un-GPLed software now.
>
> > http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2
>
> As I said, 44kloc ;)
Sorry for the size, again :) But I really don't want to split it,
doesn't make much sense.
>
> - Do you really need to support old_mmap()?
>
> - It would be preferable to use the generic IRQ infrastructure in kernel/irq/
Task added. I'll make it happen.
>
> - Too much use of open-coded `volatile'. The objective should be to have
> zero occurrences in .c files. And volatile sometimes creates suspicion
> even when it's used in .h files.
volatile is not evil :) The only and correct usage is variables that
may be modified by hardware (such as MMR) or in a irq/signal handler.
I have checked my code. Yes some kind of warpper may look better, we
have plan to change it, I'll send you patch for this.
>
> - bug: coreb_ioctl() does copy_from_user() and down() inside spinlock.
>
> - err, coreb_ioctl() does down(&file->f_dentry->d_inode->i_sem); but
> that's a mutex now, so I assume that's actually dead code?
Thanks. Bug reported. Actually that's part of the reasons we want
to get into mainline: As we keep up to latest kernel, we can get rid
of the obsolete code in time.
>
>
>
--
Best regards,
Luke Yang
[email protected]; [email protected]
Hi,
This is the patch of MAINTAINERS entry. As more Blackfin drivers
added in, I'll add more maintainers list.
diff --git a/MAINTAINERS b/MAINTAINERS
index 8db5c33..649cb01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -425,6 +425,36 @@ M: [email protected]
L: [email protected]
S: Maintained
+BLACKFIN ARCHITECTURE
+P: Luke Yang
+M: [email protected]
+P: Aubery Li
+M: [email protected]
+P: Bernd Schmidt
+M: [email protected]
+P: Robin Getz
+M: [email protected]
+P: Michael Hennerich
+M: [email protected]
+P: Jie Zhang
+M: [email protected]
+P: Michael Kang
+M: [email protected]
+P: Roy Huang
+M: [email protected]
+P: Sonic Zhang
+M: [email protected]
+L: [email protected]
+W: http://blackfin.uclinux.org
+S: Supported
+
+BLACKFIN SERIAL DRIVER
+P: Sonic Zhang
+M: [email protected]
+L: [email protected]
+W: http://blackfin.uclinux.org
+S: Supported
+
BLOCK LAYER
P: Jens Axboe
M: [email protected]
signed-off-by: Luke Yang <[email protected]>
Regards,
Luke Yang
On 3/22/06, Andrew Morton <[email protected]> wrote:
> "Luke Yang" <[email protected]> wrote:
> >
> > > The lack of a MAINTAINERS entry doesn't inspire confidence..
> > As Bernd said, Analog Device has a group maintaining linux for
> > Blackfin. Now I am the one who in charge of committing patches into
> > mainline, other developers may do the same thing later. By
> > MAINTAINERS entry do you mean the linux-2.6/MAINTAINER? Or shall I
> > list maintainers name in the patch mail?
>
> I was referring to an update to the MAINTAINERS file.
>
--
Best regards,
Luke Yang
[email protected]; [email protected]
Luke Yang wrote:
>On 3/21/06, Andrew Morton <[email protected]> wrote:
> > - How widespread/popular is the blackfin? Are many devices using it?
> > How old/mature is it? Is it a new thing or is it near end-of-life?
> As a DSP, Blackfin has been there for years and is somewhat popular.
>But as a CPU which can run Linux, we are trying to make it popular.
>Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy to
>play with.
I would not describe it as a toy (sorry Luke), plus I would consider the
work we have done to be mildly popular in terms of Linux support. I think
that since Luke mostly has his head down doing development, doesn't see all
the people that are in production...
I still consider Blackfin a "new" architecture (in terms of processors).
Some background on Blackfin/MSA can be found:
http://www.intel.com/design/msa/
Blackfin is a low cost (under $5.00 @ 400MHz) high performance (Dual core
at 600MHz each) processor that people are using, and shipping in real products.
http://www.analog.com/processors/processors/blackfin/BlackfinFamilyReferenceTable.html
Our kernel source supports BF531, BF532, BF533, BF534, BF536, BF537, BF561
A few people what started shipping that we did press releases with (many
others did not):
thermal infrared imaging camera:
http://www.analog.com/en/press/0,2890,3%255F%255F92455,00.html
Internet-Protocol Television (IPTV) set-top boxes:
http://www.analog.com/en/press/0,2890,3%255F%255F86425,00.html
We are engaged with lots of people - from students to people shipping
millions of units. We have almost 1600 registered developers on our web
site, and have had over 66,000 individual downloads of our kernel source
(not including checkouts or rsync of our cvs) - lots of people are using
it. That doesn't compare to the traffic on kernel.org, or people using x86,
but it is not bad for a "new" architecture.
People are making uClinux based SBC based on Blackfin:
http://www.zbrain.ch/htm/docs/zbrain_flyer_gnu_kit.pdf
http://www.tinyboards.com/rainbow2006/site/hardware/core_modules/__cm-bf537e/313/cm-bf537e.aspx
http://www.camsig.co.uk/products.htm
People are making 3rd party emulators (for those who don't want to use gdb
or kgdb, - we support both):
http://www.section5.ch/?which=1&sub=1
It is not a toy - people (including the 15 and growing people working full
time on this at ADI) make their living making sure it is acceptable both to
the people deploying it in a product, but also to the community at large -
we don't want to end up with a maintenance issues either, and have been
working pretty hard in getting into the mainline trees for all the projects
we are working on (toolchain, bootloader, ltp, kernel). Luke is spending
almost 90% of his time, ensuring that everything in our kernel source meets
the feedback from the mainline maintainers (and soon will help re-write the
serial driver, based on Russell King's feedback :)
> > It's a cost/benefit thing. It costs us to add code to the kenrel. How
> > many people would benefit from us doing that?
> As multimedia is becoming popular in embedded world, I believe many
> people would benefit from a DSP running Linux.
IMHO - It is more than just another processor running Linux.
For people who ship large volume, it is a new mix of
price/performance/power/peripherals that embedded Linux has not been able
to meet in the past. We are enabling people to add (or keep) Linux to their
products, and decrease their cost. We enable Linux on the network edge -
for example : IP Phones - we worked with the maintainer of Linphone, and
people are deploying that in their systems for VoIP.
For people who ship zero volume (which is great) - it is a completely free
system. free toolchain, free debugger, free libraries, free kernel, free
applications, free schematics, free simulator (skyeye), free documentation
(web site), free support (web site). Free as in speech (open source), and
in beer(zero cost). For those who want to run it on hardware - - $200(US)
at Digikey, you get a board with 10/100 Networking, 500MHz CPU, 64Meg
SDRAM, 4 Meg Flash, and lots of expansion.
If you think our patch sucks, fine - let us know where to fix it. We will
be back at 2.6.17 with an update - and you can tell us where that sucks
then too. (Just like we did at 2.6.13, where lots of people pointed out
issues, which we worked on fixing for now)
-Robin
Robin Getz <[email protected]> wrote:
>
> Luke Yang wrote:
> >On 3/21/06, Andrew Morton <[email protected]> wrote:
> > > - How widespread/popular is the blackfin? Are many devices using it?
> > > How old/mature is it? Is it a new thing or is it near end-of-life?
> > As a DSP, Blackfin has been there for years and is somewhat popular.
> >But as a CPU which can run Linux, we are trying to make it popular.
> >Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy to
> >play with.
>
> I would not describe it as a toy (sorry Luke),
>
> [ interesting info ]
>
Thanks.
> If you think our patch sucks, fine - let us know where to fix it.
It looks reasonable to me, from a ten-minute-scan.
Well. All architecture ports suck. Yours sucks averagely ;)
The todo list of which I'm aware is
- use serial core in that driver
- Fix up that ioctl so it a) doesn't sleep in spinlock and b) compiles
- Use generic IRQ framework
- Review all the volatiles, consolidate them in some helper-in-header-file.
- Sort out maintainance issues, gather signed-off-bys. (Done, it appears)
More things might come out once people start paying more attention, but if
that's the extent of things, I'd be OK with a merge when you're ready.
On 3/22/06, Andrew Morton <[email protected]> wrote:
> Robin Getz <[email protected]> wrote:
> >
> > Luke Yang wrote:
> > >On 3/21/06, Andrew Morton <[email protected]> wrote:
> > > > - How widespread/popular is the blackfin? Are many devices using it?
> > > > How old/mature is it? Is it a new thing or is it near end-of-life?
> > > As a DSP, Blackfin has been there for years and is somewhat popular.
> > >But as a CPU which can run Linux, we are trying to make it popular.
> > >Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy to
> > >play with.
> >
> > I would not describe it as a toy (sorry Luke),
> >
> > [ interesting info ]
> >
>
> Thanks.
>
> > If you think our patch sucks, fine - let us know where to fix it.
>
> It looks reasonable to me, from a ten-minute-scan.
>
> Well. All architecture ports suck. Yours sucks averagely ;)
>
> The todo list of which I'm aware is
>
> - use serial core in that driver
>
> - Fix up that ioctl so it a) doesn't sleep in spinlock and b) compiles
>
> - Use generic IRQ framework
>
> - Review all the volatiles, consolidate them in some helper-in-header-file.
>
> - Sort out maintainance issues, gather signed-off-bys. (Done, it appears)
>
> More things might come out once people start paying more attention, but if
> that's the extent of things, I'd be OK with a merge when you're ready.
Does this merge has to be within 1 week after the release, so we
have to wait for 2.6.17? Or this can be done on mm-tree?
>
--
Best regards,
Luke Yang
[email protected]; [email protected]
"Luke Yang" <[email protected]> wrote:
>
> > More things might come out once people start paying more attention, but if
> > that's the extent of things, I'd be OK with a merge when you're ready.
> Does this merge has to be within 1 week after the release, so we
> have to wait for 2.6.17? Or this can be done on mm-tree?
The whole patch affects just one line in one Kconfig file outside
arch/bluefin, so I don't see a reason why this needs to be tied into the
two-week-window thing. I figure that if we can get it into -mm within a
few weeks we'll be OK for 2.6.17.
But that depends upon review comments. My ten-minute-peek was not
sufficient. But given this discussion and its probably appearance in -mm,
I'd expect a few more people will get in there and help.
We'll see how it goes.
Hi Luke,
On Wednesday, 22. March 2006 04:45, you wrote:
> As a DSP, Blackfin has been there for years and is somewhat popular.
> But as a CPU which can run Linux, we are trying to make it popular.
> Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy
> to play with.
Yes, its awesome! And I would like to thank Analog Devices for doing
and sponsoring this work. I also like to thank them for providing useful
test devices for reasonable prices. Hope you guys will make it.
I have seen a presentation and demo of this on the Chemnitzer Linux Tage 2006[1]
and was impressed big time considering how long it took to get sth. running
with other products and without any vendor Linux support.
And yes I'm a bit biased[2], as you'll find out, if you google a bit :-)
Regards
Ingo Oeser
[1] In German, sorry: http://chemnitzer.linux-tage.de/2006/vortraege/detail.html?idx=345
[2] towards coupling Linux & DSPs
On 3/23/06, Ingo Oeser <[email protected]> wrote:
> Hi Luke,
>
> On Wednesday, 22. March 2006 04:45, you wrote:
> > As a DSP, Blackfin has been there for years and is somewhat popular.
> > But as a CPU which can run Linux, we are trying to make it popular.
> > Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy
> > to play with.
>
> Yes, its awesome! And I would like to thank Analog Devices for doing
> and sponsoring this work. I also like to thank them for providing useful
> test devices for reasonable prices. Hope you guys will make it.
>
> I have seen a presentation and demo of this on the Chemnitzer Linux Tage 2006[1]
> and was impressed big time considering how long it took to get sth. running
> with other products and without any vendor Linux support.
Thank you! We'll try to make it.
>
> And yes I'm a bit biased[2], as you'll find out, if you google a bit :-)
Is it a document? I googled by didn't find it.
>
>
> Regards
>
> Ingo Oeser
>
> [1] In German, sorry: http://chemnitzer.linux-tage.de/2006/vortraege/detail.html?idx=345
> [2] towards coupling Linux & DSPs
>
>
>
--
Best regards,
Luke Yang
[email protected]; [email protected]
Ingo Oeser <ioe-lkml <at> rameria.de> writes:
<snip>
> Yes, its awesome! And I would like to thank Analog Devices for doing
> and sponsoring this work. I also like to thank them for providing useful
> test devices for reasonable prices. Hope you guys will make it.
<snip>
> And yes I'm a bit biased[2], as you'll find out, if you google a bit
>
I'm likely terminally biased, but FWIW, ADI has been really supportive of our
effort in porting Adeos and the Xenomai real-time sub-system over their
architecture. Their tireless effort in improving the Blackfin kernel port and
also the toolchain, while providing information in total openness, made this
possible.
--
Philippe