Microblaze Linux release

Microblaze Linux release

[Michal Simek]

Hi Everybody,

I fixed all reported bugs which I got from LKML and from you.
Latest version of Microblaze Linux kernel is available at git.monstr.eu.
There is git repository called linux-microblaze.git
Microblaze port is based on 2.6.24-rc5. I'll create the new repo with clean pack
of changes based on latest kernel version for easier pull.

Merge windows will be open hopefully next week and I would like to send pull
request to Paul.

I would like to ask you for review all microblaze code especially
arch/microblaze and include/asm-microblaze. Please don't send me question to
drivers - Microblaze will use only uartlite driver (only add on or to Kconfig -
that's enough for now).

All questions and reported bug please send to me.
Please report all bugs (coding style, long line, poor coments - everything).
Please send me your ACK too. For my better summary - please send me list of
files. Summary will be continuously concurrently publish at
http://www.monstr.eu/wiki/doku.php?id=kernel:kernel.


Thanks for your help,

Michal Simek,
www.monstr.eu

P.S.: For LKML users - I am going to integrate all bugs to previous set of
patches - that's why I asked about how to do it. I hope I send this pack today
or on Monday.

Re: Microblaze Linux release

[Grant Likely]

On Sun, Apr 13, 2008 at 7:26 AM, Michal Simek <monstr@seznam.cz> wrote:
> Hi Everybody,
>
>  I fixed all reported bugs which I got from LKML and from you.
>  Latest version of Microblaze Linux kernel is available at git.monstr.eu.
>  There is git repository called linux-microblaze.git
>  Microblaze port is based on 2.6.24-rc5. I'll create the new repo with clean pack
>  of changes based on latest kernel version for easier pull.
>
>  Merge windows will be open hopefully next week and I would like to send pull
>  request to Paul.
>
>  I would like to ask you for review all microblaze code especially
>  arch/microblaze and include/asm-microblaze. Please don't send me question to
>  drivers - Microblaze will use only uartlite driver (only add on or to Kconfig -
>  that's enough for now).

Can you please also post your updated patch series?  Reviewing patches
is easy.  Reviewing a git tree is a lot more work.

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Microblaze Linux release

[Josh Boyer]

On Sun, 13 Apr 2008 15:26:57 +0200
Michal Simek <monstr@seznam.cz> wrote:

> Hi Everybody,
> 
> I fixed all reported bugs which I got from LKML and from you.
> Latest version of Microblaze Linux kernel is available at git.monstr.eu.
> There is git repository called linux-microblaze.git
> Microblaze port is based on 2.6.24-rc5. I'll create the new repo with clean pack
> of changes based on latest kernel version for easier pull.
> 
> Merge windows will be open hopefully next week and I would like to send pull
> request to Paul.

Why Paul?  If microblaze is a new architecture (which it seems to be),
then you should really work through Linus directly.

Also, which version of gcc/binutils are needed to actually build this?

josh

Re: Microblaze Linux release

[Michal Simek]

Hi Grant,

as I wrote. I am working on it. I'll send them ASAP.


Michal

>> Hi Everybody,
>>
>>  I fixed all reported bugs which I got from LKML and from you.
>>  Latest version of Microblaze Linux kernel is available at git.monstr.eu.
>>  There is git repository called linux-microblaze.git
>>  Microblaze port is based on 2.6.24-rc5. I'll create the new repo with clean pack
>>  of changes based on latest kernel version for easier pull.
>>
>>  Merge windows will be open hopefully next week and I would like to send pull
>>  request to Paul.
>>
>>  I would like to ask you for review all microblaze code especially
>>  arch/microblaze and include/asm-microblaze. Please don't send me question to
>>  drivers - Microblaze will use only uartlite driver (only add on or to Kconfig -
>>  that's enough for now).
> 
> Can you please also post your updated patch series?  Reviewing patches
> is easy.  Reviewing a git tree is a lot more work.
> 
> Thanks,
> g.
> 

Re: Microblaze Linux release

[Michal Simek]

Hi Josh,

>> Hi Everybody,
>>
>> I fixed all reported bugs which I got from LKML and from you.
>> Latest version of Microblaze Linux kernel is available at git.monstr.eu.
>> There is git repository called linux-microblaze.git
>> Microblaze port is based on 2.6.24-rc5. I'll create the new repo with clean pack
>> of changes based on latest kernel version for easier pull.
>>
>> Merge windows will be open hopefully next week and I would like to send pull
>> request to Paul.
> 
> Why Paul?  If microblaze is a new architecture (which it seems to be),
> then you should really work through Linus directly.

I don't know who start with it. For me is not this point important.
I think that was Steve's idea, wasn't it?

> Also, which version of gcc/binutils are needed to actually build this?

I personally use gcc from Petalogix distribution. For non-MMU kernel v3.4.1. for
MMU kernel I think 4.1.1. (MMU port for Microblaze FDT kernel will come later).
You can download whole distribution from developer.petalogix.com.

Michal Simek
www.monstr.eu

Re: Microblaze Linux release

[Arnd Bergmann]

On Sunday 13 April 2008, Michal Simek wrote:
> I would like to ask you for review all microblaze code especially
> arch/microblaze and include/asm-microblaze. Please don't send me question to
> drivers - Microblaze will use only uartlite driver (only add on or to Kconfig -
> that's enough for now).

I'm certainly willing to help review it, but I think the timing is too short
for asking for a 2.6.26 merge. Judging from experience, a new architecture
review takes a few weeks to sort out all the issues you want resolved before
merging, so posting them now would put you in a much more comfortable position
when targeting a 2.6.27 merge.

One of the things I always wanted to have is a common location for all the
things that get duplicated verbatim into each new architecture, like all
the include/asm/{fcntl,ioctls,ipcbuf,mman,poll,posix_types,sem_buf}.h and
others that define part of the syscall ABI.

	Arnd <><

Re: Microblaze Linux release

[H. Peter Anvin]

Arnd Bergmann wrote:
> 
> One of the things I always wanted to have is a common location for all the
> things that get duplicated verbatim into each new architecture, like all
> the include/asm/{fcntl,ioctls,ipcbuf,mman,poll,posix_types,sem_buf}.h and
> others that define part of the syscall ABI.
> 

include/asm-generic

	-hpa

Re: Microblaze Linux release

[Arnd Bergmann]

On Monday 14 April 2008, Arnd Bergmann wrote:

> I'm certainly willing to help review it, but I think the timing is too short
> for asking for a 2.6.26 merge. Judging from experience, a new architecture
> review takes a few weeks to sort out all the issues you want resolved before
> merging, so posting them now would put you in a much more comfortable position
> when targeting a 2.6.27 merge.

I've just looked at your git tree, and it confirmed my point that we need
a little more time. Please don't hesitate to submit patches to the mailing
list though. You may have misunderstood the idea of the merge window: The
patches can go in during that time if they have been reviewed before, so
it is not the time to post patches for review.

More to the point, here are a few things that I noticed on a brief
review:

* Your arch code in general looks nice and clean, don't worry too much
about the coding style right now.

* The code level is 2.6.24-rc8, while the current head is at 2.6.25-rc9.
You should really upgrade the kernel level, because a number of changes
have gone in that directly affect your code. Your best bet is probably
now to have a patch against the linux-next tree, which also has the changes
that will go into 2.6.26.

* Your syscall ABI is largely obsolete. A third of the syscalls you
define should not even be there in the first place as they have been
replaced by newer versions. E.g. you have select, _newselect and pselect6,
where just pselect6 would be sufficient -- you don't need to worry about
backwards compatibility if you don't have existing code. A good start
would be to take the arch/blackfin syscall list and further reduce it
from there. Further examples are:
- replace socketcall with separate syscall entry points
- replace ipc with a separate entry points
- remove all the legacy signal handling from arch/microblaze/kernel/signal.c
- remove sys_mmap, sys_olduname and sys_vfork
- finally define a generic sys_mmap2 and sys_uname in kernel/ so you don't
  need another copy in arch/microblaze/kernel
- Use 64 bit off_t, and 32 bit uid_t, gid_t etc.

* Your device tree functions in of_device.c, of_platform.c, prom.c and
prom_parse.c are basically copies of the powerpc versions. This duplication
is not helpful, better merge that code into new files in drivers/of/
so that it can be shared.

* The semaphore implementation will be obsolete in 2.6.26

* The EXPORT_SYMBOL definitions for csum_partial etc should be in
arch/microblaze/lib/checksum.c, not in microblaze_ksyms.c, same
for memcpy/memmove/memset.

* The platform directory is noticably empty. You can probably judge better
how much platform specific code there will be in the future, but I would
suspect that you're better off with a flat platform directory instead
of subdirectories below that.

* the consistent.c implementation looks strange. Is any of that code
even used anywhere? What is it good for, considering that you don't have
an mmu?

* Your dma_mapping.h does BUG() for almost everything. I suspect you could
easily replace it with a trivial implementation, like the x86_32 one.

* I'm not sure if you really need something as sophisticated as the lmb
code, if you don't have a real firmware, or even an MMU. setup_memory
can probably work with something much simpler, and for the prom.c stuff,
you may get away with #defining them to bootmem_alloc etc.

* You don't seem to have any code for PCI, so the pci.h and pci-bridge.h
files don't make much sense.

* The following files:
atomic.h checksum.h io.h ioctl.h ioctls.h ipcbuf.h msgbuf.h param.h
poll.h posix_types.h sembuf.h shmbuf.h shmparam.h sigcontext.h signal.h
socket.h sockios.h stat.h termbits.h termios.h types.h ucontext.h
all look like verbatim copies of some other architecture. Please do
the next person to come up with a new architecture a favor and stick them
in include/asm-generic instead, including them from your own headers.

* You unistd.h contains _syscall* macros. These were removed some time
ago from all other architectures.

* You define a lot of __ARCH_WANT_SYS_ macros. Generally, these are
for the syscalls you don't want.

* You are missing a include/asm-microblaze/Kbuild file that lists all
the header files you want to export to user space.

	Arnd <><

Re: Microblaze Linux release

[Arnd Bergmann]

On Monday 14 April 2008, H. Peter Anvin wrote:
> Arnd Bergmann wrote:
> > 
> > One of the things I always wanted to have is a common location for all the
> > things that get duplicated verbatim into each new architecture, like all
> > the include/asm/{fcntl,ioctls,ipcbuf,mman,poll,posix_types,sem_buf}.h and
> > others that define part of the syscall ABI.
> > 
> 
> include/asm-generic

Sure. Halfway through writing my sentence, I wanted to suggest arch/generic
for the stuff in there that has the potential of being unified, but then
realized how little there is of that, and that it may just as well go into
the top-level mm/, kernel/, lib/ etc, as we have done in the past.

	Arnd <><

Re: Microblaze Linux release

[Michal Simek]

Hi Arnd,

>> I would like to ask you for review all microblaze code especially
>> arch/microblaze and include/asm-microblaze. Please don't send me question to
>> drivers - Microblaze will use only uartlite driver (only add on or to Kconfig -
>> that's enough for now).
> 
> I'm certainly willing to help review it, but I think the timing is too short
> for asking for a 2.6.26 merge. Judging from experience, a new architecture
> review takes a few weeks to sort out all the issues you want resolved before
> merging, so posting them now would put you in a much more comfortable position
> when targeting a 2.6.27 merge.

Thanks for your help. I know that the time is short.:-( We'll see. I will
request for merge if I know Microblaze cpu is clean.

> One of the things I always wanted to have is a common location for all the
> things that get duplicated verbatim into each new architecture, like all
> the include/asm/{fcntl,ioctls,ipcbuf,mman,poll,posix_types,sem_buf}.h and
> others that define part of the syscall ABI.
> 
> 	Arnd <><

Include files are pain I know.

Michal Simek
www.monstr.eu

RE: Microblaze Linux release

[Stephen Neuendorffer]

> -----Original Message-----
> From: Michal Simek [mailto:monstr@seznam.cz]
> Sent: Sunday, April 13, 2008 11:51 AM
> To: Josh Boyer
> Cc: Stephen Neuendorffer; John Williams; benh@kernel.crashing.org;
John Linn; git-dev; Grant Likely;
> git; microblaze-uclinux@itee.uq.edu.au; linux-kernel@vger.kernel.org;
paulus@samba.org
> Subject: Re: Microblaze Linux release
> 
> Hi Josh,
> 
> >> Hi Everybody,
> >>
> >> I fixed all reported bugs which I got from LKML and from you.
> >> Latest version of Microblaze Linux kernel is available at
git.monstr.eu.
> >> There is git repository called linux-microblaze.git
> >> Microblaze port is based on 2.6.24-rc5. I'll create the new repo
with clean pack
> >> of changes based on latest kernel version for easier pull.
> >>
> >> Merge windows will be open hopefully next week and I would like to
send pull
> >> request to Paul.
> >
> > Why Paul?  If microblaze is a new architecture (which it seems to
be),
> > then you should really work through Linus directly.
> 
> I don't know who start with it. For me is not this point important.
> I think that was Steve's idea, wasn't it?

Nope, it should go through Linus.  My hope was to recruit reviewers from
the powerpc community, since there is alot of overlap (device trees,
drivers, the MMU is very similar).

Steve

Re: Microblaze Linux release

[Michal Simek]

Hi Arnd,

>> I'm certainly willing to help review it, but I think the timing is too short
>> for asking for a 2.6.26 merge. Judging from experience, a new architecture
>> review takes a few weeks to sort out all the issues you want resolved before
>> merging, so posting them now would put you in a much more comfortable position
>> when targeting a 2.6.27 merge.
> 
> I've just looked at your git tree, and it confirmed my point that we need
> a little more time. Please don't hesitate to submit patches to the mailing
> list though. You may have misunderstood the idea of the merge window: The
> patches can go in during that time if they have been reviewed before, so
> it is not the time to post patches for review.
>
> More to the point, here are a few things that I noticed on a brief
> review:
> 
> * Your arch code in general looks nice and clean, don't worry too much
> about the coding style right now.

I think so. I spent a lot of time to clean the code.

> * The code level is 2.6.24-rc8, while the current head is at 2.6.25-rc9.
> You should really upgrade the kernel level, because a number of changes
> have gone in that directly affect your code. Your best bet is probably
> now to have a patch against the linux-next tree, which also has the changes
> that will go into 2.6.26.

I am working on 2.6.25-rc9 Microblaze version. I am solving issue about
CONFIG_HZ and new syscall timerfd_... . There are new 3 syscalls. And I think
that these syscalls bring up failure to MB code.

> * Your syscall ABI is largely obsolete. A third of the syscalls you
> define should not even be there in the first place as they have been
> replaced by newer versions. E.g. you have select, _newselect and pselect6,
> where just pselect6 would be sufficient -- you don't need to worry about
> backwards compatibility if you don't have existing code. A good start
> would be to take the arch/blackfin syscall list and further reduce it
> from there. Further examples are:
> - replace socketcall with separate syscall entry points
> - replace ipc with a separate entry points
> - remove all the legacy signal handling from arch/microblaze/kernel/signal.c
> - remove sys_mmap, sys_olduname and sys_vfork
> - finally define a generic sys_mmap2 and sys_uname in kernel/ so you don't
>   need another copy in arch/microblaze/kernel
> - Use 64 bit off_t, and 32 bit uid_t, gid_t etc.

This kernel don't need to keep backward compatibility. No one will port to
previous version. I'll look at your points and I'll send you what I do.

> * Your device tree functions in of_device.c, of_platform.c, prom.c and
> prom_parse.c are basically copies of the powerpc versions. This duplication
> is not helpful, better merge that code into new files in drivers/of/
> so that it can be shared.

These files are almost the same. There is small differences between them. I
would like to avoid to merge this code with PowerPC because this generate a lot
of mails in this steps.

BTW: OF code in powerpc have coding style violation.

Guys from PowerPC. Can you move these files around OF to drivers/of folder? or
Can you propose easier way for me?

I think we can solve these files when we merge Microblaze to PowerPC branch.

> * The semaphore implementation will be obsolete in 2.6.26

I don't know. Which cpu has correct implemetnation?

> * The EXPORT_SYMBOL definitions for csum_partial etc should be in
> arch/microblaze/lib/checksum.c, not in microblaze_ksyms.c, same
> for memcpy/memmove/memset.

OK. I fixed it.

> * The platform directory is noticably empty. You can probably judge better
> how much platform specific code there will be in the future, but I would
> suspect that you're better off with a flat platform directory instead
> of subdirectories below that.

I consult this with John Williams and this was result of our meeting. This
structure is more comfortable for adding new platform inside distribution. I
would like to keep this for now. We'll see if is good or not in future.

> * the consistent.c implementation looks strange. Is any of that code
> even used anywhere? What is it good for, considering that you don't have
> an mmu?

We have prepared MMU code. I hope that this code for FDT kernel comes soon.
This code is written by John Williams. I have never changed it. I see that this
code solves problems around ucached_shadows stuff.
http://developer.petalogix.com/wiki/UserGuide/AdvancedTopics/EnablingUncachedShadow
JW. Can you comment this?

> * Your dma_mapping.h does BUG() for almost everything. I suspect you could
> easily replace it with a trivial implementation, like the x86_32 one.

OK. I'll synchronize this.

> * I'm not sure if you really need something as sophisticated as the lmb
> code, if you don't have a real firmware, or even an MMU. setup_memory
> can probably work with something much simpler, and for the prom.c stuff,
> you may get away with #defining them to bootmem_alloc etc.

LMB code cames with OF. You wrote that prom.c files and others are written for
PowerPC and PowerPC uses lmb allocation. For me was simplier to add LMB code to
Microblaze. As I wrote above. Microblaze have static (old configuration style)
implementation for MMU. I think it will be improvident to redesign this code
when I know that I will merge noMMU kernel with MMU.

> * You don't seem to have any code for PCI, so the pci.h and pci-bridge.h
> files don't make much sense.

Yes you are right. I don't have any PCI code but I think that this code for MB
exists. Steve or John: Do you have any code for PCI?

> * The following files:
> atomic.h checksum.h io.h ioctl.h ioctls.h ipcbuf.h msgbuf.h param.h
> poll.h posix_types.h sembuf.h shmbuf.h shmparam.h sigcontext.h signal.h
> socket.h sockios.h stat.h termbits.h termios.h types.h ucontext.h
> all look like verbatim copies of some other architecture. Please do
> the next person to come up with a new architecture a favor and stick them
> in include/asm-generic instead, including them from your own headers.

I'll look which files are the same with others arch.

> * You unistd.h contains _syscall* macros. These were removed some time
> ago from all other architectures.

I removed it.

> * You define a lot of __ARCH_WANT_SYS_ macros. Generally, these are
> for the syscalls you don't want.

ARCH_WANT is defined for syscalls which I don't want. I don't understand this.

I think that I ARCH_WANT is for syscalls which I want and IGNORE for rest. Am I
right?

> * You are missing a include/asm-microblaze/Kbuild file that lists all
> the header files you want to export to user space.


I add it. This files comes from PowerPC.

> 	Arnd <><

Thanks for your review,

Michal Simek
www.monstr.eu

Re: Microblaze Linux release

[Michal Simek]

Hi Steve,

>> Hi Josh,
>>
>>>> Hi Everybody,
>>>>
>>>> I fixed all reported bugs which I got from LKML and from you.
>>>> Latest version of Microblaze Linux kernel is available at
> git.monstr.eu.
>>>> There is git repository called linux-microblaze.git
>>>> Microblaze port is based on 2.6.24-rc5. I'll create the new repo
> with clean pack
>>>> of changes based on latest kernel version for easier pull.
>>>>
>>>> Merge windows will be open hopefully next week and I would like to
> send pull
>>>> request to Paul.
>>> Why Paul?  If microblaze is a new architecture (which it seems to
> be),
>>> then you should really work through Linus directly.
>> I don't know who start with it. For me is not this point important.
>> I think that was Steve's idea, wasn't it?
> 
> Nope, it should go through Linus.  My hope was to recruit reviewers from
> the powerpc community, since there is alot of overlap (device trees,
> drivers, the MMU is very similar).
> 
> Steve

That can be my mistake.	I don't remember who was it. It doesn't matter.

We talked about recruits with Steve that was different topic not this.

Regards,
Michal Simek
www.monstr.eu

Re: Microblaze Linux release

[Arnd Bergmann]

On Tuesday 15 April 2008, Michal Simek wrote:

> > * Your device tree functions in of_device.c, of_platform.c, prom.c and
> > prom_parse.c are basically copies of the powerpc versions. This duplication
> > is not helpful, better merge that code into new files in drivers/of/
> > so that it can be shared.
> 
> These files are almost the same. There is small differences between them. I
> would like to avoid to merge this code with PowerPC because this generate a lot
> of mails in this steps.
> 
> BTW: OF code in powerpc have coding style violation.
> 
> Guys from PowerPC. Can you move these files around OF to drivers/of folder? or
> Can you propose easier way for me?
> 
> I think we can solve these files when we merge Microblaze to PowerPC branch.

I think the easiest way is to include those patches in your series
and ask for an Acked-by from paulus.

The order of the patches should be:

1. fix up any coding style issues you have found
2. move the files without further changes to drivers/of
3. add whatever code you need to make it work on both architectures

Be careful not to break sparc in the process, as they are already
sharing substantial parts of the OF code with powerpc.

> > * The semaphore implementation will be obsolete in 2.6.26
> 
> I don't know. Which cpu has correct implemetnation?

2.6.26 will have a common implementation in kernel/semaphore.c.
All you need is a one-line asm/semaphore.h to #include linux/semaphore.h.

> > * the consistent.c implementation looks strange. Is any of that code
> > even used anywhere? What is it good for, considering that you don't have
> > an mmu?
> 
> We have prepared MMU code. I hope that this code for FDT kernel comes soon.
> This code is written by John Williams. I have never changed it. I see that this
> code solves problems around ucached_shadows stuff.
> http://developer.petalogix.com/wiki/UserGuide/AdvancedTopics/EnablingUncachedShadow
> JW. Can you comment this?

>From what I can see, your consistent.c code is just wrong and uses an
obsolete interface. Since you currently don't use it, I'd suggest to
drop it from your current tree for the merge. We can discuss it again
when you add MMU support.
 
> > * I'm not sure if you really need something as sophisticated as the lmb
> > code, if you don't have a real firmware, or even an MMU. setup_memory
> > can probably work with something much simpler, and for the prom.c stuff,
> > you may get away with #defining them to bootmem_alloc etc.
> 
> LMB code cames with OF. You wrote that prom.c files and others are written for
> PowerPC and PowerPC uses lmb allocation. For me was simplier to add LMB code to
> Microblaze. As I wrote above. Microblaze have static (old configuration style)
> implementation for MMU. I think it will be improvident to redesign this code
> when I know that I will merge noMMU kernel with MMU.

LMB doesn't have much to do with an MMU, but more with the way certain IBM
machines extend the OF interfaces.

I'd recommend splitting prom.c into code that can be shared between powerpc
and microblaze and architecture specific code. Anything that deals with
LMB should go into powerpc, and you can simply use the alloc_bootmem
mechanism for your architecture.
 
> > * The following files:
> > atomic.h checksum.h io.h ioctl.h ioctls.h ipcbuf.h msgbuf.h param.h
> > poll.h posix_types.h sembuf.h shmbuf.h shmparam.h sigcontext.h signal.h
> > socket.h sockios.h stat.h termbits.h termios.h types.h ucontext.h
> > all look like verbatim copies of some other architecture. Please do
> > the next person to come up with a new architecture a favor and stick them
> > in include/asm-generic instead, including them from your own headers.
> 
> I'll look which files are the same with others arch.

That was not my point, although it would be a good idea as well.
The important bit is that your version of these files don't contain
any architecture specific code (no guarantees, my review may have
been sloppy). Even if every architecture so far has a different
version of them, but any of them would be ok for you, please throw
one of them into asm-generic and start using it.
All future architectures can simply use that copy as well, as long as
they have the same constraints (e.g. you atomic.h assumes there are
no atomic operations other than spinlock, iirc).

If you want to be really nice, look for the most common implementation
across the existing architectures and put that into asm-generic.
Also, please cc the linux-arch mailing list on any patch that adds
a file in asm-generic.

> > * You define a lot of __ARCH_WANT_SYS_ macros. Generally, these are
> > for the syscalls you don't want.
> 
> ARCH_WANT is defined for syscalls which I don't want. I don't understand this.
> 
> I think that I ARCH_WANT is for syscalls which I want and IGNORE for rest. Am I
> right?

Sorry, my comment was impossible to understand ;-).
What I meant is that a new architecture should not define these macros, because
only architectures with a need for backwards compatibility want the syscalls
they enable. If you find an exception and think you need one of them, please
tell us.

	Arnd <><

Re: Microblaze Linux release

[Benjamin Herrenschmidt]

On Tue, 2008-04-15 at 15:32 +0200, Arnd Bergmann wrote:
> 
> I'd recommend splitting prom.c into code that can be shared between powerpc
> and microblaze and architecture specific code. Anything that deals with
> LMB should go into powerpc, and you can simply use the alloc_bootmem
> mechanism for your architecture.

That is non trivial... the unflatten DT code among others relies heavily
on the LMB's to allocate the objects.

We could split the early accessors, unflatten code, and kernel-side
accessors at one point, though we already did most of it no ?

Ben.

Re: Microblaze Linux release

[Michal Simek]

Hi Ben,

>> I'd recommend splitting prom.c into code that can be shared between powerpc
>> and microblaze and architecture specific code. Anything that deals with
>> LMB should go into powerpc, and you can simply use the alloc_bootmem
>> mechanism for your architecture.
> 
> That is non trivial... the unflatten DT code among others relies heavily
> on the LMB's to allocate the objects.

I think so. Sharing code among archs looks nice and this way is definitely
right. But starting with communication with PowerPC guys that this code I want
to use in case that this code is not in vanilla. This is not good start for
doing this.
I think if Microblaze will be in vanilla we can talked about separation MB and
PPC part to kernel folder and shared code move to shared folder.

> We could split the early accessors, unflatten code, and kernel-side
> accessors at one point, though we already did most of it no ?

Yes

Michal Simek
www.monstr.eu

Re: Microblaze Linux release

[Paul Mackerras]

Michal Simek writes:

> I think so. Sharing code among archs looks nice and this way is definitely
> right. But starting with communication with PowerPC guys that this code I want
> to use in case that this code is not in vanilla. This is not good start for
> doing this.

I have a commit queued up that moves lmb.c into the top-level lib
directory so other architectures can use it easily.  Dave Miller
wanted this so he could use it for sparc64.  That will go into Linus'
tree when the merge window opens and will be in 2.6.26.  So I don't
see any reason why microblaze couldn't use the LMB stuff.

Paul.

Re: Microblaze Linux release

[Arnd Bergmann]

On Wednesday 16 April 2008, Paul Mackerras wrote:
> Michal Simek writes:
> 
> > I think so. Sharing code among archs looks nice and this way is definitely
> > right. But starting with communication with PowerPC guys that this code I want
> > to use in case that this code is not in vanilla. This is not good start for
> > doing this.
> 
> I have a commit queued up that moves lmb.c into the top-level lib
> directory so other architectures can use it easily.  Dave Miller
> wanted this so he could use it for sparc64.  That will go into Linus'
> tree when the merge window opens and will be in 2.6.26.  So I don't
> see any reason why microblaze couldn't use the LMB stuff.
> 

Right, fair enough. I was mostly objecting to the idea of creating another
copy of the lmb code when bootmem should be sufficient for what microblaze
needs. Using the code from lib/lmb.c sounds fair enough when it's already
there.

One more reason for the microblaze kernel to base on top of linux-next
instead of mainline.

	Arnd <><

Re: Microblaze Linux release

[Benjamin Herrenschmidt]

On Wed, 2008-04-16 at 08:24 +0200, Michal Simek wrote:
> Hi Ben,
> 
> >> I'd recommend splitting prom.c into code that can be shared between powerpc
> >> and microblaze and architecture specific code. Anything that deals with
> >> LMB should go into powerpc, and you can simply use the alloc_bootmem
> >> mechanism for your architecture.
> > 
> > That is non trivial... the unflatten DT code among others relies heavily
> > on the LMB's to allocate the objects.
> 
> I think so. Sharing code among archs looks nice and this way is definitely
> right. But starting with communication with PowerPC guys that this code I want
> to use in case that this code is not in vanilla. This is not good start for
> doing this.
> I think if Microblaze will be in vanilla we can talked about separation MB and
> PPC part to kernel folder and shared code move to shared folder.

Well, LMB code is moving to generic anyway... So we may as well move
more stuff there ;-)

Cheers,
Ben.

Re: Microblaze Linux release

[Michal Simek]

Hi Paul,

> 
>> I think so. Sharing code among archs looks nice and this way is definitely
>> right. But starting with communication with PowerPC guys that this code I want
>> to use in case that this code is not in vanilla. This is not good start for
>> doing this.
> 
> I have a commit queued up that moves lmb.c into the top-level lib
> directory so other architectures can use it easily.  Dave Miller
> wanted this so he could use it for sparc64.  That will go into Linus'
> tree when the merge window opens and will be in 2.6.26.  So I don't
> see any reason why microblaze couldn't use the LMB stuff.
> 
> Paul.

I will test it.

Thanks Paul,

Michal Simek

Re: Microblaze Linux release

[Michal Simek]

>>> I think so. Sharing code among archs looks nice and this way is definitely
>>> right. But starting with communication with PowerPC guys that this code I want
>>> to use in case that this code is not in vanilla. This is not good start for
>>> doing this.
>> I have a commit queued up that moves lmb.c into the top-level lib
>> directory so other architectures can use it easily.  Dave Miller
>> wanted this so he could use it for sparc64.  That will go into Linus'
>> tree when the merge window opens and will be in 2.6.26.  So I don't
>> see any reason why microblaze couldn't use the LMB stuff.
>>
>
> Right, fair enough. I was mostly objecting to the idea of creating another
> copy of the lmb code when bootmem should be sufficient for what microblaze
> needs. Using the code from lib/lmb.c sounds fair enough when it's already
> there.
>
> One more reason for the microblaze kernel to base on top of linux-next
> instead of mainline.

For me is not difficult to use lmb from microblaze/mm or from lib if the files
are the same.

Michal Simek

Re: Microblaze Linux release

[Arnd Bergmann]

On Wednesday 16 April 2008, Michal Simek wrote:
> > One more reason for the microblaze kernel to base on top of linux-next
> > instead of mainline.
> 
> For me is not difficult to use lmb from microblaze/mm or from lib if the files
> are the same.
> 

What I meant is that there are a number of reasons to use linux-next
as a base for your kernel (this being one of them) and few against.

	Arnd <><

RE: [microblaze-uclinux] Re: Microblaze Linux release

[Stephen Neuendorffer]

> > * the consistent.c implementation looks strange. Is any of that code
> > even used anywhere? What is it good for, considering that you don't
have
> > an mmu?
> 
> We have prepared MMU code. I hope that this code for FDT kernel comes
soon.
> This code is written by John Williams. I have never changed it. I see
that this
> code solves problems around ucached_shadows stuff.
>
http://developer.petalogix.com/wiki/UserGuide/AdvancedTopics/EnablingUnc
achedShadow
> JW. Can you comment this?

It probably makes sense to grab: arch/microblaze/mm/dma-coherent.c from
git.xilinx.com and drop consistent.c.  I believe this is the more
'modern' way to implement this functionality.  I think it's easiest for
you to just grab this file.

> > * Your dma_mapping.h does BUG() for almost everything. I suspect you
could
> > easily replace it with a trivial implementation, like the x86_32
one.
> 
> OK. I'll synchronize this.

This is also in git.xilinx.com.

> > * You don't seem to have any code for PCI, so the pci.h and
pci-bridge.h
> > files don't make much sense.
> 
> Yes you are right. I don't have any PCI code but I think that this
code for MB
> exists. Steve or John: Do you have any code for PCI?

I'd recommend dropping anything having to do with PCI: I don't know that
there is much interest in it on microblaze.

Other comments:

memset/memmove/memcpy are broken under gcc4.  There are fixed versions
of this at git.xilinx.com.  Again, it's probably easiest if you just
grab the files directly.

It would also be good to have irq_of_parse_and_map, which drivers will
need.  I'll send you a patch for this one.

Steve

Re: [microblaze-uclinux] Re: Microblaze Linux release

[Michal Simek]

Hi Steve

>>> * the consistent.c implementation looks strange. Is any of that code
>>> even used anywhere? What is it good for, considering that you don't
> have
>>> an mmu?
>> We have prepared MMU code. I hope that this code for FDT kernel comes
> soon.
>> This code is written by John Williams. I have never changed it. I see
> that this
>> code solves problems around ucached_shadows stuff.
>>
> http://developer.petalogix.com/wiki/UserGuide/AdvancedTopics/EnablingUnc
> achedShadow
>> JW. Can you comment this?
> 
> It probably makes sense to grab: arch/microblaze/mm/dma-coherent.c from
> git.xilinx.com and drop consistent.c.  I believe this is the more
> 'modern' way to implement this functionality.  I think it's easiest for
> you to just grab this file.

I'll look at it.

>>> * Your dma_mapping.h does BUG() for almost everything. I suspect you
> could
>>> easily replace it with a trivial implementation, like the x86_32
> one.
>> OK. I'll synchronize this.
> 
> This is also in git.xilinx.com.

ok.

>>> * You don't seem to have any code for PCI, so the pci.h and
> pci-bridge.h
>>> files don't make much sense.
>> Yes you are right. I don't have any PCI code but I think that this
> code for MB
>> exists. Steve or John: Do you have any code for PCI?
> 
> I'd recommend dropping anything having to do with PCI: I don't know that
> there is much interest in it on microblaze.

I think I'll do it

> Other comments:
> 
> memset/memmove/memcpy are broken under gcc4.  There are fixed versions
> of this at git.xilinx.com.  Again, it's probably easiest if you just
> grab the files directly.

NO. I fixed it. The problem was different as wrote Jan Engelhardt in previous
email. Changes are in repository. You have in xilinx repository only byte copy
and huge if 1 else endif. This is not acceptable. That's only as my explanation.

> It would also be good to have irq_of_parse_and_map, which drivers will
> need.  I'll send you a patch for this one.

This parts of code is coming with uartlite driver.

Thanks for your comments,
Michal

Re: Microblaze Linux release

[Michal Simek]

Hi all,

I update Microblaze kernel to latest Linus tree. I fixed some problems which
come with it.

Regards,
Michal


>>> One more reason for the microblaze kernel to base on top of linux-next
>>> instead of mainline.
>> For me is not difficult to use lmb from microblaze/mm or from lib if the files
>> are the same.
>>
> 
> What I meant is that there are a number of reasons to use linux-next
> as a base for your kernel (this being one of them) and few against.
> 
> 	Arnd <><
> 
> 

Re: Microblaze Linux release

[Florian Fainelli]

Hi Michal

Le mercredi 23 avril 2008, Michal Simek a écrit :
> Hi all,
>
> I update Microblaze kernel to latest Linus tree. I fixed some problems
> which come with it.

While reading the previous discussion, I wondered that keeping PCI would be a 
good idea. I am personnaly using it for a custom design and would be glad 
being able to continue using it.

If this represents too much work for you, we can probably add it later.

Great work !
-- 

Re: Microblaze Linux release

[Michal Simek]

Hi all

>>> * The semaphore implementation will be obsolete in 2.6.26
>> I don't know. Which cpu has correct implemetnation?
> 
> 2.6.26 will have a common implementation in kernel/semaphore.c.
> All you need is a one-line asm/semaphore.h to #include linux/semaphore.h.

I fixed this issue.

Regards,
Michal Simek

Re: Microblaze Linux release

[Arnd Bergmann]

On Wednesday 23 April 2008, Florian Fainelli wrote:
> While reading the previous discussion, I wondered that keeping PCI would be a 
> good idea. I am personnaly using it for a custom design and would be glad 
> being able to continue using it.
> 
> If this represents too much work for you, we can probably add it later.
> 

The problem as far as I can see is that the existing header files
just don't work without a platform implementation.

I think it would be less confusing to leave them out. If you 
need PCI, it's probably easier to add new files for these
and get them working at the same time.

	Arnd <><

Re: Microblaze Linux release

[Michal Simek]

Hi,

I am decided to remove content pci.h and pci-bridge.h. It is easier for me now.
This step comes soon. I gonna change consistent.c file with use it.

The files will be in asm folder because OF point to them but the files will be
empty or almost empty.

Regards,
Michal Simek



>> While reading the previous discussion, I wondered that keeping PCI would be a 
>> good idea. I am personnaly using it for a custom design and would be glad 
>> being able to continue using it.
>>
>> If this represents too much work for you, we can probably add it later.
>>
> 
> The problem as far as I can see is that the existing header files
> just don't work without a platform implementation.
> 
> I think it would be less confusing to leave them out. If you 
> need PCI, it's probably easier to add new files for these
> and get them working at the same time.
> 
> 	Arnd <><
> 
> 

Re: Microblaze Linux release

[Michal Simek]

> Hi Michal
> 
>> Hi all,
>>
>> I update Microblaze kernel to latest Linus tree. I fixed some problems
>> which come with it.
> 
> While reading the previous discussion, I wondered that keeping PCI would be a 
> good idea. I am personnaly using it for a custom design and would be glad 
> being able to continue using it.

I'll add PCI parts as I will have a reason to do it. I have no PCI devices
connected to MB now.

> If this represents too much work for you, we can probably add it later.

yes. This is lot of work for me unfortunately without any commercial support.

> Great work !

Have a good day,
Michal Simek

Re: Microblaze Linux release

[Michal Simek]

Hi,


>> I'd recommend splitting prom.c into code that can be shared between powerpc
>> and microblaze and architecture specific code. Anything that deals with
>> LMB should go into powerpc, and you can simply use the alloc_bootmem
>> mechanism for your architecture.
> 
> That is non trivial... the unflatten DT code among others relies heavily
> on the LMB's to allocate the objects.
> 
> We could split the early accessors, unflatten code, and kernel-side
> accessors at one point, though we already did most of it no ?
> 
> Ben.

I look at latest LMB version currenty in lib folder. There is some changes which
I think go against version.

I would like to ask some question about.

in include/asm-powerpc/lmb.h is written LMB_REAL_LIMIT.

Is this real limit memory limit? Why I ask. I think powerpc start with main
memory from zero address and you can set your high limit from zero. In this case
is high limit equal to size of memory.

In Microblaze systems we don't have main memory from zero. Starting point can be
everywhere in 2^32.

I hope I can avoid in this constant in MB system and only direct start and size
mem with DTS description. Am I right?

The similar code was added to of files which are in arch/powerpc/kernel/ folder.
I would like to fix LMB and OF together.

I have some fixed around coding style violation. I'll send them ASAP.

I don't have any idea what files use Sparc. Can you inform me about? I don't
want to break something with MB port.

Thanks for info.

Regards,
Michal Simek

Re: Microblaze Linux release

[John Williams]

Hi,

On Wed, 2008-04-23 at 23:22 +0200, Michal Simek wrote:
> > Hi Michal
> > 
> >> Hi all,
> >>
> >> I update Microblaze kernel to latest Linus tree. I fixed some problems
> >> which come with it.
> > 
> > While reading the previous discussion, I wondered that keeping PCI would be a 
> > good idea. I am personnaly using it for a custom design and would be glad 
> > being able to continue using it.
> 
> I'll add PCI parts as I will have a reason to do it. I have no PCI devices
> connected to MB now.
> 
> > If this represents too much work for you, we can probably add it later.
> 
> yes. This is lot of work for me unfortunately without any commercial support.
> 
> > Great work !

I have a working PCI implementation that I will submit once Michal's
patches are finalised.

Unsurprisingly it is heavily derived from the PPC implementation, but
reworked a little bit.

Regards,

John

> 
> Have a good day,
> Michal Simek
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663