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

Tue May 11 20:02:51 UTC 2010

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
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/arm/attachments/20100511/ece7ae78/attachment-0001.html 