I am porting a Redhat's embedded linux kernel, mpc8xx-2.2.13 from the Redh EDK 1.0), to a new custom designed bd, with the mpc860. I am using a local RAM disk on this new bd.
I previously successfully used this version and my app on the MBX bd. With threads a-blazin' and ethernet comm and multi-cast, the whole kit and the kaboodle. I'm having trouble with the port to this new bd. I think this version mpc8xx-2.2.13 has not been used in any way other than using NFS to access a remote intrd (with /sbin/init and /app). I think it is buggy and I'm fighting another bug regarding initrd. The zImage (boot loader + zipped KERNEL + zipped RAM disk) is downloaded into RAM, starts the BOOT loader, unzips the kernel to 0x0000.0000, executes the initial kernel code, unzips the local RAM disk, starts booting the kernel code, and then tarnsfers control to the app. I can modify any of the stuff in the initrd, /sbin/init or /sbin/app, for example, and the app runs (at least for 10 secs I can do a reiterative printk(), then it bombs for some reason). But, if I modify the boot loader code or the kernel code, both of which sit ahead of the compressed initrd in the zImage, then there may or may not be a problem loading initrd. It's as though that adding or deleting code such as a printk() from these cause the initrd to be moved forward or backward and possibly losing alignment in the zImage, thus causing the gunzip to bomb. I sometimes get, after the compressed initrd is located, error msgs such as "invalid compressed image". Sometimes it just hangs. But, by merely adding a printk(), or just adjusting the code slightly, to start_kernel(), for instance, then the compressed initrd is located and unzipped and code execution is allowed to continue on to the app. When the code does execute all the way thru to executing the app, It will run for a while (few secs to several mins) and then die. If I try to create a thread, which I could do previously with the NFS/MBX version, then the app rteurns to /sbin/init for re-spawning. Does any of this ring a bell with anyone? :>) Thanks, Steven _______________________________________________ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
