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@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@ispbrasil.com.br> wrote:
On Sun, May 9, 2010 at 3:46 AM, Jon Hermansen
<jon.hermansen@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