Hi
For some time I have the problem to which the solution is described here.
Unfortunately this seems to work on a guruplug and does not work on a
sheevaplug.
With the binaries and config, that had been attached to the last mail, I
tried to set variables from a running linux:
root@sheeva:~# ./fw_printenv ^M
Warning: Bad CRC, using default environment^M
bootcmd=bootp; setenv bootargs root=/dev/nfs
nfsroot=${serverip}:${rootpath} ip=
${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm^M
bootdelay=5^M
baudrate=115200^M
Linking fw_printenv to fw_setenv and setting variables results in:
Warning: Bad CRC, using default environment^M
Even worse: If I reboot the sheevaplug hangs and I have to reinstall uboot
via openocd.
Questions is, how to set the uboot environment on a sheevaplug from a
running system?
Norbert
Mahavir Jain wrote:
Hi
You can use env tools from U-Boot source code(tools/env), fw_printenv
for printing mtd partition with U-Boot environment variables and
fw_setenv for setting environment variables. U-Boot environments for
guruplug are located at offset 0x40000 with size 0x20000.
I have attached fw_setenv binary, config file and log at my end.
Detail steps are,
* Copy fw_env.config to /etc.
* Create soft link to fw_setenv as fw_printenv.
* Execute fw_printenv to see enviroment and fw_setenv to modify.
Hope this helps.
Thanks
Mahavir
On Tue, 2010-05-11 at 13:02 -0700, Jon Hermansen wrote:
> Chris,
> Thanks for clarifying the differences between the shipped SheevaPlug
> and GuruPlug hardware. It looks like Global Scale was sending the
> JTAG/tty breakout box for free with the GuruPlug but only with
> pre-orders, and I didn't make the cut (ordered May 1st or so.)
>
> I misspoke earlier -- I think fw_printenv and fw_setenv are part of
> U-Boot.
>
> I found more detailed information (but no more than I already had) on
> the layout of the GuruPlug's MTD from a patch signed off on by
> Siddarth Gore@marvell.
>
> static struct mtd_partition guruplug_nand_parts[] = {
> {
> .name = "u-boot",
> .offset = 0,
> .size = SZ_1M
> }, {
> .name = "uImage",
> .offset = MTDPART_OFS_NXTBLK,
> .size = SZ_4M
> }, {
> .name = "root",
> .offset = MTDPART_OFS_NXTBLK,
> .size = MTDPART_SIZ_FULL
> },
> };
>
> I have seen others' /proc/mtd file and some different (but very
> similar) hardware has had a completely seperate, fourth partition (in
> between "u-boot" and "uImage") which I presumed was specifically
for
> u-boot configuration. My device seems to not have one. Was there a
> design decision behind this? Is my hardware specifically designed to
> lock me out from changing the U-Boot environment variables without
> that breakout box?
>
> I also realize that I can repartition the MTD, but who knows if that'd
> help at all. I may go with Chris' advice to just flash the u-boot
> partition with some of my modifications (i.e. kernel parameters) and
> see how I fare.
>
> I am working on a few other fronts, namely, building Fedora 13's
> release 2.6.33.3 kernel targeted for my GuruPlug (the same patch set I
> referenced earlier includes a guruplug_defconfig) and getting U-Boot
> built for it too. From what I can tell, all you need is "make
> guruplug" on the latest testing branch from u-boot-marvell.git.
>
> Siddarth, I added you to see if you might be able to help me...
>
> And lastly, I'd like to thank you all for taking time out of your day
> to support the unsupportable :p
>
>
> On Tue, May 11, 2010 at 11:42 AM, Joe McManus <joe(a)inotion.com> wrote:
> Hey Jon - If you do figure it out, please add it to the wiki.
> I am waiting for a JTAG myself, didn't notice the Guruplug did
> not have the serial built in.
>
> Cheers,
> -Joe
>
>
>
>
> On Tue, 11 May 2010, Jon Hermansen wrote:
>
> Itamar,
> I have read over many guides, including the Fedora
> wiki, Ubuntu
> ARM-specific wiki pages,
plugcomputer.org, and a few
> other places but yet
> have not found what I've been looking for. All the
> pages I've read
> specifically refer to accessing U-Boot over serial
> (using the $40 box from
> Global Scale, or I can DIY) from another PC, and I
> can't do this at the
> moment. Specifically, I think the problem boils down
> to knowing specific
> offsets to data on the NAND on my GuruPlug board.
>
> There are existing tools that will supposedly do what
> I want -- flash
> onboard NAND:
> 1. mtd-utils:
http://www.linux-mtd.infradead.org/
> 2. sheeva-uboot-tools:
>
http://code.google.com/p/sheeva-uboot-tools/
>
> I assume that the latter tool relies on the former.
> Now, fw_printenv (part
> of mtd-utils) always throws "bad CRC" at me because I
> haven't figured out
> the correct offsets/sizes yet. I've done a nanddump on
> the partitions of the
> MTD that have the interesting bits on them, namely,
> the u-boot loader and
> the kernel. There is a third partition, that holds the
> rootfs:
>
> [root@guru ~]# cat /proc/mtd
> dev: size erasesize name
> mtd0: 00100000 00020000 "u-boot"
> mtd1: 00400000 00020000 "uImage"
> mtd2: 1fb00000 00020000 "root"
>
>
> I looked at the uImage bit in a hex editor, and found
> nothing interesting or
> configurable, just kernel junk. In the "u-boot"
> partition, I have found bits
> that look like configuration information, but I _do
> not_ want to modify the
> default u-boot options, in fact, I'd rather leave them
> in case I get a JTAG
> cable later or do something to bork my OS. I also
> can't discern where in
> this file lie the custom settings vs. the default
> settings, so I won't
> change any bits here yet...
>
> I have considered another alternative, that is, only
> flashing over the
> uImage and rootfs MTD partitions. This would be fine,
> assuming that the
> shipped version of U-Boot does not limit functionality
> on my system... and I
> think this would allow me to install Fedora 12.
>
> An additional alternative would be to fake passed
> parameters to the kernel,
> i.e. hack the kernel source to default to
> "root=/dev/sda" and thus
> overriding my current /proc/cmdline:
>
> [root@guru ~]# cat /proc/cmdline
> console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs
> rootfstype=ubifs
>
>
> If anyone has any more information, please advise. I
> am considering writing
> to Global Scale / the kernel developers over at
> Marvell to see if they can
> drop me any hints...
>
> On Sun, May 9, 2010 at 9:30 PM, Itamar Reis Peixoto
> <itamar(a)ispbrasil.com.br> wrote:
> On Sun, May 9, 2010 at 3:46 AM, Jon Hermansen
> <jon.hermansen(a)gmail.com> wrote:
> > Hello all,
> > I just got a brand new GuruPlug a few days ago and
> I was hoping to
> install
> > Fedora ARM on it as soon as possible. Well, the only
> problem is, I
> neglected
> > to get the JTAG breakout box / cables required to
> get the U-Boot
> prompt and
> > thus, as far as I can tell, can't do much about
> loading a new U-Boot
> version
> > (hopefully to boot from microSD), putting a new
> U-Boot config, Linux
> kernel
> > and accompanying rootfs on the NAND/external MicroSD
> card. I can see
> the
> > /dev/mtd* devices from Debian 5.0.3, kernel
> 2.6.32-00007-g56678ec,
> but I
> > have yet to write to them from my live system as I
> want to be
> absolutely
> > sure about what I'm doing on this front.
> >
> > I'd also like to know if I can use the internal
> NAND/external
> MicroSD card
> > as one big device, as opposed to two seperate
> devices. I realize the
> NAND is
> > not addressed as a block device, but if they both
> can contain
> filesystems,
> > does that mean that I can use UnionFS (or something
> similiar) to
> bridge two
> > seperate filesystems and divide the space taken up
> by data between
> the two
> > storage devices?
> >
> > If anyone could provide any more information on what
> I'm attempting
> to do
> > (flash NAND, reinstall OS) without a JTAG cable,
> either on a
> SheevaPlug or a
> > GuruPlug (from what I've read, they are nearly the
> same), it would
> be
> > greatly appreciated.
> >
> > Thanks to all of you guys for working out the kinks
> in Fedora ARM,
> and I'm
> > looking forward to using my favorite distro on the
> smallest PC I've
> ever
> > had...
> >
> > Jon Hermansen
> >
> start here ->
>
https://fedoraproject.org/wiki/Architectures/ARM
>
>
> --
> ------------
>
> Itamar Reis Peixoto
>
>
>
>
>
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm