Fwd: [arm-gnu] porting linux 2.6.18.1(EABI) support GCC-4.1.1(eabi) shell not coming

[Naval Saini]

Hi:

Hi Keon Kooi, it seems your patch is what we needed.

I further saw that, before we applied your patch there was a 'clz r1, r3'
instruction in objdump of busybox binary. At this instruction (maybe there
are others too) that we were getting an exception and jumping into the
kernel. This instruction is supported in v5 arch but not in v4, that we are
using (found on net).

So is this patch explained or is there more we are missing for informative
purpose on what this patch does? Its good enuf the shell is up.

Thanks and regards,
Naval Saini

On 2/19/07, Naval Saini <navalnovel at gmail.com> wrote:
>
> Hi Everyone:
>
> We have been able to move past init ( in busybox ).
> Earlier we were getting stuck while making first IOCTL  (with TIOCGSERIAL)
> call and then while close (2).   ( i commened console_init and hardcoded
> '/dev/console' in it ; and commened the line close (2) , next )
>
> But even after init, we donot get the shell.
>
> I find myself making a flurry of calls to do_notify_resume ( )    ( and
> then a do_signal , ... here is my result from printk's i put in the kernel -
> do_signal )
>
>  do_signal - syscall 0 , current->pid 119, current->gid 119
>  do_signal - syscall 1073913928 , current->pid 1, current->gid 1, signr -
> 0
>  do_signal - syscall 0 , current->pid 121, current->gid 121
>  do_signal - syscall 1073913928 , current->pid 1, current->gid 1, signr -
> 0
>  do_signal - syscall 0 , current->pid 123, current->gid 123
>  ...
>
> I find the value in parameter syscall quite absurd. Thats cause, when do_notify_resume
> calls do_signal ; the value in parameter (its the third param) is 10, 75,
> etc... but when i printk it, its 0 or some weird value.
>
> The stack frame in do_signal is as follows :-
>    do_signal
>    do_notify_resume
>    work_pending (asm)
>    exception                   ( SR: 0x ... some addr. )
>
>
> Also , would it be helpful to know, for which instruction/s is/are causing
> this exception?
>
> Help needed in zeroing down on the issue.
> By the way, other than the EABI patch for V4, i have tried all previous
> suggestions (without effect).  :-)
>
> Thanks for all the mails.
> Regards,
> Naval
>
> On 2/17/07, Koen Kooi <koen at dominion.kabel.utwente.nl> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Marcin Juszkiewicz schreef:
> > > Dnia piątek, 16 lutego 2007, George G. Davis napisał:
> > >>> CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
> > >> ISTR hereing that ARM eABI support in GCC requires/assumes an ARMv5TE
> > >> or greater processor.  Yet you're using an ARMv4T based processor.  I
> > >> don't know for certain if this is causing problems for you here but
> > >> perhaps other may comment on status of GCC ARM eABI support on ARMv4T
> > >> targets, e.g. if you built userland under the assumption that the
> > >> processor is ARMv5TE or above, it aint gonna work on an ARMv4T based
> > >> processor?
> > >
> > > Ångström distribution supports armv4t/EABI. All needed parts of
> > toolchain
> > > are available in OpenEmbedded buildsystem.
> > >
> > > We use gcc 4.1.1/binutils 2.17.50.0.5/glibc 2.5 with amount of patches
> > to
> > > get it working properly. IIRC only armv4 (for example sa1100) are not
> > > supported in EABI.
> >
> > You can disable thumb-interworking and patch each and every -Werror out
> > of libc to get it
> > to compile for strongarm. Or pester the gcc people to implement proper
> > armv4 support.
> >
> > regards,
> >
> > Koen
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20070221/5dad195d/attachment.htm