Welcome! Log In Create A New Profile

Advanced

Newer uBoot as workaround to 3.2 kernel problem?

Posted by davygravy 
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 12, 2012 03:32PM
@davygravy:

could you post a diff file with your changes over the git files?. I want to follow the same aproach in the pink pogo. If we unify efforts on both devices then we can release a new working u-boot that have been tested.

>> If I can just get original uboot.kwb back in NAND, then I should be able to test if it fully has all the capabilities of Jeff's uboot.

Jeff's enviroment (just a relevant part)

mtdids=nand0=orion_nand
partition=nand0,2
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi

when mtdids and mtdparts are configured and you configure your default partition you can try if it works instead of not having the original enviroment. You can try the follow approach:

mtdparts=orion_nand:1m(uboot),4m(test),-(data)
mtdids=nand0=orion_nand
partition=nand0,1

boot your linux from usb and format /dev/mtd1 (or your test partition) with jffs2 (flash_eraseall -j /dev/mtd1); then mount it in someplace with mount -t jffs2 /dev/mtdblock1 and write the original bootloader there...

in uboot's prompt you can check if ls shows you the old-bootloader file



Edited 1 time(s). Last edit at 02/12/2012 03:59PM by pazos.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 12, 2012 05:44PM
@ pazos: I diffed this against the last official release u-boot-2011.12

http://ppl.ug/bzcfH7bEFXs/

is my link to it... hosted on my pogoplug (sorry it is so large... I wasn't sure which source you had...)

=====================================================


Re: Newer uBoot as workaround to 3.2 kernel problem?
February 12, 2012 07:48PM
Thanks for your time

Uffff... Did you make a diff between the git repository and the ftp-stable-source???

Asumming that you don't modify any other file than include/configs/dockstar.h , please can you attach this file here.
If you modify some other file please tell me what?

l2_cache_disabled patch applies cleanly to stable 2011.12 denx version, and since there is not other remarkable upgrades for kirkwood users between versions, i suggest you to switch to lastest stable release for your tests.

I attach the kirkwood_disable_l2.patch, ready to be patched to 2011.12 version. Dockstar is supported by default, then you just need to modify the mentioned include/configs/dockstar to suit your needs!

Thanks again for all your work & time!!!
Attachments:
open | download - kirkwood_disable_l2_cache.patch (2.6 KB)
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 12, 2012 10:17PM
Yes, I am 99.99% sure I only altered dockstar.h.

Attached is the that file from include/configs/dockstar.h. {obsolete : deleted }

I will however, rebuild here, using the MWalle L2CacheDisable patch, with my dockstar.h config and test it ... just to be sure. It should load into SDRAM fine, for checking.

Will let you know for sure.

=====================================================





Edited 1 time(s). Last edit at 02/24/2012 09:21PM by davygravy.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 12, 2012 10:53PM
Looks good!!!
Confirming what we were hoping... only the L2CacheDisable.patch and the altered config are needed for my dockstar. I have not tested this to boot the PogoPlugCE image, though. Mine was erase a few days back, and I'm not sure I want to put it back on. ( I have a regular PogoPlug for that. :) )

It boots the vanilla kernel (w/o the need for the weird "EMBEDDED" flag, etc , the P2V problem), and it boots the Rescue System (Jeff's very own).

u-boot>> tftpboot 0x800000 uboot.mtd0.kwb-2011.12-L2Cdisabled-davysconfig   
Using egiga0 device
TFTP from server 192.168.11.149; our IP address is 192.168.11.187
Filename 'uboot.mtd0.kwb-2011.12-L2Cdisabled-davysconfig'.
Load address: 0x800000
Loading: ####################################
done
Bytes transferred = 524288 (80000 hex)
u-boot>> nand erase 0x0 0x80000

NAND erase: device 0 offset 0x0, size 0x80000
Erasing at 0x60000 -- 100% complete.
OK
u-boot>> nand write.e 0x800000 0x0 0x80000

NAND write: device 0 offset 0x0, size 0x80000
 524288 bytes written: OK
u-boot>> reset
resetting ...


U-Boot 2011.12 (Feb 12 2012 - 21:33:07)
Seagate FreeAgent DockStar

SoC:   Kirkwood 88F6281_A0
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0 
u-boot>> version

U-Boot 2011.12 (Feb 12 2012 - 21:33:07)
Seagate FreeAgent DockStar
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709

=====================================================


Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 13, 2012 08:38AM
Had some corrupted MTD partitions, so I decided to reload the original Dockstar u-boot and firmware: ( I knew there was something wrong when not even Jeff's u-boot would load the original firmware!)

Pleased to report that the new u-boot seems to function flawlessy (netconsole should work). Was able to load and boot Jeff's u-boot into the original Dockstar environment; and was also able to load and boot uboot.mtd0.dockstar.original.kwb.

I suppose it's just a matter of thorough testing.

Good work davygravy & pazos
Debian Wheezy has upgraded to Kernel 3.2, which won't boot anymore on my Pogoplug and I assume I've hit the uboot problem you've been discussing in this thread. So, would I just pull the current denx repository, configure it according to pazos post on the previous page, apply the l2 patch, change dockstar.h, make and flash uboot and I'm set? Or did I miss something?

Would be nice to finally have 3.2, since CVE-2012-0056 still isn't fixed in Wheezy.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 13, 2012 06:03PM
@ nrq: yeah, the 3.2 problem is annoying w/ Wheezy. Apparently 3.2 has not only the L2Cache problem, but also a problem w/ udev that folks over at ArchLinuxArm are experiencing. Personally, I hope they skip 3.2 and put 3.3.y in Wheezy, instead.

As far as the u-boot upgrade goes, nrq, I'd try to wait a day or two - we need to test Netconsole functionality on it ... and maybe a few more things.

... unless you are willing to risk it ... I have one expendable Dockstar here... not sure if yours are "expendable".
(my others are _essential_)

For a Dockstar, you'd need to apply the L2CacheDisable.patch, something like the dockstar.h config (that I posted) in include/configs/ , and compile in on the Sourcery G++ Lite 2009q3-67 toolchain.

If you have a PogoPlug, then I believe you'd want to use the extra PogoPlug patch... but I've never built that one... maybe pazos could chime in for a more definitive answer.

In any case, flash at your own risk. It carries some inherent risk (though I've never completely bricked any box that I wasn't able to JTAG or serial-control my way out of, I hear that it can be done!).

=====================================================





Edited 1 time(s). Last edit at 02/13/2012 06:54PM by davygravy.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 13, 2012 06:28PM
I tested my dockstar w/ netconsole... seems to work... output below shows a successful interrupt of the boot process, printing a single env var from uboot, and a second boot process that was uninterrupted.
I still need to test the functionality of All of the things below have been checked over :
  1. enable/disable works
  2. tftpbooting works
  3. flashing/nanderase/write works
  4. boots Jeff's Rescue System works
  5. boots Wheezy using Wheezy's current stock 3.2.y kirkwood linux-iimage kernel works
  6. boots stock PogoPlug software a la Jeff Doozan setup, in case no rootfs is found on the USB drives works - could use verification on a "virgin" box
from the netconsole side.

davygravy@bitbaker64:~$ nc -up 6666 192.168.11.187 6666

U-Boot 2011.12 (Feb 12 2012 - 21:33:07)
Seagate FreeAgent DockStar
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Hit any key to stop autoboot:  9 
 0 
u-boot>> 

u-boot>> 

u-boot>> printenv ipaddr  
printenv ipaddr
ipaddr=192.168.11.187
u-boot>> boot
boot
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... EHCI timed out on TD - token=0x80008c80
4 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
** Block device usb 0 not supported

** Invalid boot device **
Creating 1 MTD partitions on "nand0":
0x000002500000-0x000010000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            219 MiB
UBI: number of good PEBs:        1752
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             1731
UBI: total number of reserved PEBs: 21
UBI: number of PEBs reserved for bad PEB handling: 17
UBI: max/mean erase counter: 1/1
UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:rootfs", error -19
Error reading superblock on volume 'ubi:rootfs'!
** Block device usb 0 not supported
** Block device usb 1 not supported
** Block device usb 2 not supported
** Block device usb 3 not supported
** Block device usb 0 not supported
** Block device usb 0 not supported
Wrong Image Format for bootm command
ERROR: can't get kernel image!
stopping USB..

NAND read: device 0 offset 0x100000, size 0x400000
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.32.18-dockstar
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3236180 Bytes = 3.1 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...


U-Boot 2011.12 (Feb 12 2012 - 21:33:07)
Seagate FreeAgent DockStar
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Hit any key to stop autoboot:  0 
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Loading file "/rescueme" from usb device 0:1 (usbda1)
** File not found /rescueme
reading /rescueme.txt

** Unable to read "/rescueme.txt" from usb 0:1 **
Creating 1 MTD partitions on "nand0":
0x000002500000-0x000010000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            219 MiB
UBI: number of good PEBs:        1752
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             1731
UBI: total number of reserved PEBs: 21
UBI: number of PEBs reserved for bad PEB handling: 17
UBI: max/mean erase counter: 1/1
UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:rootfs", error -19
Error reading superblock on volume 'ubi:rootfs'!
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1 bytes read
Found bootable drive on usb 0:1
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1623456 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4943795 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-3.3.0-rc3-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1623392 Bytes = 1.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-3.3.0-rc3-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4943731 Bytes = 4.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

=====================================================





Edited 7 time(s). Last edit at 02/16/2012 08:56PM by davygravy.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 14, 2012 01:42PM
Great work davygravy. I'm looking at uboot.mtd0.installer.sh. We must use CONFIG_ENV_OVERWRITE to be able to change ethaddr value as jeff doozan's installer does.

Both original pogoplug firmware & jeff's rescue system works on my pogoplug v2. I think that work its done. It could be a good idea to upgrade the uboot installer script, but I'm not sure if someone really needs it...

I'm going to test the new bootloader over this week, if I can see that everything works (like it seems to be) I will post uboot binaries here with some instructions to flash it over jeff doozan uboot (in this case we can delete all enviroment values added, cause the enviroment is not going to be overwritten).

PD: I added support for Iomega Iconnect to lastest 2011.12 u-boot (based on the openwrt patch and the work in this post). I've not flash it to ram yet but ram-loading works ok! I'm not sure if I need to work so much in Iconnect cause it hasn't the same firmware as docks & pogos and people over the net seems to be happy with the stock iconnect uboot ( not beeing able to boot newer kernels, but just a few of us really wants to have lastest kernel installed on our devices)

See you later
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 14, 2012 09:05PM
Just a note to myself... since I used the option to avoid automatic updates to the PogoPlug firmware, the hbplug service was not running when there was no Debian drive in the USB port(s)... so there was only the orange flashing light. I had disabled it... and thought somehow that something was broken or amiss w/ my u-boot. It is actually fine.

In my case, I have to reenable it manually...
-sh-3.2# /etc/init.d/hbmgr.sh restart

does just fine.

Now my Dockstar running my patch u-boot does function again properly as a PogoPlug Device, if I wish it to.

    1 root       3400 S   init       
    2 root            SW< [kthreadd]
    3 root            SWN [ksoftirqd/0]
    4 root            SW< [events/0]
    5 root            SW< [khelper]
   46 root            SW< [kblockd/0]
   49 root            SW< [khubd]
   51 root            SW< [kmmcd]
   65 root            SW  [crypto]
   66 root            SW  [crypto_ret]
   71 root            SW  [pdflush]
   72 root            SW  [pdflush]
   73 root            SW< [kswapd0]
   74 root            SW< [aio/0]
  225 root            SW< [mtdblockd]
  226 root            SW< [nftld]
  260 root            SW< [kcryptd/0]
  313 root       3404 S   udhcpc -b Pogoplug 
  315 root       3400 S   telnetd 
  318 root       2100 S   /usr/sbin/dropbear 
  319 root       2740 R   -sh 
  562 root            SW< [xce]
  563 root       1696 S   /usr/local/cloudengines/bin/hbwd /usr/local/cloudengi
  564 root      11852 S   /usr/local/cloudengines/bin/hbplug 
  635 root       3404 R   ps 



mount
rootfs on / type rootfs (rw)
/dev/root on / type jffs2 (ro)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw)
none on /tmp type tmpfs (rw)
/tmp/.cemnt/sda1 on /tmp/.cemnt/mnt_sda1 type vfat (rw,nosuid,nodev,noexec,noatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,utf8)

===============================

AHHA... in /etc/init.d/rcS
#Uncomment the line below to enable the pogoplug service
#/etc/init.d/hbmgr.sh start

=====================================================





Edited 2 time(s). Last edit at 02/14/2012 10:02PM by davygravy.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 14, 2012 09:43PM
pazos Wrote:
-------------------------------------------------------
> ... We must use
> CONFIG_ENV_OVERWRITE to be able to change ethaddr
> value as jeff doozan's installer does.
>


Maybe this is already enabled further up, in configs for the platform... I'll look into it. IIRC, I can change ethadd just fine via the setenv and fw_setenv.

Will double check that.

====================================
u-boot>> print ethaddr
print ethaddr
ethaddr=00:10:75:1A:5C:73
u-boot>> setenv ethaddr 00:10:75:1A:5C:74
setenv ethaddr 00:10:75:1A:5C:74
u-boot>> saveenv


u-boot>> print ethaddr
print ethaddr
ethaddr=00:10:75:1A:5C:74
u-boot>> 

u-boot>> reset
reset
resetting ...

U-Boot 2011.12 (Feb 12 2012 - 21:33:07)
Seagate FreeAgent DockStar
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Hit any key to stop autoboot:  9 

 0 
u-boot>> print ethaddr
print ethaddr
ethaddr=00:10:75:1A:5C:74
u-boot>>

I see that Jeff's script reads and greps/cuts out the ethaddr, and keeps it for "safety sake", then applies it into the new environment. This current config allows changes like that... ??? Is there some special situation in which this won't work, as it already is?

==================================

As far as CONFIG_ENV_OVERWRITE goes...
davygravy@bitbaker64:~/u-boot-2011.12/arch/arm$ fgrep  -rin 'CONFIG_ENV_OVERWRITE' .
./include/asm/arch-kirkwood/config.h:99:#define CONFIG_ENV_OVERWRITE	/* ethaddr can be reprogrammed */
./include/asm/arch/config.h:99:#define CONFIG_ENV_OVERWRITE	/* ethaddr can be reprogrammed */

It seems that it is already enabled for all kirkwood devices.

=====================================================





Edited 3 time(s). Last edit at 02/14/2012 11:00PM by davygravy.
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 06:06AM
Quote
pazos
I'm going to test the new bootloader over this week, if I can see that everything works (like it seems to be) I will post uboot binaries here with some instructions to flash it over jeff doozan uboot (in this case we can delete all enviroment values added, cause the enviroment is not going to be overwritten).

Consider the case where a person might want to perform a u-boot resetenv
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 07:37AM
Yes, exactly ... To have a way to recover from borked env vars.

=====================================================


Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 10:12AM
Quote
Robert Mugabe
Consider the case where a person might want to perform a u-boot resetenv

Yes, I didn't think in that posibility...

@davygravy: ok! I tested it, you're right. It is enabled by default on all kirkwood devices...

I have the same configuration as yours and everything is working right now. Do you expect to change some other variables? As I see in your include/configs/dockstar.h jeff usb_init script are NOT in the enviroment (some variables are installed with the enviroment but not declared in the configuration header itself)



Edited 1 time(s). Last edit at 02/15/2012 10:21AM by pazos.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 06:00PM
It looks like to me that he left the hard-coded (compiled-in) env variables somewhat spare and minimal. His script overlays those values with a superset (wider group) of env vars:

$FLASH_ERASE /dev/mtd0 0xc0000 1
  $NANDWRITE -s 786432 /dev/mtd0 "$UBOOT_ENV"

I want to look at the u-boot source code and make sure that everything agrees w/ expectations... and what Jeff has set up.

=====================================================


Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 06:21PM
Robert Mugabe Wrote:

> Consider the case where a person might want to
> perform a u-boot resetenv

I'm wondering if protectoff-erase-protecton has been deprecated in favor of resetenv?
Quite a few years back I set this article up http://buffalo.nas-central.org/wiki/U-boot_Default_Environmental_Variables_and_Values ...

I guess I want to read over things and see how they've changed code...

/*
 *  Environment variables configurations
 */
#ifdef CONFIG_CMD_NAND
#define CONFIG_ENV_IS_IN_NAND		1
#define CONFIG_ENV_SECT_SIZE		0x20000	/* 128K */
#else
#define CONFIG_ENV_IS_NOWHERE		1	/* if env in SDRAM */
#endif
/*
 * max 4k env size is enough, but in case of nand
 * it has to be rounded to sector size
 */
#define CONFIG_ENV_SIZE			0x20000	/* 128k */
#define CONFIG_ENV_ADDR			0xc0000
#define CONFIG_ENV_OFFSET		0xc0000	/* env starts here */

================================================

@ Mugabe : Interesting, as neither protect-[on | off] nor setenv appear in the list of commands supplied by help.

It looks like both of these may have been deprecated in favor of the nand sub-system commands:
u-boot>> nand help                                                              
nand - NAND sub-system                                                          
                                                                                
Usage:                                                                          
nand info - show available NAND devices                                         
nand device [dev] - show or set current device                                  
nand read - addr off|partition size                                             
nand write - addr off|partition size                                            
    read/write 'size' bytes starting at offset 'off'                            
    to/from memory address 'addr', skipping bad blocks.                         
nand read.raw - addr off|partition                                              
nand write.raw - addr off|partition                                             
    Use read.raw/write.raw to avoid ECC and access the page as-is.              
nand erase[.spread] [clean] off size - erase 'size' bytes from offset 'off'     
    With '.spread', erase enough for given file size, otherwise,                
    'size' includes skipped bad blocks.                                         
nand erase.part [clean] partition - erase entire mtd partition'                 
nand erase.chip [clean] - erase entire chip'                                    
nand bad - show bad blocks                                                      
nand dump[.oob] off - dump page                                                 
nand scrub [-y] off size | scrub.part partition | scrub.chip                    
    really clean NAND erasing bad blocks (UNSAFE)                               
nand markbad off [...] - mark bad block(s) at offset (UNSAFE)                   
nand biterr off - make a bit error at offset (UNSAFE)

=====================================================





Edited 1 time(s). Last edit at 02/15/2012 06:44PM by davygravy.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 07:17PM
Did Jeff (or does! Jeff) have a github account somewhere? I'd like to see what changes he made between the first uboot and the current one.

I'm wondering why he chose not to put all the usb scan script infrastructure in the hard-coded uboot env vars.

Less invasive? More flexibility?

???

=====================================================


dpffan
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 08:29PM
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 08:35PM
Jeff's git.

Quote
davygravy
I'm wondering why he chose not to put all the usb scan script infrastructure in the hard-coded uboot env vars.

I think flexibility. Jeff's original code is bespoke - dynamic loading of u-boot images is not particularly encouraged by Denx, and the original Dockstar u-boot/image did not support booting from external media.

saveenv has been replaced by env default -f



u-boot>> env
env - environment handling commands

Usage:
env default -f - reset default environment
env edit name - edit environment variable
env export [-t | -b | -c] [-s size] addr [var ...] - export environment
env import [-d] [-t | -b | -c] addr [size] - import environment
env print [name ...] - print environment
env run var [...] - run commands in an environment variable
env save - save environment
env set [-f] name [arg ...]

Here's my original environment before executing env default -f


u-boot>>   printenv
arcNumber=2998
baudrate=115200
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
bootdelay=3
console=ttyS0,115200
ethact=egiga0
ethaddr=00:10:75:xx:xx:xx
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
if_netconsole=ping $serverip
ipaddr=192.168.0.104
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
preboot=run if_netconsole start_netconsole
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
serverip=192.168.0.253
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_device=0:1
usb_init=run usb_scan
usb_root=/dev/sda1
usb_rootdelay=10
usb_rootfstype=ext2
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_scan_list=1 2 3 4
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params


After executing env default -f

u-boot>> env default -f
## Resetting to default environment
u-boot>> printenv
arcNumber=2097
baudrate=115200
bootcmd=run bootcmd_usb; usb stop; run bootcmd_pogo; reset
bootcmd_pogo=fsload uboot-original-mtd0.kwb; go 0x800200
bootcmd_usb=run usb_init; run usb_load_uimage; run set_bootargs_usb; run usb_boot;
bootdelay=3
console=ttyS0,115200
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
set_bootargs_usb=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts
usb_boot=if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000;else bootm 0x800000;fi;
usb_device=0:1
usb_init=usb start
usb_load_uimage=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage
usb_root=/dev/sda1
usb_rootdelay=10
usb_rootfstype=ext2


The actual initial environment used in the installation of Jeff's u-boot is uboot.environment. When I JTAGged my Dockstar I manually loaded uboot.environment. Basically, what I'm saying is that uboot.environment is not the same as the default (minimal) environment variables in dockstar.h


uboot.environment
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 08:47PM
resetenv has beeb replaced by env default -f !!
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 15, 2012 10:57PM
Yes, flexibility makes sense. Having too much stuff hard-coded seems a bit restrictive.

The flashing in of the extra or larger env var set w/ usb scripts in the uboot-install-scripts makes perfect sense. Easy to update or change env for lots of users, with a minimum of fuss. [ too bad there wasn't already a flag in uboot to append to the boot sequence to either enable or disable the L2Cache...just by setting an env var]

Thanks @ both Robert Mugabe & dpffann regarding the github account : https://github.com/doozan/uBoot/tree/master/environment has interesting and (very) familiar contents.

And for the env commands... strange that Denx hasn't put them into the online documentation: http://www.denx.de/wiki/view/DULG/UBootCmdGroupEnvironment

I'm guessing, Robert, that you could restore your env vars with env import ... though I'm curious to find a man page for env <command> ... though you've prolly already done that.

=================================

http://lists.denx.de/pipermail/u-boot/2011-March/089338.html
http://old.nabble.com/-U-Boot--using-%24%7Bvar%7D-with-env-import-td31274897.html#a31274897
some specifics about the new env subset of commands : http://lists.denx.de/pipermail/u-boot/2010-September/077035.html

It looks like the source for these env commands are in common/cmd_nvedit.c. Apparently the API has changed recently well, so documentation is sparse.

=====================================================





Edited 3 time(s). Last edit at 02/15/2012 11:46PM by davygravy.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 16, 2012 04:41PM
Finally I lent my pogo to a friend for a project. It means that not more testing for a while, I'll follow this post. When davygravy wants to upload a final version (and more than tested) of the file include/configs/dockstar.h I'll port it to support pogo_e02 (and test it, of course)

I hope it will be soon :)
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 16, 2012 09:00PM
I feel I have only one thing left to do, and that is to test the erasure and rewritting of the full environent variable area. It looks like Robert M has already done the first part of that (and prolly the 2nd part as well, by now), but I need to do it also, just for completeness's sake.

Can't be too sure w/ a bootloader.

=====================================================


Re: Newer uBoot as workaround to 3.2 kernel problem?
February 20, 2012 12:59AM
@ pazos : I couldn't help myself ... I went ahead and used your patch... as you alluded to there were some problems, but it did at least compile (my E02 bricked but that's what JTAG is for). I fixed up some data in board/Marvell/pogo_e02/kwbimage.cfg (had to compare it to Jeff's orginal pogopink patch). IMHO, the patch attached at page bottom is now complete.

The patch applies to u-boot-2011.12... once applied, you can apply the kirkwood-L2C-disable.patch... and build.

Done, I think ...[s]Getting closer now on the PogoV2(E02)... still a rough patch or two to smooth over... but... progress...[/s]
                                                                                     
U-Boot 2011.12 (Feb 20 2012 - 21:21:59)
Pogoplug E02

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0 
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1623456 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4943795 bytes read
## Booting kernel from Legacy Image at 00800000 ...
...
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.3.0-rc3-kirkwood (davygravy@bitbaker64) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 Sat Feb 11 11:22
[    0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Marvell SheevaPlug Reference Board
[    0.000000] Memory policy: ECC disabled, Data cache writeback
...
[   18.540381] console [ttyS0] enabled
[   18.544736] NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND 128MiB 3,3V 8-bit)
[   18.553253] Scanning device for bad blocks
[   18.633236] 4 cmdlinepart partitions found on MTD device orion_nand
[   18.639541] Creating 4 MTD partitions on "orion_nand":
[   18.644707] 0x000000000000-0x000000100000 : "u-boot"
[   18.650346] 0x000000100000-0x000000500000 : "uImage"
[   18.655952] 0x000000500000-0x000002500000 : "rootfs"
[   18.661526] 0x000002500000-0x000008000000 : "data"
[   18.667438] mousedev: PS/2 mouse device common for all mice
[   19.675673] rtc-mv rtc-mv: internal RTC not ticking
[   19.680662] i2c /dev entries driver
[   19.684312] cpuidle: using governor ladder
...

Debian GNU/Linux wheezy/sid debian ttyS0


...
root@debian:~# free
             total       used       free     shared    buffers     cached
Mem:        255436      34412     221024          0       1968      22728
-/+ buffers/cache:       9716     245720
Swap:       258044          0     258044

===================================================

Importantly, it will boot a stock Debian Wheezy kernel as it should - no freeze/stall at the "Starting kernel ... Uncompressing Linux... done, booting the kernel." message.

=====================================================





Edited 3 time(s). Last edit at 02/20/2012 11:34PM by davygravy.
Attachments:
open | download - pogo_e02-uboot2011.12_DG.patch (19.4 KB)
open | download - kirkwood_disable_l2_cache.patch (2.6 KB)
open | download - dockstar-uboot2011.12_DG.patch (3.1 KB)
Great work!

Sorry if I missed this, but will this patched u-boot also work with pre-3.2 kernels as well?
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 22, 2012 11:34PM
Yes, and it should be a pretty transparent drop-in replacement.

It will boot older kernels, newer kernels, and in case there is no USB rootfs detected, it will then try to boot whatever rootfs that it can find in NAND (pogoplug software or the rescue system).

=====================================================


Joschi75
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 23, 2012 03:23AM
Really great work :)

Are you considering to release your patched uBoot as an pre-compiled, easy to install package?
I do not have a environment to compile it on my own using your patches, given that it would be great if you can share your work so that it can be installed similar to Jeff's original uBoot (http://jeff.doozan.com/debian/uboot/)
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 23, 2012 03:32AM
davygravy Wrote:
-------------------------------------------------------
> Yes, and it should be a pretty transparent drop-in
> replacement.
>
> It will boot older kernels, newer kernels, and in
> case there is no USB rootfs detected, it will then
> try to boot whatever rootfs that it can find in
> NAND (pogoplug software or the rescue system).

Awesome! I can't wait to try it.
Re: Newer uBoot as workaround to 3.2 kernel problem?
February 23, 2012 05:05AM
Great ... I just picked up a semi-borked GoFlex Net for cheap.... hopefully I can fix it and use it for testing...

=====================================================


Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: