xzcat Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img.xz | sudo dd of=/dev/sdc bs=8M
This is interesting that the beaglebone support direct booting from a block device, which i am assuming that it is a micro-sd card. The problem arises when the os try to determine the filesystem/partition table on the sd-card, since the first 512 bytes of the sd-card is used to store master boot record and partition table. I do not think the os can determine the partition table on this block device anymore, unless you can tell the block-device driver where to file the partition table. The BBone bootloader should be better off supporting direct booting from sector 1, and read first partition File-Allocation Table starting at LBA 8M+512bytes, since the kernel occupies the following 8M already.
Will it boot up and work ok if I replace the 3.2.34 uImage with my new 3.2.37+ uImage and the remove the 3.2.34 modules directory and replace it with the 3.2.37+ modules directory?
it should work ok. But i dont understand why a second kernel is stored on the root-filesystem; i thought the kernel image is memory loaded from the block device (from your first question). Unless the in-memory kernel chainload the second (real) kernel that resides on the root-filesystem.
About the modules, you do not have to replace, all modules should be installed in:
/usr/modules/
in your case, copy the module content from:
$HOME/kernel/kernel/rootfs/lib/modules/3.2.37+
-toan
xzcat
Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img.xz
> sudo dd of=/dev/sdc bs=8M
This is interesting that the beaglebone support direct booting from a
block device, which i am assuming that it is a micro-sd card. The problem
arises when the os try to determine the filesystem/partition table on the
sd-card, since the first 512 bytes of the sd-card is used to store master
boot record and partition table. I do not think the os can determine the
partition table on this block device anymore, unless you can tell the
block-device driver where to file the partition table. The BBone
bootloader should be better off supporting direct booting from sector 1,
and read first partition File-Allocation Table starting at LBA 8M+512bytes,
since the kernel occupies the following 8M already.
Huh? Is there a specific reason you are going around and spreading
misleading/incorrect information?
You don't need to worry about all of that. The bootloader will read the new
kernel from /boot/uImage as u-boot understands partition tables and ext4
file systems. We *could* us a dumber bootloader that just reads from
specific sector addresses, but we don't.
The dd operation above is just copying MBR, partition tables, file systems
and all to the uSD card from the image of a uSD card.
Will it boot up and work ok if I replace the 3.2.34 uImage with my new
3.2.37+ uImage and the remove the 3.2.34 modules directory and replace it
with the 3.2.37+ modules directory?
it should work ok. But i dont understand why a second kernel is stored on
the root-filesystem; i thought the kernel image is memory loaded from the
block device (from your first question). Unless the in-memory kernel
chainload the second (real) kernel that resides on the root-filesystem.
About the modules, you do not have to replace, all modules should be
installed in:
/usr/modules/<kernel version>
You mean /lib/modules/<kernel version>. The <kernel version> is 3.2.37+,
just like what is made by 'make MODULES_INSTALL'. The 'lib' folder is just
like what is made by 'make MODULES_INSTALL'.