printenv results

I have set up and done saveenv, but I can't see the dvi args in
printenv which explains why I'm always getting 640x480 display. I set
bootargs for "omapfb.mode=dvi:1280x720MR-16@60". My LCD screen is
capable of 1366x768@60Hz, Horizontal 24-83KHz and Vertical 50-75Hz.

OMAP3 beagleboard.org # printenv
bootcmd=if mmcinit; then if run loadbootscript; then run bootscript;
else if run loaduimage; then if run loadramdisk; then run ramboot; else
run mmcboot; fi; else run nandboot; fi; fi; else run nandboot; fi
bootdelay=10
baudrate=115200
loadaddr=0x80200000
rdaddr=0x81600000
console=ttyS2,115200n8
optargs=
mmcargs=setenv bootargs console=${console} ${optargs}
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
ramargs=setenv bootargs console=${console} ${optargs} root=/dev/ram0 rw
ramdisk_size=32768 initrd=${rdaddr},32M
ubifsargs=setenv bootargs console=${console} ${optargs}
root=ubi0:beagleroot ubi.mtd=4 rw rootfstype=ubifs
jffs2args=setenv bootargs console=${console} ${optargs}
root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; autoscr ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage.bin
loadramdisk=fatload mmc 0 ${rdaddr} ramdisk.gz
ramboot=echo Booting from ramdisk.gz ...; run ramargs; bootm ${loadaddr}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run jffs2args; nand read
${loadaddr} 280000 400000; bootm ${loadaddr}
usbtty=cdc_acm
stdout=serial,usbtty
stdin=serial,usbtty
stderr=serial,usbtty
serial=6b22000300000000040323090d00a00a

Environment size: 1300/131068 bytes
OMAP3 beagleboard.org #
I just noticed that reset.scr was not renamed to boot.scr, changed that
and I shall try reflashing nand - don' know if that may have been the cause.
Regards
Sid.

Hey, I’m only new to this myself, so I maybe wrong, but you dont seem to have any bootargs variable defined?

such as
bootargs=console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1024x768

setenv bootoargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1024x768’

or whatever you need

Hey, I'm only new to this myself, so I maybe wrong, but you dont seem to
have any bootargs variable defined?

That's why I also thought it strange. I have done that a few times and
saveenv after.
OK, I just did it all again, saveenv, then printenv showed it was OK,
but it had the preamble below before the stuff I saved. I issued the
boot command and it was 1280x720 as expected.
After a power off/on or reset it's back to 640x480 again, like saveenv
didn't really work.
Regards
Sid.

Dear Sid:

The “light blub” went on for me when I looked at the linux kernel while it was booting. With the string I originally thought was correct, the line after “kernel command arguments” said “unknown option”.

So, … the trick is that the syntax changed between 2.6.28 and 2.6.29 and one needs to look at the kernel booting to see if the kernel is happy with the command line. It will tell you.

Charles

Tue, 22 Sep 2009, Sid Boyce wrote:

OK, I just did it all again, saveenv, then printenv showed it was OK,
but it had the preamble below before the stuff I saved. I issued the
boot command and it was 1280x720 as expected.
After a power off/on or reset it's back to 640x480 again, like saveenv
didn't really work.

Upgrade your U-Boot. To my knowledge, the one which comes with the board discards env and always uses default settings. My opinion is that this behaviour should me made more known for everyone for example by printing this info in u-boot console or something.

However, this is in the FAQ already: BeagleBoardFAQ - eLinux.org

I have the original u-boot that came with the board (Feb 2009 Dirty).
It saves my enviroment varialbes no problem every time, so it must be something else.

Does the board confirm that the data was written to flash.

Stick up a full log, of before, during and after

Tue, 22 Sep 2009, Ian Coleman kirjoitti:

I have the original u-boot that came with the board (Feb 2009 Dirty).

There's your problem.

It saves my enviroment varialbes no problem every time, so it must be something else.

Yes, it saves them but at boot time it does not read them. Your U-boot _always_ uses the default env written inside the code when booted.

I have the original u-boot that came with the board (Feb 2009 Dirty).
It saves my enviroment varialbes no problem every time, so it must be
something else.

Texas Instruments X-Loader 1.4.2 (Aug 8 2008 - 16:59:05)
Reading boot sector
Booting from mmc

U-Boot 2009.01-dirty (Feb 19 2009 - 12:23:21)

I2C: ready
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
DRAM: 256 MB
NAND: 256 MiB
Using default environment <<====

Does the board confirm that the data was written to flash.

Stick up a full log, of before, during and after

This is part of dmesg after saveenv and a boot command when everything
is OK.
Environment size: 1300/131068 bytes
OMAP3 beagleboard.org # setenv bootcmd 'mmcinit; fatload mmc 0
0x80300000 uImage; bootm 0x80300000'^M
OMAP3 beagleboard.org # setenv bootargs 'console=ttyS2,115200n8
console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
omapfb.mode=dvi:1280x720MR-16@60'^M
OMAP3 beagleboard.org # saveenv^M
Saving Environment to NAND...
Erasing Nand...
^MErasing at 0x260000 -- 100% complete.
Writing to Nand... done
OMAP3 beagleboard.org # printenv^M
bootdelay=10
baudrate=115200
loadaddr=0x80200000
rdaddr=0x81600000
console=ttyS2,115200n8
optargs=
mmcargs=setenv bootargs console=${console} ${optargs}
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
ramargs=setenv bootargs console=${console} ${optargs} root=/dev/ram0 rw
ramdisk_size=32768 initrd=${rdaddr},32M
ubifsargs=setenv bootargs console=${console} ${optargs}
root=ubi0:beagleroot ubi.mtd=4 rw rootfstype=ubifs
jffs2args=setenv bootargs console=${console} ${optargs}
root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; autoscr ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage.bin
loadramdisk=fatload mmc 0 ${rdaddr} ramdisk.gz
ramboot=echo Booting from ramdisk.gz ...; run ramargs; bootm ${loadaddr}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run jffs2args; nand read
${loadaddr} 280000 400000; bootm ${loadaddr}
usbtty=cdc_acm
stdout=serial,usbtty
stdin=serial,usbtty
stderr=serial,usbtty
serial=6b22000300000000040323090d00a00a
bootcmd=mmcinit; fatload mmc 0 0x80300000 uImage; bootm 0x80300000
bootargs=console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rw
rootfstype=ext3 rootwait omapfb.mode=dvi:1280x720MR-16@60

Environment size: 1286/131068 bytes
OMAP3 beagleboard.org # setenv bootcmd 'mmcinit; fatload mmc 0
0x80300000 uImage.bin; bootm 0x80300000'^M
OMAP3 beagleboard.org # setenv bootargs 'console=ttyS2,115200n8
console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
omapfb.mode=dvi:1280x720MR-16@60'^M
OMAP3 beagleboard.org # saveenv^M
Saving Environment to NAND...
Erasing Nand...
^MErasing at 0x260000 -- 100% complete.
Writing to Nand... done
OMAP3 beagleboard.org # printenv^M
bootdelay=10
baudrate=115200
loadaddr=0x80200000
rdaddr=0x81600000
console=ttyS2,115200n8
optargs=
mmcargs=setenv bootargs console=${console} ${optargs}
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
ramargs=setenv bootargs console=${console} ${optargs} root=/dev/ram0 rw
ramdisk_size=32768 initrd=${rdaddr},32M
ubifsargs=setenv bootargs console=${console} ${optargs}
root=ubi0:beagleroot ubi.mtd=4 rw rootfstype=ubifs
jffs2args=setenv bootargs console=${console} ${optargs}
root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; autoscr ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage.bin
loadramdisk=fatload mmc 0 ${rdaddr} ramdisk.gz
ramboot=echo Booting from ramdisk.gz ...; run ramargs; bootm ${loadaddr}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run jffs2args; nand read
${loadaddr} 280000 400000; bootm ${loadaddr}
usbtty=cdc_acm
stdout=serial,usbtty
stdin=serial,usbtty
stderr=serial,usbtty
serial=6b22000300000000040323090d00a00a
bootcmd=mmcinit; fatload mmc 0 0x80300000 uImage.bin; bootm 0x80300000
bootargs=console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rw
rootfstype=ext3 rootwait omapfb.mode=dvi:1280x720MR-16@60

Environment size: 1290/131068 bytes
OMAP3 beagleboard.org # boot^M
reading uImage.bin

2991560 bytes read
## Booting kernel from Legacy Image at 80300000 ...
   Image Name: Angstrom/2.6.29/beagleboard
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 2991496 Bytes = 2.9 MB
   Load Address: 80008000
   Entry Point: 80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Error, the USB hardware is not on B modeUncompressing
Linux..................................................................................................................................................................................................
done, booting the kernel.
[ 0.000000] Linux version 2.6.29-omap1 (koen@dominion) (gcc version
4.3.3 (GCC) ) #1 PREEMPT Thu Sep 3 11:19:01 CEST 2009
[ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7),
cr=10c5387f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] OMAP3430 ES3.0
[ 0.000000] SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
[ 0.000000] Reserving 14680064 bytes SDRAM for VRAM
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 65024
[ 0.000000] Kernel command line: console=ttyS2,115200n8 console=tty0
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
omapfb.mode=dvi:1280x720MR-16@60

The failure after the reboot command.

Are we saying here that a different u-boot.bin is needed? I removed
u-boot-f.bin in case that was the problem.
Regards
Sid.

No, My beagle board and uboot respond to my enviromoent varialbes. If I change my resolution options, or the svideo options, the beagle board reacts, both after a reboot and a full power cycle. I can change the boot block, or remove it, and again the beagle board reacts.

I don’t know what that message is refereing to, I was saying that I don’t have any problems, and I have the same uboot as you.

I’ll have to look a bit closer at your log, I got Angstrom up and running, I didn’t use the scripts which flash the nand, I just had the MLO, uImage, and RFS, nothing else and it worked fine

whats instructions are you following?
Where did it say to name it uboot-f? The -f bit?

Heres an explanation from someone at beagleboard from another thread called “original uboot”.

Basically, the uBoot that comes flashed with the board is fine, but the on eon the RevCValidation page at google code has problems!

Thanks! Is it possible to disable the USB-tty-stuff (U-Boot
2009.01-dirty) without recompiling u-boot? Some env variable?

It also seems its resetting the env variables.

I will defer to others to help on this in detail, but this uboot uses
scripts to handle the booting process. You will find those scripts on the
same download page.

The u-boot.bin on the RevCValidation page ignores the environment
variables all the time and simply uses a default environment setting.
That default environment setting tries to read a script file for
further boot instructions.

The u-boot that is flashed on the the board behaves normally,
respecting the u-boot environment variables. What happens, however,
is that if you have u-boot.bin on the SD card, x-loader loads that
u-boot over the one on the NAND flash.

So, the process is:

  • Is the USER button pressed at reset?
    ** Yes: Then poll for USB boot, Serial boot, SD boot (the MLO file in
    a special place on the card), and then the NAND flash.
    ** No: Then check the NAND flash first, then try the other boot modes
    if there is nothing valid on the flash.

  • Assuming we are running x-loader from the NAND flash as the Rev C
    boards are shipped, is there a u-boot.bin on the FAT formatted first
    partition of the SD card?
    ** Yes: Then load and run it. This might be the “hacked” u-boot.bin
    on the RevCValidation page that ignores the environment variables.
    ** No: Then check the location in the NAND flash reserved for u-boot
    and attempt to run that. This is the u-boot-flash.bin on the
    RevCValidation page. If it fails to run because it has been
    corrupted, the system will hang here.

  • Assuming we are running the u-boot from the NAND flash as the Rev C
    boards are shipped (u-boot-flash.bin), then are the environment
    variables saved?
    ** Yes: Then execute what the environment variables say to do,
    including not enable the usbtty, if that is desired.
    ** No: Then run the default environment variables and poll the SD card
    for a boot script, attempt to load a kernel from the SD card, then
    fall back to attempting to load a kernel from the NAND flash.

Hope this helps. I think we want to avoid changing this process
again, but some people are thinking it might be a good idea to include
a Linux kernel on the boards as they ship along with a minimal file
system and some way to read the sources directly off the NAND flash.
I’m open to this if someone can make something such that the Beagle
will show up as an MSC device and all the relevant sources actually
fit on the NAND. Thoughts?

  • Show quoted text -

whats instructions are you following?
Where did it say to name it uboot-f? The -f bit?

There is a separate u-boot-flash (u-boot-f.bin), but I am not sure what
it does. There is also u-boot.bin.
Regards
Sid.

Heres an explanation from someone at beagleboard from another thread
called "original uboot".

Basically, the uBoot that comes flashed with the board is fine, but the
on eon the RevCValidation page at google code has problems!

I don't remember where I got these from, but the u-boot.bin is the same
size as the one on the SD card, so it's almost certainly a copy of
u-boot_revc_v3.bin.
# l /BEAGLEBOARD/
total 10936
drwxr-xr-x 2 root root 4096 Aug 21 01:48 ./
drwxr-xr-x 37 root root 4096 Sep 22 16:28 ../
-rw-r--r-- 1 root root 0 Aug 21 01:48 .replay
-rw-r--r-- 1 lancelot users 20392 Jul 23 20:24 MLO_revc_v3
-rw-r--r-- 1 lancelot users 603 Jul 23 20:25 normal_revc_v3.scr
-rw-r--r-- 1 lancelot users 7999649 Jul 23 20:25 ramdisk_revc_v3.gz
-rw-r--r-- 1 lancelot users 679 Jul 23 20:25 reset_revc_v3.scr
-rw-r--r-- 1 lancelot users 275928 Jul 23 20:21 u-boot-f_revc_v3.bin
-rw-r--r-- 1 lancelot users 275904 Jul 23 20:24 u-boot_revc_v3.bin
-rw-r--r-- 1 lancelot users 2578044 Jul 23 20:25 uImage_revc_v3.bin
-rw-r--r-- 1 lancelot users 20392 Jul 23 20:25 x-load_revc_v3.bin.ift

# l /media/mmcblk0p1
total 3244
-rwxr-xr-x 1 root root 679 Sep 16 03:56 boot.scr
-rwxr-xr-x 1 root root 20392 Sep 16 03:56 mlo
-rwxr-xr-x 1 root root 603 Sep 16 03:56 normal.scr
-rwxr-xr-x 1 root root 275904 Sep 16 03:56 u-boot.bin
-rwxr-xr-x 1 root root 2991560 Sep 16 03:56 uImage.bin
-rwxr-xr-x 1 root root 19840 Sep 16 03:56 x-load.bin.ift
Regards
Sid.

Now found I got those files via
http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidation
Regards
Sid.