On Wed, 2008-01-16 at 09:16 +0300, Vitaly Bordug wrote: Greetings Vitaly !
> On Tue, 15 Jan 2008 23:25:02 +0000 > Bryan O'Donoghue wrote: > > > Greetings Scott. > > > > I've tried both of the procedures you've outlined on the Adder875 with > > the patches supplied against the paulus git tree to no avail. > > > > Pass #1 : > > > > Doing it safe with cuImage.8xx > > > > [...] > > => bootm 0x400000 > > ## Booting image at 00400000 ... > > Image Name: Linux-2.6.24-rc6-g4f43143f-dirty > > Image Type: PowerPC Linux Kernel Image (gzip compressed) > > Data Size: 1032266 Bytes = 1008.1 kB > > Load Address: 00400000 > > Entry Point: 00400554 > > Verifying Checksum ... OK > > Uncompressing Kernel Image ... OK > > > > I haven't as yet tried to single step through the bootup process - > > but, just to say that assuming the above procedure isn't _too_ far > > wrong - the stuff posted to the list agains the tree you've > > recommended doesn't seem to work.. > > > yes the sequence seems correct, so I'd check cmdline params, contents of > chosen node in dts, etc to make sure stuff is being written to the proper > UART with proper settings. Indeed - thing is for the cuImage.8xx it's definitely _not_ something simple like a UART not set at the expected baud rate. Using an Adder875 booted from U-Boot and cuImage.8xx with a a bdi2000 as a debugger - after the jump to kernel startup we don't even hit start_kernel ! There's no question about it - for whatever reason the cuImage.8xx for this board is definitely broken. I've been doing some experiments in the last hour or so mapping vmlinux to 0x400554 in gdb - since that's the entry point above - and setting an instruction breakpoint to do some instruction stepping. When I do that with cuImage.8xx I find that in kernel/head_8xx.S the code dies before going into virtual memory mode - haven't nailed down exactly where yet. Point being if I boot a uImage + dtb bootm 0x400000 - 0x500000 with a breakpoint set at start_kernel - then the uImage + dtb version _will_ hit start_kernel - where we are in virtual mode... _something_ wierd is for sure wrong with the cuImage.8xx and unfortunately it's not a simple as a silly baud rate. > > > following the u-boot way (which is more correct imo) you'll need to add some > code that fixes up frequencies and stuff inside dtb, or you may try to > hardcode those values inside dts(if you know exactly what should be there). > Just adding CONFIG_*LIBFDT is not going to work. I agree, makes sense to go with the flow of things tbh. It still leaves as unanswered why exactly the ucImage.8xx kernel dies suddenly before hitting start_kernel - whereas the uImage + dtb boy is getting much further along in the boot. I suppose I'll do some debug with the uImage - and try to see what else it wants to complete the boot though, it'd be nice if the cuImage worked so there'd be a safety net to use as a comparison to get the uImage + dtb running properly. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
