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@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
