OMAP3 beagleboard.org # mmcinit
OMAP3 beagleboard.org # fatload mmc 0 0x80300000 uImage
reading uImage
1892956 bytes read OMAP3 beagleboard.org # setenv bootargs
console=ttyS2,115200n8 noinitrd root=/dev/mmcblk0p2
video=omapfb:mode:1280x720@50 init=/init rootfstype=ext2 rw
rootdelay=1 nohz=off
OMAP3 beagleboard.org # bootm 0x80300000
## Booting kernel from Legacy Image at 80300000 ...
Image Name: Linux-2.6.27-omap1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1892892 Bytes = 1.8 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing
Linux....................................................................
and that's as far as it gets. and even if i somehow messed up the
root filesystem, i should still get the first part of the kernel
initialization until root filesystem access, at which point the kernel
would just fall down.
i've tried this several times with the same results each time. any
hints on what i might have done incorrectly?
rday
p.s. the SD card in question has no MLO or u-boot.bin in the first
partition, since i'm booting from NAND, as you can see above. so
maybe some other NAND-based u-boot environment variable is
conflicting.
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
>
> Robert,
>
> Is it "rev C" board ?
>
> Regards,
> Rupesh Gujare
yes, it is. does that mean i just did something dumb?
rday
> nop, nothing wrong. Binaries released have been tested with rev B.
> and I had seen others reporting same issue with rev. C . I will
> recommend to compile .29 kernel with android patches.
so at some point down the road, embinux will make available a new
ANDROID.tar.bz2 download with a new uImage we can test? excellent.
i'm looking forward to it.
rday
p.s. for clarity, it would be useful to, in that tarball, name the
uImage file with the kernel version. or have *some* way to tell what
kernel version is in the tarball. as it stands, there is absolutely
no identifying information anywhere until you try to boot.
> nop, nothing wrong. Binaries released have been tested with rev B.
> and I had seen others reporting same issue with rev. C . I will
> recommend to compile .29 kernel with android patches.
so at some point down the road, embinux will make available a new
ANDROID.tar.bz2 download with a new uImage we can test? excellent.
i'm looking forward to it.
rday
p.s. for clarity, it would be useful to, in that tarball, name the
uImage file with the kernel version. or have *some* way to tell what
kernel version is in the tarball. as it stands, there is absolutely
no identifying information anywhere until you try to boot.
========================================================================
On Thu, 21 May 2009, Rupesh Gujare wrote:nop, nothing wrong. Binaries released have been tested with rev B. and I had seen others reporting same issue with rev. C . I will recommend to compile .29 kernel with android patches.so at some point down the road, embinux will make available a new ANDROID.tar.bz2 download with a new uImage we can test? excellent. i'm looking forward to it.
-- Rupesh Gujare