Re: ramdisk size is larger than 4MB
I did more debugging and something is really weird though. When the link address is changed to 0x80, when stepping through the kernel, I actually got the kernel boot successfully. However I let the kernel run through it would just crash. After crash the BDI2000 shows it stopped at __delay(). Well, actually it's nothing to do with gdb. When the link address is changed to 0x80, if the PPC_EARLY_DEBUG and PPC_EARLY_DEBUG_CPM are on, the built kernel can boot successfully. But without these EARLY_DEBUG, the kernel fails to boot. = bootm 500 ## Booting image at 0500 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1757354 Bytes = 1.7 MB Load Address: 0080 Entry Point: 00800554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0) Allocating 0x3a15a4 bytes for kernel ... gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0xbe4300 ^^The kernel stopped here. = bootm 500 ## Booting image at 0500 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1757742 Bytes = 1.7 MB Load Address: 0080 Entry Point: 00800554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0) Allocating 0x3a15a4 bytes for kernel ... gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0xbe4300 id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using My MPC870 machine description Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #5 Tue Aug 3 21:24:40 PDT 2010 bootconsole [udbg0] enabled ^The kernel continued booting. With the EARLY_DEBUG turned on, the link address is changed to 0x100, the built kernel can also boot successfully. However if the link address is changed to 0x200 or 0x400, the built kernel fails to boot. I think the kernel failure may be caused by some memory corruption. But will the bootwrapper relocation corrupt the kernel code? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
I found the link_address in the wrapper shell script sets the _start address. But after changing it to 0x80, the kernel failed to boot, shown below. There must be something also needs proper adjustment. What would that be? I did more debugging and something is really weird though. When the link address is changed to 0x80, when stepping through the kernel, I actually got the kernel boot successfully. However I let the kernel run through it would just crash. After crash the BDI2000 shows it stopped at __delay(). I also changed the link address to 0x400. During the function of_scan_flat_dt(early_init_dt_scan_chosen, NULL) called in early_init_devtree(), gdb shows the program (i.e. kernel) received a signal SIGSTOP. Why would the kernel crash during that time? of_scan_flat_dt() doesn't seem to be the cause of SIGSTOP. What would that be then? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
It should be fine to just change it locally. It would be a problem to change it upstream for all boards, since some supported boards have only 16MB (or even 8MB) of RAM. I'll definitely try to change it locally first. Would a configurable base address for the bootwrapper an acceptable solution? I found the link_address in the wrapper shell script sets the _start address. But after changing it to 0x80, the kernel failed to boot, shown below. There must be something also needs proper adjustment. What would that be? = bootm 400 ## Booting image at 0400 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1757356 Bytes = 1.7 MB Load Address: 0080 Entry Point: 00800554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x800 (128MB) ENET0: local-mac-address - 00:09:9b:01:58:64 CPU clock-frequency - 0x7270e00 (120MHz) CPU timebase-frequency - 0x7270e0 (8MHz) CPU bus-frequency - 0x3938700 (60MHz) zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0) Allocating 0x3a15a4 bytes for kernel ... gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0xbe4300 Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
One way to lift this limitation is to relocate the bootwrapper to somewhere else, say for example, 0x100 so that a 16MB initramfs can be loaded. If the bootwrapper is relocated, what else would be affected by this relocation? It should be fine to just change it locally. It would be a problem to change it upstream for all boards, since some supported boards have only 16MB (or even 8MB) of RAM. I'll definitely try to change it locally first. Would a configurable base address for the bootwrapper an acceptable solution? Another option is to provide a vmlinux_alloc callback to stick the kernel somewhere other than zero, at the cost of an extra image copy once the kernel runs to get itself back down to zero. This wasn't done in cuboot because it was considered better to adjust the bootwrapper link address at build time based on the kernel+ramfs image size, but that never got implemented. Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if the image fits there, and calls malloc otherwise? I'll look into this too. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ramdisk size is larger than 4MB
Hi, I have a ramdisk as RFS much larger than 4MB in a 2.4 kernel. In recent 2.6 kernels ramdisk is no longer supported so I decided to go with initramfs. However I found the initial RFS for initramfs is limited to 4MB since the bootwrapper locates at 0x40. One way to lift this limitation is to relocate the bootwrapper to somewhere else, say for example, 0x100 so that a 16MB initramfs can be loaded. If the bootwrapper is relocated, what else would be affected by this relocation? Another (better?) way may be to find a right file system for RFS such as JFFS2. My board has limited NOR flash (32MB) but larger RAM (128MB). There is not much space left in flash for RFS. Would you like to share some thoughts? Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
On Fri, 30 Jul 2010 00:00:52 -0700 Shawn Jin shawnx...@gmail.com wrote: Hi, I have a ramdisk as RFS much larger than 4MB in a 2.4 kernel. In recent 2.6 kernels ramdisk is no longer supported so I decided to go with initramfs. However I found the initial RFS for initramfs is limited to 4MB since the bootwrapper locates at 0x40. The uncompressed image, including both ramfs and kernel must fit below 4MB. One way to lift this limitation is to relocate the bootwrapper to somewhere else, say for example, 0x100 so that a 16MB initramfs can be loaded. If the bootwrapper is relocated, what else would be affected by this relocation? It should be fine to just change it locally. It would be a problem to change it upstream for all boards, since some supported boards have only 16MB (or even 8MB) of RAM. Another option is to provide a vmlinux_alloc callback to stick the kernel somewhere other than zero, at the cost of an extra image copy once the kernel runs to get itself back down to zero. This wasn't done in cuboot because it was considered better to adjust the bootwrapper link address at build time based on the kernel+ramfs image size, but that never got implemented. Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if the image fits there, and calls malloc otherwise? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
