Newer uBoot as workaround to 3.2 kernel problem?
Posted by davygravy
|
Newer uBoot as workaround to 3.2 kernel problem? February 05, 2012 07:12PM |
Registered: 13 years ago Posts: 502 |
You can now upgrade your older U-Boot using Jeff's U-Boot Updater Script ...
but first :
1. You may want check that your netconsole or serial console connection is working correctly, just in case.
2. Before upgrading your U-Boot, it is a good idea to print out your U-Boot env and keep a copy of it as a file. This is especially important if you have made even the slightest alteration to the stock env. After the installer finishes running but before you reboot, make sure you check that you have your original values... a few of the values might have to be restored.
... and if you don't want to do it by an automated script ...
MANUAL Directions for Upgrading Your U-Boot are Below!!
Kernel 3.2.y introduced a default setting for the kernel that affects kirkwood machines in particular, because of an unintended u-boot behavior with regard to the Level2Cache and decompression of the kernel image. Call it a latent bug in u-boot, a regression in the kernel, or whatever... the defconfig kirkwood kernel build of 3.2.y (and by extension, higher versions) will fail to boot in most/many cases.
This left us with the choice between:
Since the kernel is updated more often than u-boot, it seems like it would be more of a hassle to kludge around it and compile a "special flavor" kernel just for kirkwood users. Working together, a few of us have put together patches and some basic testing to come up with updated u-boot images. A big thank you to Robert Mugabe and Pazos.
Our criteria were simple:
At the moment, the following machines seem pretty much taken care of:
[Pazos tells me that the stock u-boot on his Iomega iConnect seems to boot 3.2 and higher kernels just fine, so at the moment, there is no reason to build a newer u-boot for it.]
===========================================================================================
===========================================================================================
Manual Directions for upgrading the u-boot on your Dockstar, Pogoplug, or GoFlex Net/Home:
0. By doing any of the steps below, you agree to hold me blameless. I've flashed my devices w/ my u-boots quite a few times now, but there are no promises. If you make a mistake, or if the power to your Kirkwood device goes off/fails while you are flashing it, your device might be bricked, recoverable only by JTAG. You have been warned. You are nevertheless invited to continue, but only if you accept risk and responsibility.
1. Prepare your equipment, data files and your brain.
a. Backup your data and any contents you wish to keep.
b. Read through to the end, and make sure you understand each step, and how to recover in case of a bad erase.
c. Print out the contents of your NAND U-Boot env variables to a text file, or use nanddump. In either case, note your MAC address (aka hardware address, or ethaddr). Make a mental note to yourself and check that is unchanged after the upgrade process. [mine didn't change ever, but YMMV]
2. You should consider having a serial cable/adapter so that you can connect to your Pogoplug, Dockstar or other Kirkwood device, for emergency recovery.
3. Either enable netconsole and confirm its functionality, or use a serial cable/adapter, so that you can control u-boot on your Kirkwood device. Make sure you understand how netconsole works before venturing into this, also.
4. Set up a tftp server on your desktop/laptop/other-computer. Confirm that tftp transfers are working before flashing anything.
5. Based on which machine you have, download and _untar/gunzip_ one of these uboot.mtd0.kwb binaries:
*These images are based on 2011.12 source code, have all Jeff's features and capabilities, will boot the newer 3.2 (& higher) kernel, and contain a few minor fixes. I'll post patches ASAP. I'd originally thought to rework the patches based on 2012.6-ish source, but no further crucial changes would result from waiting for this, so its time to finish this.
6. (Re)Boot your Kirkwood device. Assuming it has one of Jeff's u-boot builds in NAND, when it powers up, you will see something like:
a. Once you see the Marvell>> prompt, check that you can pull in the image via tftp.
Execute:
If this is successful, you should see something like this:
STOP: Before going further double or triple check to make sure you have selected the correct filename that corresponds with your Kirkwood machine [Dockstar, Pogoplug E02, GoFlex Net/Home]. Flashing the wrong file in your machine will possibly brick it. Double check before going further. The filenames _must_ match. The "Bytes transferred" value _must_ match. If not, you should stop here and go no further.
b. Erase and flash; execute
If you have an erase/block problem, read through Jeff's original u-boot thread to see how people got around that problem.
If the nand write went as planned, you should see something like this:
c. If all is well, reset.
Your device should reboot now, but you will see newer uboot version information in the console or netconsole window:
You will now be able to boot a stock Debian 3.2 (or higher) kernel without having the decompression error that would cause so many Kirkwood machines to hang at boot time.
If you followed this howto command-for-command, you should not have to alter or restore any u-boot env variables. Of course, YMMV.
=========================================================================================
This makes it look more official: we might be SOL if the 3.2 regression is indeed handled as "really just a latent bug in uboot".
http://thread.gmane.org/gmane.linux.ports.arm.kernel/127951/focus=151172
Is anyone game to apply the L2cache disable patch?
It looks like it may become a necessary upgrade if users want to use the mainline kernel inthe future.
===========================
Has anyone tried this relatively new uBoot on their Dockstar? It looks like it was rolled by tbm (@debian.org)...
http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html
Hmmmm... sounds like a familiar problem: http://www.plugcomputer.org/plugforum/index.php?topic=5897.0
=====================================================
Edited 27 time(s). Last edit at 06/03/2012 12:32AM by davygravy.
but first :
1. You may want check that your netconsole or serial console connection is working correctly, just in case.
2. Before upgrading your U-Boot, it is a good idea to print out your U-Boot env and keep a copy of it as a file. This is especially important if you have made even the slightest alteration to the stock env. After the installer finishes running but before you reboot, make sure you check that you have your original values... a few of the values might have to be restored.
... and if you don't want to do it by an automated script ...
MANUAL Directions for Upgrading Your U-Boot are Below!!
Kernel 3.2.y introduced a default setting for the kernel that affects kirkwood machines in particular, because of an unintended u-boot behavior with regard to the Level2Cache and decompression of the kernel image. Call it a latent bug in u-boot, a regression in the kernel, or whatever... the defconfig kirkwood kernel build of 3.2.y (and by extension, higher versions) will fail to boot in most/many cases.
This left us with the choice between:
- not being able to boot a stock/normal debootstrapped Wheezy install (which will have a 3.2 or 3.3 kernel), and not being able to boot into future stock Debian Kirkwood kernels, or
- creating updated u-boot binaries that use the already-tested L2CacheDisable patch from Michael Walle (thanks Mike!) to the newest stable u-boot so that a normal default kernel will boot.
Since the kernel is updated more often than u-boot, it seems like it would be more of a hassle to kludge around it and compile a "special flavor" kernel just for kirkwood users. Working together, a few of us have put together patches and some basic testing to come up with updated u-boot images. A big thank you to Robert Mugabe and Pazos.
Our criteria were simple:
- make it boot 3.2 kernels and higher, with default (non-expert) config settings, as well as the older 2.6 and pre-3.2 stock Debian kernels,
- base it on the newest possible stable u-boot release, in order to make future adjustments easier,
- make it a drop-in replacement, fitting the footprint of Jeff's (etal) u-boot builds,
- allow the Pogoplug software/firmware to function normally if a bootable rootfs on USB or SATA is not found, just as with Jeff's
- no new features that would change the profile and, use the same u-boot environment space and values in NAND
- fix a bug on SATA machines where a drive was not recognized correctly
At the moment, the following machines seem pretty much taken care of:
- Dockstar
- Pogoplug V1/E01 {same u-boot as Dockstar}
- Pogoplug V2/E02
- GoFlex Net & GoFlex Home
[Pazos tells me that the stock u-boot on his Iomega iConnect seems to boot 3.2 and higher kernels just fine, so at the moment, there is no reason to build a newer u-boot for it.]
===========================================================================================
===========================================================================================
Manual Directions for upgrading the u-boot on your Dockstar, Pogoplug, or GoFlex Net/Home:
0. By doing any of the steps below, you agree to hold me blameless. I've flashed my devices w/ my u-boots quite a few times now, but there are no promises. If you make a mistake, or if the power to your Kirkwood device goes off/fails while you are flashing it, your device might be bricked, recoverable only by JTAG. You have been warned. You are nevertheless invited to continue, but only if you accept risk and responsibility.
1. Prepare your equipment, data files and your brain.
a. Backup your data and any contents you wish to keep.
b. Read through to the end, and make sure you understand each step, and how to recover in case of a bad erase.
c. Print out the contents of your NAND U-Boot env variables to a text file, or use nanddump. In either case, note your MAC address (aka hardware address, or ethaddr). Make a mental note to yourself and check that is unchanged after the upgrade process. [mine didn't change ever, but YMMV]
2. You should consider having a serial cable/adapter so that you can connect to your Pogoplug, Dockstar or other Kirkwood device, for emergency recovery.
3. Either enable netconsole and confirm its functionality, or use a serial cable/adapter, so that you can control u-boot on your Kirkwood device. Make sure you understand how netconsole works before venturing into this, also.
4. Set up a tftp server on your desktop/laptop/other-computer. Confirm that tftp transfers are working before flashing anything.
5. Based on which machine you have, download and _untar/gunzip_ one of these uboot.mtd0.kwb binaries:
- for Dockstar and Pogoplug V1/E01 [wallwart-ish] : dockstar and Pogoplug V1/E01 u-boot replacement filename=uboot.mtd0.kwb-2011.12-dockstar-L2Coff.kwb
- for Pogoplug V2/E02 : Pogoplug V2/E02 u-boot replacement filename=uboot.mtd0.kwb-2011.12-pogo_e02-L2Coff.kwb
- for GoFlex Net/Home : GoFlexNet/Home u-boot replacement filename=uboot.mtd0.kwb-2011.12-goflexnet-L2Coff-IDEpatched.kwb
*These images are based on 2011.12 source code, have all Jeff's features and capabilities, will boot the newer 3.2 (& higher) kernel, and contain a few minor fixes. I'll post patches ASAP. I'd originally thought to rework the patches based on 2012.6-ish source, but no further crucial changes would result from waiting for this, so its time to finish this.
6. (Re)Boot your Kirkwood device. Assuming it has one of Jeff's u-boot builds in NAND, when it powers up, you will see something like:
U-Boot 2010.09 (Oct 23 2010 - 11:51:16) Marvell-PinkPogo by Jeff Doozan SoC: Kirkwood 88F6281_A0 DRAM: 256 MiB NAND: 128 MiB In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>> Marvell>>Press any key to stop the boot process. You may have to press the key several times, or even hold it down for several seconds.
a. Once you see the Marvell>> prompt, check that you can pull in the image via tftp.
Execute:
tftpboot 0x800000 <filename>where <filename> is taken from the matching filename above
If this is successful, you should see something like this:
Marvell>> tftpboot 0x800000 uboot.pogoplugE02-arcNumfixed-L2Coff.kwb tftpboot 0x800000 uboot.pogoplugE02-arcNumfixed-L2Coff.kwb Using egiga0 device TFTP from server 192.168.11.149; our IP address is 192.168.11.150 Filename 'uboot.pogoplugE02-arcNumfixed-L2Coff.kwb'. Load address: 0x800000 Loading: #################################### done Bytes transferred = 524288 (80000 hex)The "Bytes transferred" value should be hex 80000 (decimal 524288) - if you don't get that value, then something is wrong.
STOP: Before going further double or triple check to make sure you have selected the correct filename that corresponds with your Kirkwood machine [Dockstar, Pogoplug E02, GoFlex Net/Home]. Flashing the wrong file in your machine will possibly brick it. Double check before going further. The filenames _must_ match. The "Bytes transferred" value _must_ match. If not, you should stop here and go no further.
b. Erase and flash; execute
nand erase 0x0 0x80000 nand write.e 0x800000 0x0 0x80000
If you have an erase/block problem, read through Jeff's original u-boot thread to see how people got around that problem.
If the nand write went as planned, you should see something like this:
Marvell>> nand erase 0x0 0x80000 nand erase 0x0 0x80000 NAND erase: device 0 offset 0x0, size 0x80000 Erasing at 0x60000 -- 100% complete. OK Marvell>> nand write.e 0x800000 0x0 0x80000 nand write.e 0x800000 0x0 0x80000 NAND write: device 0 offset 0x0, size 0x80000 524288 bytes written: OK
c. If all is well, reset.
Marvell>> reset
Your device should reboot now, but you will see newer uboot version information in the console or netconsole window:
U-Boot 2011.12 (May 28 2012 - 11:59:39) 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
You will now be able to boot a stock Debian 3.2 (or higher) kernel without having the decompression error that would cause so many Kirkwood machines to hang at boot time.
If you followed this howto command-for-command, you should not have to alter or restore any u-boot env variables. Of course, YMMV.
=========================================================================================
This makes it look more official: we might be SOL if the 3.2 regression is indeed handled as "really just a latent bug in uboot".
http://thread.gmane.org/gmane.linux.ports.arm.kernel/127951/focus=151172
Is anyone game to apply the L2cache disable patch?
It looks like it may become a necessary upgrade if users want to use the mainline kernel inthe future.
===========================
Has anyone tried this relatively new uBoot on their Dockstar? It looks like it was rolled by tbm (@debian.org)...
http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html
Hmmmm... sounds like a familiar problem: http://www.plugcomputer.org/plugforum/index.php?topic=5897.0
=====================================================
- davy's Github Repo's rescue-dg
Edited 27 time(s). Last edit at 06/03/2012 12:32AM by davygravy.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 06, 2012 04:59AM |
Registered: 13 years ago Posts: 78 |
davygravy Wrote:
> Hmmmm... sounds like a familiar problem:
> http://www.plugcomputer.org/plugforum/index.php?to
> pic=5897.0
hum, no. people at plugcomputer have no set console variable to ttyS0,115200. They can't see anything cause the kernel doesn't know how to notify its output.
anyways it could be an uboot problem, cause I've never seen someboby with that problem without jeff's uboot... (I didn't check if kernel 3.2 works on my iconnect too)
> Hmmmm... sounds like a familiar problem:
> http://www.plugcomputer.org/plugforum/index.php?to
> pic=5897.0
hum, no. people at plugcomputer have no set console variable to ttyS0,115200. They can't see anything cause the kernel doesn't know how to notify its output.
anyways it could be an uboot problem, cause I've never seen someboby with that problem without jeff's uboot... (I didn't check if kernel 3.2 works on my iconnect too)
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 06, 2012 02:56PM |
Registered: 13 years ago Posts: 502 |
Well, http://bugs.debian.org/658904.
Just and FYI for everyone, I guess.
=====================================================
Just and FYI for everyone, I guess.
=====================================================
- davy's Github Repo's rescue-dg
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 07, 2012 10:22PM |
Registered: 13 years ago Posts: 502 |
This makes it look more official: we might be SOL if the 3.2 regression is indeed handled as "really just a latent bug in uboot".
http://thread.gmane.org/gmane.linux.ports.arm.kernel/127951/focus=151172
Is anyone game to apply the L2cache disable patch?
It looks like it may become a necessary upgrade if users want to use the mainline kernel in the future.
=====================================================
http://thread.gmane.org/gmane.linux.ports.arm.kernel/127951/focus=151172
Is anyone game to apply the L2cache disable patch?
It looks like it may become a necessary upgrade if users want to use the mainline kernel in the future.
=====================================================
- davy's Github Repo's rescue-dg
|
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem? February 08, 2012 07:46AM |
Is anyone game to apply the L2cache disable patch?
In a word: NO! I prefer to roll my own rather than to use an antiquainted distribution mainline kernel, which never meets my specific requirements. Also, I am not a fan of one size fits all . It is sheer arrogance to expect users to perform a potentially risky "BIOS" upgrade to accommodate someone's whim or pet theory. Jeff's u-boot is solid, reliable, dependable, has well documented installation and configuration instructions AND has stood the test of time.
This works like a charm so I'll just default-select it.; NO IT DOESN'T!
Having said that, I've compiled u-boot (u-boot-2011.12 and from the latest git) but u-boot fails to load:
I basically followed these instructions to build u-boot, the general.patch failed, so I did not apply any of the patches and just cross-compiled a dockstar_config. I also tried to load the u-boot located at cyrius.com, but that also failed to load. uboot.mtd0.dockstar.original.kwb loads OK.
In a word: NO! I prefer to roll my own rather than to use an antiquainted distribution mainline kernel, which never meets my specific requirements. Also, I am not a fan of one size fits all . It is sheer arrogance to expect users to perform a potentially risky "BIOS" upgrade to accommodate someone's whim or pet theory. Jeff's u-boot is solid, reliable, dependable, has well documented installation and configuration instructions AND has stood the test of time.
This works like a charm so I'll just default-select it.; NO IT DOESN'T!
Having said that, I've compiled u-boot (u-boot-2011.12 and from the latest git) but u-boot fails to load:
U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan
SoC: Kirkwood 88F6281_A0
DRAM: 128 MiB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot: 0
Marvell>>
Marvell>>
Marvell>> setenv ipaddr 192.168.0.111
Marvell>> setenv serverip 192.168.0.120
Marvell>> tftp 0x800000 uboot.mtd0.kwb
Using egiga0 device
TFTP from server 192.168.0.120; our IP address is 192.168.0.111
Filename 'uboot.mtd0.kwb'.
Load address: 0x800000
Loading: #################################################################
######################################
done
Bytes transferred = 524288 (80000 hex)
Marvell>> go 0x800200
## Starting application at 0x00800200 ...
I basically followed these instructions to build u-boot, the general.patch failed, so I did not apply any of the patches and just cross-compiled a dockstar_config. I also tried to load the u-boot located at cyrius.com, but that also failed to load. uboot.mtd0.dockstar.original.kwb loads OK.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 08, 2012 04:21PM |
Registered: 13 years ago Posts: 502 |
I also try tbm's (Martin Michlmayer's) uboot from his cyrius site, with same outcome. Eventually I flashed back to Jeff's uboot.
This is interesting: http://git.denx.de/?p=u-boot/u-boot-marvell.git;a=commit;h=b18d3894611b7ae13683805b428b634ee0c715f0
Is there a way do a RAM build & test with uboot on ARM? I'd done it before on a PPC NAS machine.
=====================================================
Edited 1 time(s). Last edit at 02/08/2012 04:34PM by davygravy.
This is interesting: http://git.denx.de/?p=u-boot/u-boot-marvell.git;a=commit;h=b18d3894611b7ae13683805b428b634ee0c715f0
Is there a way do a RAM build & test with uboot on ARM? I'd done it before on a PPC NAS machine.
=====================================================
- davy's Github Repo's rescue-dg
Edited 1 time(s). Last edit at 02/08/2012 04:34PM by davygravy.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 08, 2012 05:21PM |
Registered: 13 years ago Posts: 502 |
OK, this one actually built for me... http://git.denx.de/?p=u-boot/u-boot-marvell.git;a=snapshot;h=b18d3894611b7ae13683805b428b634ee0c715f0;sf=tbz2
I can't load and test it now, as I have to go to class soon (only 2 more sessions to go - wooohooo!!)
I'll load and test it after I return. I just saw the link you posted, Mugabe. http://jeff.doozan.com/debian/uboot/build_uboot.htm
I've done a bit of work on ARM/Orion uboot before: I extended netconsole support to pre-netconsole source code here:
http://buffalo.nas-central.org/wiki/U-boot_for_LS_Pro#for_the_LS_Pro.2FLive_V1_and_V2_with_Netconsole_and_more_commands
I can take a look at the general patch. I'm assuming the dockstar patch is just to support the dockstar. It is supported now in git, and IIUC, in the last release.
=====================================================
I can't load and test it now, as I have to go to class soon (only 2 more sessions to go - wooohooo!!)
arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin tools/mkimage -n "/usr/src/u-boot-marvell/"board/Seagate/dockstar"/kwbimage.cfg" -T kwbimage \ -a 0x00600000 -e 0x00600000 -d u-boot.bin u-boot.kwb Preparing kirkwood boot image to boot from nand Nand ECC mode = default Nand page size = 0x800 Image Type: Kirkwood Boot from NAND Flash Image Data Size: 365224 Bytes = 356.66 kB = 0.35 MB Load Address: 00600000 Entry Point: 00600000
I'll load and test it after I return. I just saw the link you posted, Mugabe. http://jeff.doozan.com/debian/uboot/build_uboot.htm
I've done a bit of work on ARM/Orion uboot before: I extended netconsole support to pre-netconsole source code here:
http://buffalo.nas-central.org/wiki/U-boot_for_LS_Pro#for_the_LS_Pro.2FLive_V1_and_V2_with_Netconsole_and_more_commands
I can take a look at the general patch. I'm assuming the dockstar patch is just to support the dockstar. It is supported now in git, and IIUC, in the last release.
=====================================================
- davy's Github Repo's rescue-dg
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 08, 2012 11:43PM |
Registered: 13 years ago Posts: 502 |
OK, also won't run for me.
But some of the uboot*.kwb's execute just fine:
I agree, the original one loads and runs just fine, as well as all of the items in here that I tried:
http://jeff.doozan.com/debian/uboot/files/uboot/
Which codesourcery version are you using? Perhaps I need to use _exactly_ the one that Jeff used. I tried codesourcery-arm-2008q1.sh & codesourcery-arm-2011.09.sh. I think he was using 2009.q3?
Not sure that would account for the difference. I also wonder if there is a tiny yet significant between running it on Debian vs Ubuntu. I'd run into that before, years back.
I could try the denx toolchain, as well, if it is still available.
=====================================================
Edited 1 time(s). Last edit at 02/08/2012 11:59PM by davygravy.
But some of the uboot*.kwb's execute just fine:
Marvell>> tftp 0x800000 uboot.mtd0.goflexnet.jeff-2010-10-23.kwb Using egiga0 device TFTP from server 192.168.11.149; our IP address is 192.168.11.187 Filename 'uboot.mtd0.goflexnet.jeff-2010-10-23.kwb'. Load address: 0x800000 Loading: #################################### done Bytes transferred = 524288 (80000 hex) Marvell>> go 0x800200 ## Starting application at 0x00800200 ... U-Boot 2010.09 (Oct 23 2010 - 11:53:10) Marvell-GoflexNet by Jeff Doozan, Peter Carmichael SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: 256 MiB In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>>
I agree, the original one loads and runs just fine, as well as all of the items in here that I tried:
http://jeff.doozan.com/debian/uboot/files/uboot/
Which codesourcery version are you using? Perhaps I need to use _exactly_ the one that Jeff used. I tried codesourcery-arm-2008q1.sh & codesourcery-arm-2011.09.sh. I think he was using 2009.q3?
Not sure that would account for the difference. I also wonder if there is a tiny yet significant between running it on Debian vs Ubuntu. I'd run into that before, years back.
I could try the denx toolchain, as well, if it is still available.
=====================================================
- davy's Github Repo's rescue-dg
Edited 1 time(s). Last edit at 02/08/2012 11:59PM by davygravy.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 09, 2012 12:34AM |
Registered: 13 years ago Posts: 502 |
OK, success on building it "a la Jeff". Apparently his configuration choices for uboot enable the build to be loaded into RAM and started - the uboot at Martin Michlmayers site isn't set up this way I guess so it won't run from within uboot.
yeah, I had to fix one thing: boards.cgf:
for the pogoV2, add this instead, after applying Jeff's patches...
I'm now curious when cache.c was created in dockstar.
It wasn't in the source Jeff used, but it is in the newer source.
Some changes to u-boot-2011.12/include/configs/dockstar.h will have to be made to conform to Jeff's setup - that should be doable.
==============
=====================================================
Edited 5 time(s). Last edit at 02/19/2012 09:02PM by davygravy.
Marvell>> tftp 0x800000 uboot.mtd0.kwb Using egiga0 device TFTP from server 192.168.11.149; our IP address is 192.168.11.187 Filename 'uboot.mtd0.kwb'. Load address: 0x800000 Loading: #################################### done Bytes transferred = 524288 (80000 hex) Marvell>> go 0x800200 ## Starting application at 0x00800200 ... U-Boot 2010.09 (Feb 09 2012 - 00:29:39) Marvell-Dockstar/Pogoplug by Jeff Doozan SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: 256 MiB In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>>
yeah, I had to fix one thing: boards.cgf:
dockstar arm arm926ejs - Marvell kirkwood
for the pogoV2, add this instead, after applying Jeff's patches...
pinkpogo arm arm926ejs - Marvell kirkwood
I'm now curious when cache.c was created in dockstar.
It wasn't in the source Jeff used, but it is in the newer source.
Some changes to u-boot-2011.12/include/configs/dockstar.h will have to be made to conform to Jeff's setup - that should be doable.
==============
tftpboot 0x800000 uboot.mtd0.kwb-modded nand erase 0x0 0x80000 nand write.e 0x800000 0x0 0x80000
=====================================================
- davy's Github Repo's rescue-dg
Edited 5 time(s). Last edit at 02/19/2012 09:02PM by davygravy.
|
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem? February 09, 2012 07:43AM |
Tried to retro-fit the disable l2c before linux boot to Jeff's u-boot. After some hacking (most of which I can't remember!) the modified u-boot compiled cleanly. I was able to load the new u-boot; but not boot from a USB stick.
Marvell>> setenv ipaddr 192.168.0.111
Marvell>> setenv serverip 192.168.0.252
Marvell>> setenv serverip 192.168.0.121
Marvell>> tftp 0x800000 uboot.mtd0.kwb
Using egiga0 device
TFTP from server 192.168.0.121; our IP address is 192.168.0.111
Filename 'uboot.mtd0.kwb'.
Load address: 0x800000
Loading: #################################################################
######################################
done
Bytes transferred = 524288 (80000 hex)
Marvell>> go 0x800200
## Starting application at 0x00800200 ...
U-Boot 2010.09 (Feb 09 2012 - 12:47:41)
Marvell-Dockstar/Pogoplug by Jeff Doozan
SoC: Kirkwood 88F6281_A0
DRAM: 128 MiB
NAND: 256 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... error in inquiry
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: 1750
UBI: number of bad PEBs: 2
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: 1729
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..
### JFFS2 loading 'uboot-original-mtd0.kwb' to 0x800000
Scanning JFFS2 FS: ........ done.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 09, 2012 10:29PM |
Registered: 13 years ago Posts: 502 |
I've not gone over everything, but peeked at some stuff and here's my impression:
- it may be much easier to port Jeff's changes forward to the new source from git, rather that to try to backport MWalle's L2Cache disable to the 2010.09 source. that would also make it easier in case future updates are needed.
- the 1.1.4 source that is the base for so much Marvell stuff (orion, kirkwood) was heavily patched w/ Marvell's code, so looking at the official denx u-boot code is a breath of fresh air... some of the stuff that Buffalo used was so incredibly bulky ... this is much leaner
- a lot (maybe most) of the important stuff to be patched/altered/considered is in
- a really important thing is for the uboot*.kwb to be loadable and executable as an application... just like he points to in his "how to build..." page. RAM builds are not supported (I guess they never really were...but I used one on the PPC linkstation uboot). It would make it a lot easier to test if we didn't have to keep JTAGging - though I do still have a USB-MINI-ARM setup - its been a while since I used OpenOCD, but I still have my notes.
Unanswered questions (now some are answered):
Does the compiler make a difference?
Answer: Yes. Jeff's source compiled w/ the codesourcery-arm-2009q3 loads and runs fine. The same commands and same source yields a faulty/nonworking uboot, using codesourcery-arm-2011.09.
What is preventing the uboot.kwb's that we build from running (or displaying) as Jeff's and the original one did? Is it a compiler issue? Is this feature no longer supported in newer source? Is it just something that needs to be enabled in the configs?
Is textbase given correctly? http://www.dslreports.com/forum/r24894582-General-Build-your-u-boot-for-Dockstar
Does it actually have to be TEXT_BASE = 0x00c00000 for the test in SDRAM to work?
I'll try it w/ the "helloworld" and other apps to see if they run when invoked w/ the go <address> command, once loaded.
(Answer: It did not execute. I tried it w/ two different toolchains...)
I did a careful manual diff and cross-reference of the include/configs/dockstars : from Jeff's patched source, and from the denx tree. I think I have a good outline of where to begin changes.
=====================================================
Edited 2 time(s). Last edit at 02/10/2012 12:30AM by davygravy.
- it may be much easier to port Jeff's changes forward to the new source from git, rather that to try to backport MWalle's L2Cache disable to the 2010.09 source. that would also make it easier in case future updates are needed.
- the 1.1.4 source that is the base for so much Marvell stuff (orion, kirkwood) was heavily patched w/ Marvell's code, so looking at the official denx u-boot code is a breath of fresh air... some of the stuff that Buffalo used was so incredibly bulky ... this is much leaner
- a lot (maybe most) of the important stuff to be patched/altered/considered is in
- arch/arm/include/asm/arch-kirkwood/config.h
- include/configs/dockstar.h
- a really important thing is for the uboot*.kwb to be loadable and executable as an application... just like he points to in his "how to build..." page. RAM builds are not supported (I guess they never really were...but I used one on the PPC linkstation uboot). It would make it a lot easier to test if we didn't have to keep JTAGging - though I do still have a USB-MINI-ARM setup - its been a while since I used OpenOCD, but I still have my notes.
Unanswered questions (now some are answered):
Does the compiler make a difference?
Answer: Yes. Jeff's source compiled w/ the codesourcery-arm-2009q3 loads and runs fine. The same commands and same source yields a faulty/nonworking uboot, using codesourcery-arm-2011.09.
What is preventing the uboot.kwb's that we build from running (or displaying) as Jeff's and the original one did? Is it a compiler issue? Is this feature no longer supported in newer source? Is it just something that needs to be enabled in the configs?
Is textbase given correctly? http://www.dslreports.com/forum/r24894582-General-Build-your-u-boot-for-Dockstar
Does it actually have to be TEXT_BASE = 0x00c00000 for the test in SDRAM to work?
I'll try it w/ the "helloworld" and other apps to see if they run when invoked w/ the go <address> command, once loaded.
(Answer: It did not execute. I tried it w/ two different toolchains...)
I did a careful manual diff and cross-reference of the include/configs/dockstars : from Jeff's patched source, and from the denx tree. I think I have a good outline of where to begin changes.
=====================================================
- davy's Github Repo's rescue-dg
Edited 2 time(s). Last edit at 02/10/2012 12:30AM by davygravy.
|
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem? February 10, 2012 05:05AM |
When Jeff's u-boot is compiled with codesourcey-arm-2011.09 boards.cfg has to be amended with:
and in mach-dockstar.patch TEXT_BASE = 0x00c00000 for u-boot to compile and load correctly.
The enabling runtime P2V by default u-boot patch has been added to the Marvell u-boot custodian's tree.
I intend to work with codesourcery-arm-2009q3 and the Marvell u-boot custodian's tree.
dockstar arm arm926ejs - Marvell kirkwood
and in mach-dockstar.patch TEXT_BASE = 0x00c00000 for u-boot to compile and load correctly.
The enabling runtime P2V by default u-boot patch has been added to the Marvell u-boot custodian's tree.
I intend to work with codesourcery-arm-2009q3 and the Marvell u-boot custodian's tree.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 10, 2012 07:21AM |
Registered: 13 years ago Posts: 78 |
I've build a custom u-boot.kwb based on u-boot-marvell custodian tree. Cause pogo_e02 is not supported you'll need to apply the patch attached here...
on your prompt, type:
git clone git://git.denx.de/u-boot-marvell.git
download patch attached to the same folder and apply it:
patch -Np1 -i ../pogo_e02.patch
after this type:
make mrproper
make pogo_e02_config
make u-boot.kwb
dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k conv=sync
pick the file u-boot.mtd0.kwb to your running pogo and
flash_erase /dev/mtd0 0 4
nandwrite /dev/mtd0 uboot.mtd0.kwb
.. This works for me without need of JTAG at all. New bootloader works ok, loads from usb, tftp.. and boots kernels 3.2 !! I didn't change enviroment configuration from ecc's dockstar configuration, but changing it seems easy.
If you want to compile a new u-boot for a dockstar it is easier cause dockstars are fully support in u-boot-marvell tree.
In this case you don't need to apply any patches. just:
git clone git://git.denx.de/u-boot-marvell.git
cd u-boot-marvell
make mrproper
make dockstar_config
make u-boot.kwb
dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k conv=sync
This one compiles cleanly, but I haven't a dockstar to test it!
Good luck for all, I provide NO WARRANTY at all!
Edited 2 time(s). Last edit at 02/10/2012 02:14PM by pazos.
on your prompt, type:
git clone git://git.denx.de/u-boot-marvell.git
download patch attached to the same folder and apply it:
patch -Np1 -i ../pogo_e02.patch
after this type:
make mrproper
make pogo_e02_config
make u-boot.kwb
dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k conv=sync
pick the file u-boot.mtd0.kwb to your running pogo and
flash_erase /dev/mtd0 0 4
nandwrite /dev/mtd0 uboot.mtd0.kwb
.. This works for me without need of JTAG at all. New bootloader works ok, loads from usb, tftp.. and boots kernels 3.2 !! I didn't change enviroment configuration from ecc's dockstar configuration, but changing it seems easy.
If you want to compile a new u-boot for a dockstar it is easier cause dockstars are fully support in u-boot-marvell tree.
In this case you don't need to apply any patches. just:
git clone git://git.denx.de/u-boot-marvell.git
cd u-boot-marvell
make mrproper
make dockstar_config
make u-boot.kwb
dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k conv=sync
This one compiles cleanly, but I haven't a dockstar to test it!
Good luck for all, I provide NO WARRANTY at all!
Edited 2 time(s). Last edit at 02/10/2012 02:14PM by pazos.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 10, 2012 04:38PM |
Registered: 13 years ago Posts: 502 |
@ pazos : 3 questions, if you could please answer:
1. which toolchain/crosscompiler are you using?
2. What distro (and which release/version of that distro) are you compiling it under?
3. Did you load your uboot.kwb into SDRAM to test it first?
If so, will you please post your commands here, as several of us are having trouble getting it to run consistenly in SDRAM?
=====================================================
Edited 1 time(s). Last edit at 02/10/2012 04:44PM by davygravy.
1. which toolchain/crosscompiler are you using?
2. What distro (and which release/version of that distro) are you compiling it under?
3. Did you load your uboot.kwb into SDRAM to test it first?
If so, will you please post your commands here, as several of us are having trouble getting it to run consistenly in SDRAM?
=====================================================
- davy's Github Repo's rescue-dg
Edited 1 time(s). Last edit at 02/10/2012 04:44PM by davygravy.
|
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem? February 10, 2012 04:43PM |
pazos Wrote:
-------------------------------------------------------
> I've build a custom u-boot.kwb based on
> u-boot-marvell custodian tree. Cause pogo_e02 is
> not supported you'll need to apply the patch
> attached here...
>
> on your prompt, type:
> git clone git://git.denx.de/u-boot-marvell.git
>
> download patch attached to the same folder and
> apply it:
> patch -Np1 -i ../pogo_e02.patch
>
> after this type:
> make mrproper
> make pogo_e02_config
> make u-boot.kwb
> dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k
> conv=sync
>
> pick the file u-boot.mtd0.kwb to your running pogo
> and
>
> flash_erase /dev/mtd0 0 4
> nandwrite /dev/mtd0 uboot.mtd0.kwb
>
> .. This works for me without need of JTAG at all.
> New bootloader works ok, loads from usb, tftp..
> and boots kernels 3.2 !! I didn't change
> enviroment configuration from ecc's dockstar
> configuration, but changing it seems easy.
>
> If you want to compile a new u-boot for a dockstar
> it is easier cause dockstars are fully support in
> u-boot-marvell tree.
>
> In this case you don't need to apply any patches.
> just:
>
> git clone git://git.denx.de/u-boot-marvell.git
> cd u-boot-marvell
> make mrproper
> make dockstar_config
> make u-boot.kwb
> dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k
> conv=sync
>
> This one compiles cleanly, but I haven't a
> dockstar to test it!
>
> Good luck for all, I provide NO WARRANTY at all!
dockstar_config u-boot form u-boot-marvell.git compiles cleanly, and it loads BUT u-boot stops at the dockstar> - prompt, the equivalent of the ce> or marvell> prompt: it will not boot a kernel from USB.
With Jeff's kernel it is possible to load it into RAM (test it) and boot it. Perhaps. the environment needs to be correctly set for u-boot u-boot-marvell.git.
-------------------------------------------------------
> I've build a custom u-boot.kwb based on
> u-boot-marvell custodian tree. Cause pogo_e02 is
> not supported you'll need to apply the patch
> attached here...
>
> on your prompt, type:
> git clone git://git.denx.de/u-boot-marvell.git
>
> download patch attached to the same folder and
> apply it:
> patch -Np1 -i ../pogo_e02.patch
>
> after this type:
> make mrproper
> make pogo_e02_config
> make u-boot.kwb
> dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k
> conv=sync
>
> pick the file u-boot.mtd0.kwb to your running pogo
> and
>
> flash_erase /dev/mtd0 0 4
> nandwrite /dev/mtd0 uboot.mtd0.kwb
>
> .. This works for me without need of JTAG at all.
> New bootloader works ok, loads from usb, tftp..
> and boots kernels 3.2 !! I didn't change
> enviroment configuration from ecc's dockstar
> configuration, but changing it seems easy.
>
> If you want to compile a new u-boot for a dockstar
> it is easier cause dockstars are fully support in
> u-boot-marvell tree.
>
> In this case you don't need to apply any patches.
> just:
>
> git clone git://git.denx.de/u-boot-marvell.git
> cd u-boot-marvell
> make mrproper
> make dockstar_config
> make u-boot.kwb
> dd if=u-boot.kwb of=uboot.mtd0.kwb bs=512k
> conv=sync
>
> This one compiles cleanly, but I haven't a
> dockstar to test it!
>
> Good luck for all, I provide NO WARRANTY at all!
dockstar_config u-boot form u-boot-marvell.git compiles cleanly, and it loads BUT u-boot stops at the dockstar> - prompt, the equivalent of the ce> or marvell> prompt: it will not boot a kernel from USB.
With Jeff's kernel it is possible to load it into RAM (test it) and boot it. Perhaps. the environment needs to be correctly set for u-boot u-boot-marvell.git.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 10, 2012 05:02PM |
Registered: 13 years ago Posts: 78 |
@davygravy
I use the same toolchain as jeff (2009-q3). I build the image under a x86 atom machine, with ubuntu 10.04 installed. I didn't try to load it to ram.
@mugabe
Did you check your bootcmd ??? It is a needed value for auto-boot.
Testing *.kwb's in ram seems to be unsupported
Did you try it from openocd or writting in nand??
PD: i have a JTAG Interface for my pogo, then I could do some tests, but all seems to work. cause I've not add support for hush scripts in new uboot, old jeff's enviroment did not work for me, but I've checked usb boot writting at u-boot's prompt:
setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=ext2 rootdelay=10'
usb start
ext2load usb 0:1 /boot/uImage 0x600000 # feel free to change it, but it seems to be the new standard #
bootm 0x600000
Edited 2 time(s). Last edit at 02/14/2012 12:51PM by pazos.
I use the same toolchain as jeff (2009-q3). I build the image under a x86 atom machine, with ubuntu 10.04 installed. I didn't try to load it to ram.
@mugabe
Did you check your bootcmd ??? It is a needed value for auto-boot.
Testing *.kwb's in ram seems to be unsupported
Did you try it from openocd or writting in nand??
PD: i have a JTAG Interface for my pogo, then I could do some tests, but all seems to work. cause I've not add support for hush scripts in new uboot, old jeff's enviroment did not work for me, but I've checked usb boot writting at u-boot's prompt:
setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=ext2 rootdelay=10'
usb start
ext2load usb 0:1 /boot/uImage 0x600000 # feel free to change it, but it seems to be the new standard #
bootm 0x600000
Edited 2 time(s). Last edit at 02/14/2012 12:51PM by pazos.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 10, 2012 05:51PM |
Registered: 13 years ago Posts: 502 |
hehehehe... I get it ... "Unsupported" = maybe it will, it used to work all the time in the good old days, maybe not anymore {you may be SOL}. ;)
I'm looking at the header pins, and they seem much smaller than I'm accustomed to... I don't know if the adapter on the end of my ARM-USB-TINY will fit on it... see the adapter ? http://www.olimex.com/dev/arm-usb-tiny.html
@pazos: which version of OpenOCD do you use? I imagine it has developed and changed over the last 3 years since I used it.
=====================================================
I'm looking at the header pins, and they seem much smaller than I'm accustomed to... I don't know if the adapter on the end of my ARM-USB-TINY will fit on it... see the adapter ? http://www.olimex.com/dev/arm-usb-tiny.html
@pazos: which version of OpenOCD do you use? I imagine it has developed and changed over the last 3 years since I used it.
=====================================================
- davy's Github Repo's rescue-dg
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 02:02AM |
Registered: 13 years ago Posts: 502 |
Huzzah! [ got to test this all weekend...]
=====================================================
U-Boot 2011.12-06918-gf33b06f-dirty (Feb 11 2012 - 01:50:51)
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
(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)
1589976 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4989018 bytes read
## Booting kernel from Legacy Image at 00800000 ...
Image Name: Linux-3.2.2
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1589912 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.2.2-kirkwood
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 4988954 Bytes = 4.8 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.2.2-kirkwood (root@bitbaker64) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 Mon Feb 6 22:16:2
[ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: Seagate FreeAgent DockStar
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2 mtdparts=orion_nand:1M(u-boot),4M(uIma)
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 128MB = 128MB total
[ 0.000000] Memory: 120576k/120576k available, 10496k reserved, 0K highmem
...
[ 17.729350] CPU: Testing write buffer coherency: ok
[ 17.731911] print_constraints: dummy:
[ 17.732154] NET: Registered protocol family 16
[ 17.732851] Kirkwood: MV88F6281-A0, TCLK=200000000.
[ 17.732865] Feroceon L2: Enabling L2
[ 17.732901] Feroceon L2: Cache support initialised.
[ 17.735404] bio: create slab <bio-0> at 0
[ 17.735699] vgaarb: loaded
[ 17.736133] Switching to clocksource orion_clocksource
[ 17.745235] NET: Registered protocol family 2
....
[ 18.759262] ONFI flash detected
[ 18.762506] ONFI param page 0 valid
[ 18.766016] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08AAD)
[ 18.773737] Scanning device for bad blocks
[ 18.929894] 4 cmdlinepart partitions found on MTD device orion_nand
[ 18.936199] Creating 4 MTD partitions on "orion_nand":
[ 18.941366] 0x000000000000-0x000000100000 : "u-boot"
[ 18.947015] 0x000000100000-0x000000500000 : "uImage"
[ 18.952534] 0x000000500000-0x000002500000 : "rootfs"
[ 18.958089] 0x000002500000-0x000010000000 : "data"
[ 18.964011] mousedev: PS/2 mouse device common for all mice
[ 19.976181] rtc-mv rtc-mv: internal RTC not ticking
[ 19.981174] i2c /dev entries driver
[ 19.984831] cpuidle: using governor ladder
[ 19.989090] cpuidle: using governor menu
[ 19.994022] TCP cubic registered
[ 19.997288] NET: Registered protocol family 17
[ 20.001761] Registering the dns_resolver key type
................
[ 22.576324] sd 0:0:0:0: [sda] Attached SCSI disk
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
Starting the hotplug events dispatcher: udevd[ 32.683730] udevd[157]: starting version 175
.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...[ 34.573303] Adding 258044k swap on /dev/sda2. Priority:-1 extents:1 across:258044k
done.
Checking root file system...fsck from util-linux 2.20.1
/dev/sda1: clean, 96066/306432 files, 824898/1223704 blocks
done.
Loading kernel modules...done.
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux 2.20.1
done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
Cleaning up ifupdown....
Setting up networking....
Configuring network interfaces...Setting kernel variables ...done.
[ 39.399952] mv643xx_eth_port mv643xx_eth_port.0: eth0: link up, 1000 Mb/s, full duplex, flow control disabled
dhcpcd.sh: interface eth0 has been configured with new IP=192.168.11.187
done.
[ 43.732733] NET: Registered protocol family 10
Cleaning up temporary files....
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Starting internet superserver: inetd.
Starting OpenBSD Secure Shell server: sshd.
Starting Samba daemons: nmbd smbd.
[ 47.248163] ip_tables: (C) 2000-2006 Netfilter Core Team
Debian GNU/Linux wheezy/sid debian ttyS0
debian login:
=====================================================
- davy's Github Repo's rescue-dg
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 07:37AM |
Registered: 13 years ago Posts: 78 |
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 07:51AM |
Registered: 13 years ago Posts: 502 |
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 09:36AM |
Registered: 13 years ago Posts: 502 |
But not totally out of the woods yet...
It will let me install an older kernel package (Debian official, or my own debs that I rolled), pre3.2. But it will not let me do an install with any 3.2.0 or greater package now.
It is odd - some of the initramfs processing stuff seems to fail ... initrd.img-3.2.0-1-kirkwood is not present in /boot.
Right now I'm not sure if this is a problem w/ my own uboot, or if it is a symptom of the depmod/kmod problem that users over at ArchLinuxArm found/see/are-dealing-with in the 3.2 kernel.
=====================================================
root@debian:/# dpkg -i linux-image-3.2.0-1-kirkwood_3.2.4-1_armel.deb (Reading database ... 33904 files and directories currently installed.) Preparing to replace linux-image-3.2.0-1-kirkwood 3.2.4-1 (using linux-image-3.2.0-1-kirkwood_3.2.4-1_armel.deb) ... Examining /etc/kernel/preinst.d/ Unpacking replacement linux-image-3.2.0-1-kirkwood ... Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-1-kirkwood /boot/vmlinuz-3.2.0-1-kirkwood Setting up linux-image-3.2.0-1-kirkwood (3.2.4-1) ... Running depmod. Failed to symbolic-link /boot/initrd.img-3.2.0-1-kirkwood to initrd.img. dpkg: error processing linux-image-3.2.0-1-kirkwood (--install): subprocess installed post-installation script returned error exit status 17 Errors were encountered while processing: linux-image-3.2.0-1-kirkwood
It will let me install an older kernel package (Debian official, or my own debs that I rolled), pre3.2. But it will not let me do an install with any 3.2.0 or greater package now.
It is odd - some of the initramfs processing stuff seems to fail ... initrd.img-3.2.0-1-kirkwood is not present in /boot.
Right now I'm not sure if this is a problem w/ my own uboot, or if it is a symptom of the depmod/kmod problem that users over at ArchLinuxArm found/see/are-dealing-with in the 3.2 kernel.
root@debian:/# ls /boot System.map-3.1.9-kirkwood config-3.2.0-1-kirkwood uInitrd System.map-3.2.0-1-kirkwood initrd.img-3.1.9-kirkwood vmlinuz-3.1.9-kirkwood config-3.1.9-kirkwood uImage vmlinuz-3.2.0-1-kirkwood
=====================================================
- davy's Github Repo's rescue-dg
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 10:05AM |
Registered: 13 years ago Posts: 78 |
I'm not having any problem, I use debian squeeze with a new self-compiled 3.3rc kernel (kernel headers still old).
I've ported both L2_disable.patch & pogoplug_support.patch to the lastest stable u-boot from denx (2011.12). The things seems to work well. It compiles cleanly for both pogo_e02_config & dockstar_config. I'm testing this one on my pink pogo. It is the same of using lastest git repository, except for the name ( U-Boot 2011.12-06918-gf33b06f-dirty vs U-Boot 2011.12). I'm trying right now to add some enviroment changes (hush shell support & jeff usb-scan scripts)
I deleted patches I've provided cause some minor adjustment is needed. Things seems to work OK for both git-lastest & for 2011.12-stable releases, but It is too soon to made public patches near to the work "stable"
Keep on!
Edited 3 time(s). Last edit at 02/11/2012 12:50PM by pazos.
I've ported both L2_disable.patch & pogoplug_support.patch to the lastest stable u-boot from denx (2011.12). The things seems to work well. It compiles cleanly for both pogo_e02_config & dockstar_config. I'm testing this one on my pink pogo. It is the same of using lastest git repository, except for the name ( U-Boot 2011.12-06918-gf33b06f-dirty vs U-Boot 2011.12). I'm trying right now to add some enviroment changes (hush shell support & jeff usb-scan scripts)
I deleted patches I've provided cause some minor adjustment is needed. Things seems to work OK for both git-lastest & for 2011.12-stable releases, but It is too soon to made public patches near to the work "stable"
Keep on!
Edited 3 time(s). Last edit at 02/11/2012 12:50PM by pazos.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 11:44AM |
Registered: 13 years ago Posts: 502 |
Fixed - or ... not sure what it was... but 3.3.0-rc3 boots fine, without any patches/changes to config.
I've got the HUSH, LONGHELP on & they seem to work OK. I'm currently not able to boot into my old original pogoplug (boot_pogoplug or whatever that command is/was) stuff... so I want to look at why that is not going as it should.
====================================
Could it be that I clobbered that spot in ROM?
=====================================================
Edited 2 time(s). Last edit at 02/11/2012 06:30PM by davygravy.
[ 0.000000] Linux version 3.3.0-rc3-kirkwood (davygravy@bitbaker64) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 Sat Feb2
I've got the HUSH, LONGHELP on & they seem to work OK. I'm currently not able to boot into my old original pogoplug (boot_pogoplug or whatever that command is/was) stuff... so I want to look at why that is not going as it should.
====================================
Could it be that I clobbered that spot in ROM?
DockStar> fsload uboot-original-mtd0.kwb ### JFFS2 loading 'uboot-original-mtd0.kwb' to 0x800000 Scanning JFFS2 FS: done. find_inode failed for name=uboot-original-mtd0.kwb load: Failed to find inode ### JFFS2 LOAD ERROR<0> for uboot-original-mtd0.kwb!
=====================================================
- davy's Github Repo's rescue-dg
Edited 2 time(s). Last edit at 02/11/2012 06:30PM by davygravy.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 12:13PM |
Registered: 13 years ago Posts: 78 |
Hey! Congratulations; Good progress!
I have enabled long_help & hush parser too and I have an u-boot 100% compatible with jeff's enviroment except that i can not check for booting original pogo firmware cause I've deleted old pogoplug partitions. I think that jeff uboot stores uboot-mtd0-original in some point at /dev/mtd2 (old pogo firmware). Did you configure mtdids & mtdparts commands???. If you have spare space (in example: mtd3 not used) you can just write this file to it and try it boot it from nand directly
Anyways you can also try load load uboot.mtd0.original from usb to a ram location and try to boot from ram
mw 0x600000 0 1
ext2load usb 0:1 0x600000 /uboot.mtd0.original
go 0x600200
Have fun!
Edited 1 time(s). Last edit at 02/11/2012 12:52PM by pazos.
I have enabled long_help & hush parser too and I have an u-boot 100% compatible with jeff's enviroment except that i can not check for booting original pogo firmware cause I've deleted old pogoplug partitions. I think that jeff uboot stores uboot-mtd0-original in some point at /dev/mtd2 (old pogo firmware). Did you configure mtdids & mtdparts commands???. If you have spare space (in example: mtd3 not used) you can just write this file to it and try it boot it from nand directly
Anyways you can also try load load uboot.mtd0.original from usb to a ram location and try to boot from ram
mw 0x600000 0 1
ext2load usb 0:1 0x600000 /uboot.mtd0.original
go 0x600200
Have fun!
Edited 1 time(s). Last edit at 02/11/2012 12:52PM by pazos.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 11, 2012 11:23PM |
Registered: 13 years ago Posts: 502 |
@ pazos and Mugabe: Did the flash layout change?
I've noticed something very very strange (and disconcerting).
When I'm in the u-boot environment and connected by console, I see one set of uboot environmental variables. (using print)
When I'm logged in via ssh into Debian, I see a different set of env vars. Completely different.
This isn't supposed to be so... From my experimentation, both can be editted. It appears that only the ones visible while in uboot are used for booting (which make sense).
Maybe the setting in fw_env.config needs to be updated.
Or... maybe there is a change that needs to be made to the configuration in dockstar.h ?
===============================================
Jeff's code:
newer code:
Also the kernel shows this:
=====================================================
Edited 2 time(s). Last edit at 02/11/2012 11:57PM by davygravy.
I've noticed something very very strange (and disconcerting).
When I'm in the u-boot environment and connected by console, I see one set of uboot environmental variables. (using print)
When I'm logged in via ssh into Debian, I see a different set of env vars. Completely different.
This isn't supposed to be so... From my experimentation, both can be editted. It appears that only the ones visible while in uboot are used for booting (which make sense).
Maybe the setting in fw_env.config needs to be updated.
Or... maybe there is a change that needs to be made to the configuration in dockstar.h ?
===============================================
Jeff's code:
/* * 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 */
newer code:
/* * 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 0x60000 #define CONFIG_ENV_OFFSET 0x60000 /* env starts here */
Also the kernel shows this:
[ 18.709567] console [ttyS0] enabled [ 18.713806] ONFI flash detected [ 18.717066] ONFI param page 0 valid [ 18.720573] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08AAD) [ 18.728279] Scanning device for bad blocks [ 18.884449] 4 cmdlinepart partitions found on MTD device orion_nand [ 18.890758] Creating 4 MTD partitions on "orion_nand": [ 18.895931] 0x000000000000-0x000000100000 : "u-boot" [ 18.901479] 0x000000100000-0x000000500000 : "uImage" [ 18.907028] 0x000000500000-0x000002500000 : "rootfs" [ 18.912546] 0x000002500000-0x000010000000 : "data"Has this changed?
=====================================================
- davy's Github Repo's rescue-dg
Edited 2 time(s). Last edit at 02/11/2012 11:57PM by davygravy.
|
Robert Mugabe
Re: Newer uBoot as workaround to 3.2 kernel problem? February 12, 2012 08:28AM |
The layout of the MTD partitions has not changed: just update /etc/fw_env.config to the relevant/respective new u-boot values.
Personally, I amended dockstar.h CONFIG_ENV_ADDR and CONFIG_ENV_OFFSET to Jeff's value. Jeff's default uboot.environment can be relocated from uboot: follow the relevant sections and change addresses where necessary. I reloaded uboot.environment in an abortive attempt to dynamically load/boot uboot.mtd0.dockstar.original.kwb.
It would be nice to have a new u-boot which replicates Jeff's original: mainly, being able to dynamically load subsequent builds of u-boot and hence the original pogoplug/dockstar environment; or to be able to boot into the rescue system if desired.
Personally, I amended dockstar.h CONFIG_ENV_ADDR and CONFIG_ENV_OFFSET to Jeff's value. Jeff's default uboot.environment can be relocated from uboot: follow the relevant sections and change addresses where necessary. I reloaded uboot.environment in an abortive attempt to dynamically load/boot uboot.mtd0.dockstar.original.kwb.
It would be nice to have a new u-boot which replicates Jeff's original: mainly, being able to dynamically load subsequent builds of u-boot and hence the original pogoplug/dockstar environment; or to be able to boot into the rescue system if desired.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 12, 2012 10:35AM |
Registered: 13 years ago Posts: 502 |
Well, we never lost it, really. See this : http://forum.doozan.com/read.php?3,1593
=====================================================
=====================================================
- davy's Github Repo's rescue-dg
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 12, 2012 10:56AM |
Registered: 13 years ago Posts: 502 |
Which options in include/configs/dockstar.h are now obsolete ( or deprecated ) ?
So far I found 2:
CONFIG_SYS_MAXARGS (http://lists.denx.de/pipermail/u-boot/2010-March/068428.html)
CONFIG_CMD_AUTOSCRIPT (http://lists.denx.de/pipermail/u-boot/2011-June/093641.html)
What others are there?
=====================================================
Edited 1 time(s). Last edit at 02/12/2012 12:56PM by davygravy.
So far I found 2:
CONFIG_SYS_MAXARGS (http://lists.denx.de/pipermail/u-boot/2010-March/068428.html)
CONFIG_CMD_AUTOSCRIPT (http://lists.denx.de/pipermail/u-boot/2011-June/093641.html)
What others are there?
=====================================================
- davy's Github Repo's rescue-dg
Edited 1 time(s). Last edit at 02/12/2012 12:56PM by davygravy.
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 12, 2012 12:57PM |
Registered: 13 years ago Posts: 78 |
@davygravy: you have two enviroments, please: can you look for diferences into ethaddr parameter value.
My build have enviroment offset in 0xc0000 as jeff's one. I think as Mugabe, it is better to keep the enviroment in the same place as the old one, to be able to use old enviroment without setting it!
I do some things with my pogo_e02
1. reinstall original filesystem (mtd1 & mtd2)
2. reinstall old original CE bootloader
3. reinstall jeff uboot
4. reinstall my self-compiled u-boot
All works, but ethaddr value changed from first one (jeff) to the second one (mine). Jeff u-boot seems to maintain the old value of the original bootloader.
Booting from original pogo firmware does not work yet
My build have enviroment offset in 0xc0000 as jeff's one. I think as Mugabe, it is better to keep the enviroment in the same place as the old one, to be able to use old enviroment without setting it!
I do some things with my pogo_e02
1. reinstall original filesystem (mtd1 & mtd2)
2. reinstall old original CE bootloader
3. reinstall jeff uboot
4. reinstall my self-compiled u-boot
All works, but ethaddr value changed from first one (jeff) to the second one (mine). Jeff u-boot seems to maintain the old value of the original bootloader.
Booting from original pogo firmware does not work yet
|
Re: Newer uBoot as workaround to 3.2 kernel problem? February 12, 2012 01:06PM |
Registered: 13 years ago Posts: 502 |
OK, my current u-boot that I have installed will not only load and run variations of itself, but will also load and execute the original CE uboot that came stock on the Dockstar:
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.
=====================================================
U-Boot 2011.12-06918-gf33b06f-dirty (Feb 12 2012 - 07:50:16) 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>> tftp 0x800000 uboot.mtd0.dockstar.original.kwb Using egiga0 device TFTP from server 192.168.11.149; our IP address is 192.168.11.187 Filename 'uboot.mtd0.dockstar.original.kwb'. Load address: 0x800000 Loading: #################################### done Bytes transferred = 524288 (80000 hex) u-boot>> go 0x800200 ## Starting application at 0x00800200 ... U-Boot 1.1.4 (Jul 16 2009 - 21:02:16) Cloud Engines (3.4.16) U-Boot code: 00600000 -> 0067FFF0 BSS: -> 00690D60 Soc: 88F6281 A0 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 128MB DRAM Total size 128MB 16bit width Flash: 0 kB Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:256 MB CPU : Marvell Feroceon (Rev 1) CLOUD ENGINES BOARD: REDSTONE:1.0 Streaming disabled Write allocate disabled USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 0 CE>> print baudrate=115200 loads_echo=0 ipaddr=169.254.254.253 serverip=169.254.254.254 rootpath=/mnt/ARM_FS/ netmask=255.255.0.0 run_diag=yes console=console=ttyS0,115200 CASset=min MALLOC_len=1 ethprime=egiga0 bootargs_root=root=/dev/mtdblock2 ro ethmtu=1500 usb0Mode=host nandEcc=1bit ethact=egiga0 ethaddr=00:10:75:1A:5B:73 cesvcid=BZT7Y9ERQFT3U2PKZAT7TDK7U6 ceserialno=2GEP0NGE ceboardver=REDSTONE:1.0 bootcmd=nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000 stdin=serial stdout=serial stderr=serial mainlineLinux=no enaMonExt=no enaCpuStream=no enaWrAllo=no pexMode=RC disL2Cache=no setL2CacheWT=yes disL2Prefetch=yes enaICPref=yes enaDCPref=yes sata_dma_mode=yes netbsd_en=no vxworks_en=no bootdelay=3 disaMvPnp=no Environment size: 762/131068 bytes CE>>
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.
=====================================================
- davy's Github Repo's rescue-dg
