Hi Nobert
On Wed, 2010-05-12 at 04:09 -0700, Norbert Wegener wrote:
> 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?
Try changing Device offset to 0x60000 (ENV starts here for sheevaplug)
in fw_env.config file assuming you are using open U-Boot.
Thanks
Mahavir
>
> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> wrote:
> >> On Sun, May 9, 2010 at 3:46 AM, Jon Hermansen
> >> <jon.hermansen@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> > https://admin.fedoraproject.org/mailman/listinfo/arm
>
>
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
