Denys Vlasenko wrote:
> On Tuesday 17 March 2009 18:27, Zachár Balázs wrote:
>> Hi,
>>
Hi,
Firstly thanks for the help!
>> I have a pxa270 based board, and I would like to renew the system on it...
>> I am using the emdebian's stable gnueabi cross-toolchain.
>> I have already recompile the kernel (both latest stable (2.6.28.7) and
>> testing (2.6.29-rc8)) and it works (boot up) now...
>>
>> I would like to use Busybox to init (and to many other :) )...
>>
>> I made a new root-filesystem structure, and I compiled a Busybox with the
>> same cross-toolchain which I used to compile the new kernel...
>>
>> But when I would like to boot up I get this error message:
>> VFS: Mounted root (nfs filesystem) on device 0:11.
>> Freeing init memory: 96K
>> Warning: unable to open an initial console.
>> Kernel panic - not syncing: Attempted to kill init!
>
> Look carefully: it does not say it cannot find /sbin/init.
> It says that it cannot open /dev/console,
> and then it says that *init exited*.
Yes I know this... If it can't find the /dev/console file it using the kernel
param to console...
>
>> So I compile this code to static using the cross-toolchain:
>> devel:/opt/rootfs# cat test_init.c
>> #include <stdio.h>
>>
>> int main()
>> {
>> printf("Hello world!\n");
>
> In order to exclude the possibility of stdio bug triggering,
> use write(1, "Hello world!\n", 12) instead.
I tried it, but I got the same error... :(
>
>> while(1);
>> return 0;
>> }
>>
>> And I copy it to my nfsroot/sbin/init
>>
>> I make two dev file (because I have my console on ttyS1 (kernel param:
>> console=ttyS1,115200)):
>> devel:~# ll /nfsroot/root/dev/console
>> crw------- 1 root tty 5, 1 2009-03-17 18:30 /nfsroot/root/dev/console
>> devel:~# ll /nfsroot/root/dev/ttyS1
>> crw-rw---- 1 root dialout 4, 65 2009-02-20 11:10 /nfsroot/root/dev/ttyS1
>
> Major/minor numbers look correct, but
> why they are in /nfsroot/root/dev instead of /nfsroot/dev?
Because I use the /nfsroot/ dir to hold some file to, but I use the
/nfsroot/root/ dir when I mount it to root...
>
>> Than I tried to boot up, but I got the same error like above:
>> Kernel panic - not syncing: Attempted to kill init!
>
> Do you still get "Warning: unable to open an initial console"
> just above this line? If yes, this is definitely a problem
> with /dev/console not being found.
No. After I made the /dev/console file the Warning disappeared...
>
> This will also make all init's messages to not be visible.
>
> However, it won't make init exit. This is a bit strange
> that it exits.
>
>> When I using the new kernel, with the old/orig rootfs (it is using busybox
>> too) content it boot up properly... But I would like to build a new system!
>>
>> Any Idea, where should I try?
>
> Another possibility is that your toolchain generates
> broken (crashing) executables (wrong CPU flavor selected, etc).
This Is what I am afraid... But I compile my new kernel with this
cross-toolchain and it boot up as far as the init call...
>
> If you have known working ("old") toolchain, build
> minimal-static-init-for-testing using it,
> but install it on new system. If it boots and you see
> "Hello world" (after you fixed "Warning: unable to open
> an initial console" problem), this confirms the theory
> about broken toolchain. Then use objdump and readelf
> to compare executables and find out what is wrong.
Good idea!
I have an old toolchain...
I tried it and it works... :(
Can be my new toolchain is bad after a success kernel compile? :(
After this bad news, I tried this:
Boot: New kernel, old system
Success boot!
Run: test_init (static linked, compiled with new toolchain: )
# /tmp/test_init_eabi
Segmentation fault
#
with gdb:
# gdb /tmp/test_init_eabi
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "arm-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /tmp/test_init_eabi
Program received signal SIGSEGV, Segmentation fault.
0x000118ec in uname ()
(gdb)
:(
But how can a bad cross-toolchain compile a good kernel and can't compile a
"Hello world!" ?????
regards,
Balazs
> --
> vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
