* strange problem while booting
@ 2001-03-20 23:10 Stefan Nunninger
2001-03-20 23:52 ` Amit D Chaudhary
2001-03-21 1:12 ` Dan Malek
0 siblings, 2 replies; 5+ messages in thread
From: Stefan Nunninger @ 2001-03-20 23:10 UTC (permalink / raw
To: linuxppc-embedded
Hello everybody,
Once more I've got a problem while trying to boot a montavista linux
2.2.14 on a custom board with a MPC860.
I'm using BDM4GDB for debugging and running linux.
Usually when booting linux it boots until it tries to load the
ramdisk. There it stops for a reason I did not manage to figure out
yet.
The output of the kernel looks like this:
--------------------------------------------------------
decomp : ZIMAGE_OFFSET: 0001C1F0
INITRD_OFFSET: 00077DF3
INITRD_SIZE: 0014D729
loaded at: 00100000 00100000
board data at: 001001E4 00100210
relocated to: 000F0100 000F012C
ZIMAGE_OFFSET: 0001C1F0
zimage_start : 0010C1F0
zimage_size : 00032BA2
initrd_start : 00167DF3
initrd_end : 002B551C
zimage at: 0010C1F0 0013ED92
initrd at: 00167DF3 002B551C
avail ram: 002B6000 01000000
Linux/PPC load:
Uncompressing Linux...
Gunzip ...
Dest address : 00000000
Dest length : 00100000
Source address : 0010C1F0
Now booting the kernel
Linux version 2.2.14 (stefan@paris.enst.fr) (gcc version 2.95.2
19991030 (2.95.3
prerelease/franzo)) #617 Mon Mar 19 18:15:35 CET 2001
Boot arguments: root=/dev/ram
time_init: decrementer frequency = 120000000/60
parse_options finished
Calibrating delay loop... 31.85 BogoMIPS
Memory: 14232k available (412k kernel code, 376k data, 24k init)
[c0000000,c1000000]
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
do_basic_setup
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
Starting kswapd v 1.5
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
ttyS02 at 0x0100 is a SCC
ttyS03 at 0x0200 is a SCC
pty: 256 Unix98 ptys configured
RAM disk driver initialized: 16 RAM disks of 4096K size
loop: registered device at major 7
RAMDISK: Couldn't find valid RAM disk image starting at 0.
function: /fs/super.c::mount_root says
Kernel panic: VFS: Unable to mount root fs on 01:00
Rebooting in 180 seconds..
While trying to debug this it appears that my board behaves in a
strange way I can not really understand. After resetting the board
(usually I turn of power for a second) and rebooting the kernel,
there is not the same kernel output instead I see one of the
following outputs:
--------------------------------------------------------
decomp : ZIMAGE_OFFSET: 0001C1F0
INITRD_OFFSET: 00077DE3
INITRD_SIZE: 0014D729
loaded at: 00100000 0010002C
board data at: 001001E4 00100210
relocated to: 000F0100 000F012C
ZIMAGE_OFFSET: 0001C1F0
zimage_start : 0010C1F0
zimage_size : 00032B94
initrd_start : 00167DE3
initrd_end : 002B550C
zimage at: 0010C1F0 0013ED84
initrd at: 00167DE3 002B550C
avail ram: 002B6000 01000000
Linux/PPC load:
Uncompressing Linux...
Gunzip ...
Dest address : 00000000
Dest length : 00100000
Source address : 0010C1F0
Now booting the kernel
- and nothing more.
When debugging this I found that the kernel switches on virtual
adresses and goes on until identify_machine. From there it branches
to a c-function. However this is not identify_machine but any other
function. As this makes no sense the kernel stops somewhere after.
--------------------------------------------------------
decomp : ZIMAGE_OFFSET: 0001C1F0
INITRD_OFFSET: 00077DF7
INITRD_SIZE: 0014D729
loaded at: 00100000 00110004
board data at: 001001E4 00100210
relocated to: 000F0100 000F012C
ZIMAGE_OFFSET: 0001C1F0
zimage_start : 0010C1F0
zimage_size : 00032BA5
initrd_start : 00167DF7
initrd_end : 002B5520
zimage at: 0010C1F0 0013ED95
initrd at: 00167DF7 002B5520
avail ram: 002B6000 01000000
Linux/PPC load:
Uncompressing Linux...
Gunzip ...
Dest address : 00000000
Dest length : 00100000
Source address : 0010C1F0
Now booting the kernel
Linux version 2.2.14 (stefan@paris.enst.fr) (gcc version 2.95.2
19991030 (21Boot arguments: root=/dev/ram
time_init: decrementer frequency = 120000000/60
parse_options finished
Calibrating delay loop... 31.74 BogoMIPS
Memory: 14232k available (412k kernel code, 376k data, 24k init)
[c0000000,]Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
do_basic_setup
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
Starting kswapd v 1.5
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
ttyS02 at 0x0100 is a SCC
ttyS03 at 0x0200 is a SCC
pty: 256 Unix98 ptys configured
RAM disk driver initialized: 16 RAM disks of 4096K size
loop: registered device at major 7
Machine check in kernel mode.
Caused by (from msr): regs c0165ca0 Unknown values in msr
NIP: 00000200 XER: 8000FF0A LR: C0019394 REGS: c0165ca0 TRAP: 0200
MSR: 00009002 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c0164000[1] 'swapper' mm->pgd c0070000 Last syscall: 120
last math 00000000
GPR00: C0019394 C0165D50 C0164000 0006F885 C0165D68 C015D000
00000000 00000
GPR08: C0076028 C015D000 00000000 000003F2 35000004 1111000D
1111000E 11110
GPR16: 11110010 11110011 11110012 11110013 00009032 00165E10
00000000 C0002
GPR24: C0009814 11110019 00000000 C015D000 C0164000 C00715E0
0006F885 C0071
Call backtrace:
00000023 30303020
this time I get a machine check exception. The backtrace does not
really help as there is nothing at this addresses.
yet another output looks like this:
--------------------------------------------------------
decomp : ZIMAGE_OFFSET: 0001C1F0
°²@..<L°...2N...<.N.ò¼...ÄòNN_.N_.._°..N..N...22L.2Å.B..I2..².I²¼0..²BL°_
... it goes on like this for quite a while
and finally I see this:
--------------------------------------------------------
Ä+Ä : ZIMAGE OFFSET: 0001C1F0
INITRD OFFSET: 00077DF7
INITRD SIZE: 0014D729
+Ä# #+: 00100000 00100080
Ä#_ #+# #+: 001001E4 00100210
_+Ä#+ +Ä: 000F0100 000F012C
ZIMAGE OFFSET: 0001C1F0
>+#± _+#_+ : 0010C1F0
>+#± _> : 00032BA6
Å+_ _+#_+ : 00167DF7
Å+_ Å : 002B5520
>+#± #+: 0010C1F0 0013ED96
Å+_ #+: 00167DF7 002B5520
#+#+ _#+: 002B6000 01000000
LÅ+|/PPC +Ä#:
UÅÄ+Ä___ű LÅ+|...
G+Å>Ä ...
D_+ #___ : 00000000
D_+ +ű+ : 00100000
SÄ+_ #___ : 0010C1F0
NÄ+ ÄÄ+ű + +_Å+
LÅ+| +__ÄÅ 2.2.14 (_+°#Å@Ä#__.Å_+.°_) (± +__ÄÅ 2.95.2 19991030
(2.95.3 Ä__+1BÄÄ+ #_±++Å+_: _ÄÄ+=/+/_#+
++ Å+: _+Å+_ °_Ä+Å< = 120000000/60
Ä#__ ÄÄ+ÄÅ_ °Å_
C#+_#+ű +#< +ÄÄÄ... 31.74 BıÄMIPS
M+Ä_<: 14232+ #+#+#+ (412+ +_Å+ Ä, 376+ #+#, 24+ Å+)
[0000000,1000000]
DÅ+_< #_ +#+ Å+__: 2048 (Ä__ 2, 16+)
B+°°_ # + Å++ Å+__: 16384 (Ä__ 4, 64+)
B+°°_ # #_ +#+ Å+__: 16384 (Ä__ 4, 64+)
P#± # #_ +#+ Å+__: 4096 (Ä__ 2, 16+)
POSIX ÄÅ°Ä_+#Å +_+ű < UNIFIX
Ä #_ _++Ä
LÅ+| NET4.0 °Ä_ LÅ+| 2.2
B#_ +ÄÄÅ S+#Å_# UÅ+__+< CÄ+Ä++_ SÄ+< NET3.039
S+#_+ű +_+#Ä + 1.5
CPM UART _+_ +__ÄÅ 0.03
++<S00 #+ 0|0280 _ # SMC
++<S01 #+ 0|0380 _ # SMC
++<S02 #+ 0|0100 _ # SCC
++<S03 #+ 0|0200 _ # SCC
Ä+<: 256 UÅ|98 Ä+<_ ÄÅ°±+_
RAM _+ _+_ Å+#+>: 16 RAM _+_ Ä° 4096K _>
+ÄÄÄ: _±_+_ + #+ +#+Ä_ 7
It appears that all upper case letters and numbers are correct. All
other characters are changed. These changes are not random. When
running the kernel several time the output is exactly the same.
By chance I connected this board to another debugger (VisionClick)
to see what happens there. Interestingly everything worked fine. It
gets until trying to boot the ramdisk. Thus I conclude there is
something wrong with my initialisation code in the bootloader. Some
values which are set by VisionClick might not be set properly by my
bootcode. Thus I tried to find any differences. All I could find was
this
REG VisionClick BDM4GDB
SIPEND 00000000 02A80000
MCR 0000003F 4080003F
PLPRCR 00700000 00704000
RSR 00000000 C0000000
PBDAT 00001EC4 00001DC4
I used the values of VisionClick to set up these register in
BDM4GDB. It did not help in any way. Next I've copied all register
values from VisionClick and set the values excactly like this in
BDB4GDB. But still no improvement.
The values which I normally initialize in my bootloader are as
follows:
DER = 0x2002000F
DEC = 0x7FFFFFFF
SYPCR = 0xffffff83
ICTRL = 0x00000007
ORx, BRx
UPMAx
MSTAT = 0x00000200
MAMR = 0x07821330
ICR = 0x0
MSR = 0x1042
IMMR = 0xFA200000
SIUMCR = 0x00292900
TBL = 0x0
TBU = 0x0
plprcr = 0x00700000
Is there something missing here?
Could anybody give me a hint what might be the reason for all this
strange behaviour. What could solve the problem?
I hope somebody has an idea as \x18I spend now nearly two weeks on that
without any result.
Many thanks
Stefan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: strange problem while booting
2001-03-20 23:10 strange problem while booting Stefan Nunninger
@ 2001-03-20 23:52 ` Amit D Chaudhary
2001-03-21 1:12 ` Dan Malek
1 sibling, 0 replies; 5+ messages in thread
From: Amit D Chaudhary @ 2001-03-20 23:52 UTC (permalink / raw
To: nunninger; +Cc: linuxppc-embedded
Hi,
I don't know your specific board or configuration, but here's what might
help.
It seems like the initrd is at another offset, while the kernel is
trying to get it from 0. What might go wrong, incorrect kernel being
used(for example, zImage instead of zImage.initrd) or incorrect .config
or image make settings.
Amit
Stefan Nunninger wrote:
> Hello everybody,
>
> Once more I've got a problem while trying to boot a montavista linux
> 2.2.14 on a custom board with a MPC860.
> I'm using BDM4GDB for debugging and running linux.
>
> Usually when booting linux it boots until it tries to load the
> ramdisk. There it stops for a reason I did not manage to figure out
> yet.
> The output of the kernel looks like this:
> --------------------------------------------------------
> decomp : ZIMAGE_OFFSET: 0001C1F0
> INITRD_OFFSET: 00077DF3
> INITRD_SIZE: 0014D729
> loaded at: 00100000 00100000
> board data at: 001001E4 00100210
> relocated to: 000F0100 000F012C
> ZIMAGE_OFFSET: 0001C1F0
> zimage_start : 0010C1F0
> zimage_size : 00032BA2
> initrd_start : 00167DF3
> initrd_end : 002B551C
> zimage at: 0010C1F0 0013ED92
> initrd at: 00167DF3 002B551C
> avail ram: 002B6000 01000000
>
> Linux/PPC load:
> Uncompressing Linux...
> Gunzip ...
> Dest address : 00000000
> Dest length : 00100000
> Source address : 0010C1F0
> Now booting the kernel
> Linux version 2.2.14 (stefan@paris.enst.fr) (gcc version 2.95.2
> 19991030 (2.95.3
> prerelease/franzo)) #617 Mon Mar 19 18:15:35 CET 2001
> Boot arguments: root=/dev/ram
> time_init: decrementer frequency = 120000000/60
> parse_options finished
> Calibrating delay loop... 31.85 BogoMIPS
> Memory: 14232k available (412k kernel code, 376k data, 24k init)
> [c0000000,c1000000]
> Dentry hash table entries: 2048 (order 2, 16k)
> Buffer cache hash table entries: 16384 (order 4, 64k)
> Page cache hash table entries: 4096 (order 2, 16k)
> POSIX conformance testing by UNIFIX
> do_basic_setup
> Linux NET4.0 for Linux 2.2
> Based upon Swansea University Computer Society NET3.039
> Starting kswapd v 1.5
> CPM UART driver version 0.03
> ttyS00 at 0x0280 is a SMC
> ttyS01 at 0x0380 is a SMC
> ttyS02 at 0x0100 is a SCC
> ttyS03 at 0x0200 is a SCC
> pty: 256 Unix98 ptys configured
> RAM disk driver initialized: 16 RAM disks of 4096K size
> loop: registered device at major 7
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> function: /fs/super.c::mount_root says
> Kernel panic: VFS: Unable to mount root fs on 01:00
> Rebooting in 180 seconds..
>
> While trying to debug this it appears that my board behaves in a
> strange way I can not really understand. After resetting the board
> (usually I turn of power for a second) and rebooting the kernel,
> there is not the same kernel output instead I see one of the
> following outputs:
> --------------------------------------------------------
> decomp : ZIMAGE_OFFSET: 0001C1F0
> INITRD_OFFSET: 00077DE3
> INITRD_SIZE: 0014D729
> loaded at: 00100000 0010002C
> board data at: 001001E4 00100210
> relocated to: 000F0100 000F012C
> ZIMAGE_OFFSET: 0001C1F0
> zimage_start : 0010C1F0
> zimage_size : 00032B94
> initrd_start : 00167DE3
> initrd_end : 002B550C
> zimage at: 0010C1F0 0013ED84
> initrd at: 00167DE3 002B550C
> avail ram: 002B6000 01000000
> Linux/PPC load:
> Uncompressing Linux...
> Gunzip ...
> Dest address : 00000000
> Dest length : 00100000
> Source address : 0010C1F0
> Now booting the kernel
>
> - and nothing more.
> When debugging this I found that the kernel switches on virtual
> adresses and goes on until identify_machine. From there it branches
> to a c-function. However this is not identify_machine but any other
> function. As this makes no sense the kernel stops somewhere after.
>
> --------------------------------------------------------
> decomp : ZIMAGE_OFFSET: 0001C1F0
> INITRD_OFFSET: 00077DF7
> INITRD_SIZE: 0014D729
> loaded at: 00100000 00110004
> board data at: 001001E4 00100210
> relocated to: 000F0100 000F012C
> ZIMAGE_OFFSET: 0001C1F0
> zimage_start : 0010C1F0
> zimage_size : 00032BA5
> initrd_start : 00167DF7
> initrd_end : 002B5520
> zimage at: 0010C1F0 0013ED95
> initrd at: 00167DF7 002B5520
> avail ram: 002B6000 01000000
>
> Linux/PPC load:
> Uncompressing Linux...
> Gunzip ...
> Dest address : 00000000
> Dest length : 00100000
> Source address : 0010C1F0
> Now booting the kernel
> Linux version 2.2.14 (stefan@paris.enst.fr) (gcc version 2.95.2
> 19991030 (21Boot arguments: root=/dev/ram
> time_init: decrementer frequency = 120000000/60
> parse_options finished
> Calibrating delay loop... 31.74 BogoMIPS
> Memory: 14232k available (412k kernel code, 376k data, 24k init)
> [c0000000,]Dentry hash table entries: 2048 (order 2, 16k)
> Buffer cache hash table entries: 16384 (order 4, 64k)
> Page cache hash table entries: 4096 (order 2, 16k)
> POSIX conformance testing by UNIFIX
> do_basic_setup
> Linux NET4.0 for Linux 2.2
> Based upon Swansea University Computer Society NET3.039
> Starting kswapd v 1.5
> CPM UART driver version 0.03
> ttyS00 at 0x0280 is a SMC
> ttyS01 at 0x0380 is a SMC
> ttyS02 at 0x0100 is a SCC
> ttyS03 at 0x0200 is a SCC
> pty: 256 Unix98 ptys configured
> RAM disk driver initialized: 16 RAM disks of 4096K size
> loop: registered device at major 7
> Machine check in kernel mode.
> Caused by (from msr): regs c0165ca0 Unknown values in msr
> NIP: 00000200 XER: 8000FF0A LR: C0019394 REGS: c0165ca0 TRAP: 0200
> MSR: 00009002 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK = c0164000[1] 'swapper' mm->pgd c0070000 Last syscall: 120
> last math 00000000
> GPR00: C0019394 C0165D50 C0164000 0006F885 C0165D68 C015D000
> 00000000 00000
> GPR08: C0076028 C015D000 00000000 000003F2 35000004 1111000D
> 1111000E 11110
> GPR16: 11110010 11110011 11110012 11110013 00009032 00165E10
> 00000000 C0002
> GPR24: C0009814 11110019 00000000 C015D000 C0164000 C00715E0
> 0006F885 C0071
> Call backtrace:
> 00000023 30303020
>
> this time I get a machine check exception. The backtrace does not
> really help as there is nothing at this addresses.
>
> yet another output looks like this:
> --------------------------------------------------------
> decomp : ZIMAGE_OFFSET: 0001C1F0
> °²@..<L°...2N...<.N.ò¼...ÄòNN_.N_.._°..N..N...22L.2Å.B..I2..².I²¼0..²BL°_
> ... it goes on like this for quite a while
>
> and finally I see this:
> --------------------------------------------------------
> Ä+Ä : ZIMAGE OFFSET: 0001C1F0
> INITRD OFFSET: 00077DF7
> INITRD SIZE: 0014D729
> +Ä# #+: 00100000 00100080
> Ä#_ #+# #+: 001001E4 00100210
> _+Ä#+ +Ä: 000F0100 000F012C
> ZIMAGE OFFSET: 0001C1F0
>
>> +#± _+#_+ : 0010C1F0
>> +#± _> : 00032BA6
>
> Å+_ _+#_+ : 00167DF7
> Å+_ Å : 002B5520
> >+#± #+: 0010C1F0 0013ED96
> Å+_ #+: 00167DF7 002B5520
> #+#+ _#+: 002B6000 01000000
>
> LÅ+|/PPC +Ä#:
> UÅÄ+Ä___ű LÅ+|...
> G+Å>Ä ...
> D_+ #___ : 00000000
> D_+ +ű+ : 00100000
> SÄ+_ #___ : 0010C1F0
>
> NÄ+ ÄÄ+ű + +_Å+
> LÅ+| +__ÄÅ 2.2.14 (_+°#Å@Ä#__.Å_+.°_) (± +__ÄÅ 2.95.2 19991030
> (2.95.3 Ä__+1BÄÄ+ #_±++Å+_: _ÄÄ+=/+/_#+
> ++ Å+: _+Å+_ °_Ä+Å< = 120000000/60
> Ä#__ ÄÄ+ÄÅ_ °Å_
> C#+_#+ű +#< +ÄÄÄ... 31.74 BıÄMIPS
> M+Ä_<: 14232+ #+#+#+ (412+ +_Å+ Ä, 376+ #+#, 24+ Å+)
> [0000000,1000000]
> DÅ+_< #_ +#+ Å+__: 2048 (Ä__ 2, 16+)
> B+°°_ # + Å++ Å+__: 16384 (Ä__ 4, 64+)
> B+°°_ # #_ +#+ Å+__: 16384 (Ä__ 4, 64+)
> P#± # #_ +#+ Å+__: 4096 (Ä__ 2, 16+)
> POSIX ÄÅ°Ä_+#Å +_+ű < UNIFIX
> Ä #_ _++Ä
> LÅ+| NET4.0 °Ä_ LÅ+| 2.2
> B#_ +ÄÄÅ S+#Å_# UÅ+__+< CÄ+Ä++_ SÄ+< NET3.039
> S+#_+ű +_+#Ä + 1.5
> CPM UART _+_ +__ÄÅ 0.03
> ++<S00 #+ 0|0280 _ # SMC
> ++<S01 #+ 0|0380 _ # SMC
> ++<S02 #+ 0|0100 _ # SCC
> ++<S03 #+ 0|0200 _ # SCC
> Ä+<: 256 UÅ|98 Ä+<_ ÄÅ°±+_
> RAM _+ _+_ Å+#+>: 16 RAM _+_ Ä° 4096K _>
> +ÄÄÄ: _±_+_ + #+ +#+Ä_ 7
>
> It appears that all upper case letters and numbers are correct. All
> other characters are changed. These changes are not random. When
> running the kernel several time the output is exactly the same.
>
> By chance I connected this board to another debugger (VisionClick)
> to see what happens there. Interestingly everything worked fine. It
> gets until trying to boot the ramdisk. Thus I conclude there is
> something wrong with my initialisation code in the bootloader. Some
> values which are set by VisionClick might not be set properly by my
> bootcode. Thus I tried to find any differences. All I could find was
> this
>
>
> REG VisionClick BDM4GDB
> SIPEND 00000000 02A80000
> MCR 0000003F 4080003F
> PLPRCR 00700000 00704000
> RSR 00000000 C0000000
> PBDAT 00001EC4 00001DC4
>
> I used the values of VisionClick to set up these register in
> BDM4GDB. It did not help in any way. Next I've copied all register
> values from VisionClick and set the values excactly like this in
> BDB4GDB. But still no improvement.
>
> The values which I normally initialize in my bootloader are as
> follows:
> DER = 0x2002000F
> DEC = 0x7FFFFFFF
> SYPCR = 0xffffff83
> ICTRL = 0x00000007
> ORx, BRx
> UPMAx
> MSTAT = 0x00000200
> MAMR = 0x07821330
> ICR = 0x0
> MSR = 0x1042
> IMMR = 0xFA200000
> SIUMCR = 0x00292900
> TBL = 0x0
> TBU = 0x0
> plprcr = 0x00700000
>
> Is there something missing here?
> Could anybody give me a hint what might be the reason for all this
> strange behaviour. What could solve the problem?
>
> I hope somebody has an idea as \x18I spend now nearly two weeks on that
> without any result.
>
> Many thanks
> Stefan
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: strange problem while booting
2001-03-20 23:10 strange problem while booting Stefan Nunninger
2001-03-20 23:52 ` Amit D Chaudhary
@ 2001-03-21 1:12 ` Dan Malek
2001-03-21 13:08 ` Stefan Nunninger
1 sibling, 1 reply; 5+ messages in thread
From: Dan Malek @ 2001-03-21 1:12 UTC (permalink / raw
To: nunninger; +Cc: linuxppc-embedded
Stefan Nunninger wrote:
> loaded at: 00100000 00100000
You have to load the bits into memory at or above 0x200000...NO, don't
change anything in the Makefile, just load the resulting bits like
this. The zImage decompressor has to relocate itself to 0x100000.
There
isn't any bss space allocated between the end of the data and the start
of the zImage/initrd in the downloaded image. Your decompressor code is
likely writing over the images.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: strange problem while booting
2001-03-21 1:12 ` Dan Malek
@ 2001-03-21 13:08 ` Stefan Nunninger
2001-03-21 13:47 ` Jerry Van Baren
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Nunninger @ 2001-03-21 13:08 UTC (permalink / raw
To: linuxppc-embedded
Hi Dan,
Dan Malek wrote:
> > loaded at: 00100000 00100000
>
> You have to load the bits into memory at or above 0x200000...NO, don't
> change anything in the Makefile, just load the resulting bits like
> this. The zImage decompressor has to relocate itself to 0x100000.
> There
> isn't any bss space allocated between the end of the data and the start
> of the zImage/initrd in the downloaded image. Your decompressor code is
> likely writing over the images.
The original value in the /mbxboot/Makefile from montavista was
0x180000. I changed this to 0x100000 because a older version we were
working on used this value. Anyway changing the value to 0x200000 or
0x300000 as well as 0x180000 did not change anything in the
described behaviour of linux.
This is what I got to see for a value of 0x200000:
--------------------------------------------------------
decomp : ZIMAGE_OFFSET: 0001C1F0
INITRD_OFFSET: 00077DE7
INITRD_SIZE: 0014D729
loaded at: 00200000 00202A40
board data at: 002001E4 00200210
relocated to: 001F0100 001F012C
ZIMAGE_OFFSET: 0001C1F0
zimage_start : 0020C1F0
zimage_size : 00032B98
initrd_start : 00267DE7
initrd_end : 003B5510
zimage at: 0020C1F0 0023ED88
initrd at: 00267DE7 003B5510
avail ram: 003B6000 01000000
Linux/PPC load:
Uncompressing Linux...
Gunzip ...
Dest address : 00000000
Dest length : 00100000
Source address : 0020C1F0
Now booting the kernel
... nothing more
Also I can't really believe that the kernel or the bootloader is
overwritten. If that were the case I would expect that nothing works
at all. But as I said at least on one debugging system the kernel
always reaches the point where it tries to load the ramdisk.
It might well be that the ramdisk is overwritten though. This could
explain why it can not be loaded. Still I can not find a reason for
the kernel to stop or to print such strange characters on the serial
line.
Do you (or anyone else) have some other suggestion what I could do?
Thank you
Stefan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: strange problem while booting
2001-03-21 13:08 ` Stefan Nunninger
@ 2001-03-21 13:47 ` Jerry Van Baren
0 siblings, 0 replies; 5+ messages in thread
From: Jerry Van Baren @ 2001-03-21 13:47 UTC (permalink / raw
To: linuxppc-embedded
The strange characters you were getting are reminiscent of DEC VT-100
"graphics" characters. On a VT (compatible) display, you can send an
escape sequence which makes the lower case ASCII characters turn into
characters that are line graphics, but the upper case characters are
unchanged. Note that this became part of the ANSI terminal
specification, and is implemented in most terminal programs. This
describes the funny characters you are seeing, although the actual
display values are not VT-100 style. Hmm, more advanced VT terminals
(VT-320++?) allowed downloadable character sets, you could be getting
into these character sets.
References:
http://www.linuxdoc.org/HOWTO/Text-Terminal-HOWTO-20.html
http://www.ecc400.com/java/twproae.htm
If this this theory is correct, you should be able to exit your
terminal program and restart it and the character set would be reset,
giving you back your lower case letters.
If this is what is happening, something is sending a bogus escape
sequence out the console port.
gvb
At 02:08 PM 3/21/01 +0100, Stefan Nunninger wrote:
[snip]
>It might well be that the ramdisk is overwritten though. This could
>explain why it can not be loaded. Still I can not find a reason for
>the kernel to stop or to print such strange characters on the serial
>line.
>
>Do you (or anyone else) have some other suggestion what I could do?
>
>Thank you
> Stefan
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-03-21 13:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-20 23:10 strange problem while booting Stefan Nunninger
2001-03-20 23:52 ` Amit D Chaudhary
2001-03-21 1:12 ` Dan Malek
2001-03-21 13:08 ` Stefan Nunninger
2001-03-21 13:47 ` Jerry Van Baren
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.