[fedora-arm] Flash GuruPlug NAND without JTAG cable?

Mahavir Jain mjain at marvell.com
Wed May 12 11:13:15 UTC 2010


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 at 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 at 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 at 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 at 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 at 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 at ispbrasil.com.br> wrote:
> >>                 On Sun, May 9, 2010 at 3:46 AM, Jon Hermansen
> >>                 <jon.hermansen at 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 at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/arm
> 
> 



More information about the arm mailing list