login
Search
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. --
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. --
On Sun, 13 Apr 2008 15:26:57 +0200 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 --
I don't know who start with it. For me is not this point important. 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 --
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 --
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 <><
--
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 <>< --
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 * ...
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 This kernel don't need to keep backward compatibility. No one will port to 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 consult this with John Williams and this was result of our meeting. This structure is more comfortable for adding new platform inside distribution. I 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 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 Yes you are right. I don't have any PCI code but I think that this code for MB 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 Thanks for your review, Michal Simek www.monstr.eu --
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 2.6.26 will have a common implementation in kernel/semaphore.c. 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 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 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 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 ...
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 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 Yes Michal Simek www.monstr.eu --
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. --
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 <>< --
For me is not difficult to use lmb from microblaze/mm or from lib if the files are the same. Michal Simek --
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 <>< --
Hi all, I update Microblaze kernel to latest Linus tree. I fixed some problems which come with it. Regards, --
Hi Michal 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 ! -- --
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 <>< --
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, --
I'll add PCI parts as I will have a reason to do it. I have no PCI devices Have a good day, Michal Simek --
Hi, 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 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 --
Well, LMB code is moving to generic anyway... So we may as well move more stuff there ;-) Cheers, 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 --
http://developer.petalogix.com/wiki/UserGuide/AdvancedTopics/EnablingUnc 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 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 --
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 This parts of code is coming with uartlite driver. Thanks for your comments, Michal --
Thanks for your help. I know that the time is short.:-( We'll see. I will Include files are pain I know. Michal Simek www.monstr.eu --
