Microblaze init port v4
Hi everybody, current linux version is 2.6.26-rc8 and I think this is the right time to send latest patches againts rc8 for Microblaze CPU. I fixed there some issues which were reported to me. We have there still problem with syscalls and we don't have chance to fix it to stable version, this is not part which I can do yourself. Microblaze will be n + 1 platform which use some old syscalls. I hope you understand. I am sending more than 50 patches and I would like to see ACKs for patches which are good and comments for patches which are bad. Thanks for your time and review. Best regards, Michal Simek www.monstr.eu ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
On Thu, Jun 26, 2008 at 02:29:29PM +0200, [EMAIL PROTECTED] wrote: Hi everybody, current linux version is 2.6.26-rc8 and I think this is the right time to send latest patches againts rc8 for Microblaze CPU. ... Thanks for your work on getting the architecture included. I have two questions: Where can I find a toolchain for compiling a Microblaze kernel? What is the status of Microblaze support in upstream binutils and gcc? Best regards, Michal Simek TIA Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
On Thursday 26 June 2008, [EMAIL PROTECTED] wrote: We have there still problem with syscalls and we don't have chance to fix it to stable version, this is not part which I can do yourself. Microblaze will be n + 1 platform which use some old syscalls. I hope you understand. That still leaves the problem that a lot of your syscalls have bugs copied from other platforms. If you need to maintain backwards compatibility with your existing binaries, that's fine, but please fix the code you are adding. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
On Thursday 26 June 2008, Arnd Bergmann wrote: That still leaves the problem that a lot of your syscalls have bugs copied from other platforms. If you need to maintain backwards compatibility with your existing binaries, that's fine, but please fix the code you are adding. Sorry for my harsh words here, I should have read your patch set before commenting on the introduction. Most of the interfaces look good now, there are really just details left now. So contrary to what we had discussed before, you seem to have decided to try to maintain source level compatibility with old uClibc versions, but dropped binary compatibility that does not make much sense on your architecture (considering that people synthesize their CPU with a custom instruction set and then build kernel and user space for that), which sounds reasonable to me, based on the earlier discussion. On a more detailed level, there are a number of decisions in your syscall interface, so let me summarize what I see you have done and please tell me if this was all intentional or just an arbitrary decision that seemed good at some point: * off_t is 32 bit, and you use both off_t and loff_t based syscalls: This is required because uClibc calls both versions of the syscalls, otherwise you'd need to add a lot of code in uClibc. * You implement both legacy and rt signal interfaces, just like everyone else does. It probably seemed like a good idea because something might actually be using the legacy interfaces in arch/microblaze/kernel/signal.c, but AFAICT, neither libc nor uClibc has been using them in a very long time when they are both present, certainly longer than microblaze has been around. The fact that you never noticed the missing sigaltstack implementation is a good indication that this code has never seen any testing and probably has more bugs. * You have not implemented the *at() family of syscalls, which seems to be an accidental misimplementation, and you have consequently not removed the older versions of these syscalls, which is correct if you don't want to break source level compatibility. * Your syscall list follows the exact same numbering as i386, which is fairly unusual, but not incorrect, despite wasting a little memory on the unused slots. I suppose you did this in order to keep some level of binary compatibility with older user code. Since you are subtly breaking compatibility now, I would still recommend changing all the numbers so that you can guarantee that every old binary is obviously broken instead of showing random problems. * You are using sys_ipc and sys_socketcall instead of the broken-out syscalls, which is a direct consequence of following the i386 numbering scheme. * You have defined both stat and stat64, with different definitions. uClibc does have a copy of the two struct definitions, so you can't easily change them without changing uClibc as well. Otherwise it would have been good to define struct stat in the same way as struct stat64, and only provide sys_stat but not sys_stat64 as a syscall. * I have already commented on the __ARCH_WANT_SYS_* macros you define. Independent of the off_t, signal and *at() syscalls, I think you should reduce the number of them by as much as you can without breaking uClibc support. You can probably remove almost all of them (not __ARCH_WANT_SYS_RT_SIGACTION, __ARCH_WANT_STAT64 and __ARCH_WANT_SYS_SOCKETCALL, as I mentioned). * Your syscall_table now contains two entries for each of the uid32 functions, e.g __NR_setreuid32 and __NR_setreuid have different numbers but both point to sys_setreuid. No problem here, but a little unusual. As with the other functions I mentioned, uClibc and glibc always call the *32 variant if that is defined and the other one if it's not. I would suggest doing either #define __NR_setreuid32 __NR_setreuid #define __NR_setreuid 203 or (better) #undef __NR_setreuid32 #define __NR_setreuid 203 to make the architecture more regular in this regard. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
Arnd Bergmann wrote: * You are using sys_ipc and sys_socketcall instead of the broken-out syscalls, which is a direct consequence of following the i386 numbering scheme. Please pretty please kill, kill, kill... -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
Hi Adrian, On Thu, Jun 26, 2008 at 02:29:29PM +0200, [EMAIL PROTECTED] wrote: Hi everybody, current linux version is 2.6.26-rc8 and I think this is the right time to send latest patches againts rc8 for Microblaze CPU. ... Thanks for your work on getting the architecture included. I have two questions: Where can I find a toolchain for compiling a Microblaze kernel? I personally use petalogix toolchain from www.petalogix.com. What is the status of Microblaze support in upstream binutils and gcc? I don't have any information about. We will discuss with John Williams and guys from Xilinx what we can do for it. M Best regards, Michal Simek TIA Adrian No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date: 25.6.2008 04:13 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
Hi Arnd, On Thursday 26 June 2008, [EMAIL PROTECTED] wrote: We have there still problem with syscalls and we don't have chance to fix it to stable version, this is not part which I can do yourself. Microblaze will be n + 1 platform which use some old syscalls. I hope you understand. That still leaves the problem that a lot of your syscalls have bugs copied from other platforms. If you need to maintain backwards compatibility with your existing binaries, that's fine, but please fix the code you are adding. This is for now. I'll remove when I will have new toolchain. I saw an email from you about. M ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
On Thu, Jun 26, 2008 at 08:50:37PM +0200, Michal Simek wrote: Hi Adrian, On Thu, Jun 26, 2008 at 02:29:29PM +0200, [EMAIL PROTECTED] wrote: Hi everybody, current linux version is 2.6.26-rc8 and I think this is the right time to send latest patches againts rc8 for Microblaze CPU. ... Thanks for your work on getting the architecture included. I have two questions: Where can I find a toolchain for compiling a Microblaze kernel? I personally use petalogix toolchain from www.petalogix.com. What is the status of Microblaze support in upstream binutils and gcc? I don't have any information about. We will discuss with John Williams and guys from Xilinx what we can do for it. Thanks! M cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Microblaze init port v4
We're looking at putting a microblaze toolchain on git.xilinx.com, which will be slightly easier than grabbing all of petalinux, if people just want to compile test it. At the moment, we would very much like to push the microblaze architecture code to the gcc mainline. I believe the main barrier is that we don't have someone with the bandwidth to interact with the gcc community at the moment, although hiring someone to work on it may be in the works. (Anyone interested?) Steve -Original Message- From: Adrian Bunk [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 12:43 PM To: Michal Simek Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stephen Neuendorffer; John Linn; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Microblaze init port v4 On Thu, Jun 26, 2008 at 08:50:37PM +0200, Michal Simek wrote: Hi Adrian, On Thu, Jun 26, 2008 at 02:29:29PM +0200, [EMAIL PROTECTED] wrote: Hi everybody, current linux version is 2.6.26-rc8 and I think this is the right time to send latest patches againts rc8 for Microblaze CPU. ... Thanks for your work on getting the architecture included. I have two questions: Where can I find a toolchain for compiling a Microblaze kernel? I personally use petalogix toolchain from www.petalogix.com. What is the status of Microblaze support in upstream binutils and gcc? I don't have any information about. We will discuss with John Williams and guys from Xilinx what we can do for it. Thanks! M cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Microblaze init port v4
Hi, On 6/27/08, Adrian Bunk [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 02:29:29PM +0200, [EMAIL PROTECTED] wrote: current linux version is 2.6.26-rc8 and I think this is the right time to send latest patches againts rc8 for Microblaze CPU. ... Thanks for your work on getting the architecture included. I have two questions: Where can I find a toolchain for compiling a Microblaze kernel? We bundle it in the PetaLinux distro: http://developer.petalogix.com What is the status of Microblaze support in upstream binutils and gcc? noMMU uClibc toolchain is at 3.4.1, MMU/glibc is at 4.1.1 Xilinx does their gcc/binutils stuff mostly in-house, and none of it is upstream. We (PetaLogix) build and distribute the uClibc toolchain, and we are slowly merging the MMU support across to our regular distro, that will also include the glibc tools. Cheers, John -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
