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
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, 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
On Tue, May 11, 2010 at 11:19 AM, Jon Hermansen jon.hermansen@gmail.com 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
you can access it using sheeva USB cable and gtkterm for example.
On Tue, 2010-05-11 at 11:22 -0300, Itamar Reis Peixoto wrote:
On Tue, May 11, 2010 at 11:19 AM, Jon Hermansen jon.hermansen@gmail.com wrote:
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...
You can do a complete reflash via jtag later if need be, so I wouldn't go out of the way to avoid changing the boot parameters if you need to do that.
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...
Some of the Marvell folks hang out in #fedora-devel, if you catch them at the right time.
you can access it using sheeva USB cable and gtkterm for example.
No, the guruplug doesn't have the built-in console that the sheevaplug has -- the USB<->(console+jtag) circuit is in the external JTag box. That makes sense for production units customized for a specific app, but the sheeva configuration is better for experimental/development purposes.
-Chris
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:
- mtd-utils: http://www.linux-mtd.infradead.org/
- 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=ubifsIf 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
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@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:
- mtd-utils: http://www.linux-mtd.infradead.org/
- 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=ubifsIf 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
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@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
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@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
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
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@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
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Hi Mahavir I changed the settings accordingly to:
# MTD device name Device offset Env. size Flash sector size Number of sectors
# NAND example /dev/mtd0 0x60000 0x20000 0x20000 1
Nevertheless the Bad CRC stays with fw_printenv:
uncorrectable error : Warning: Bad CRC, using default environment bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm bootdelay=5 baudrate=115200
root@sheeva:~# ./fw_setenv x_bootargs_root 'root=/dev/sda1 rootwait'^M Warning: Bad CRC, using default environment^M root@sheeva:~# exit^ reboot again does not work and again uboot has to be reinstalled. Regards Norbert
Mahavir Jain wrote:
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
-
Chris Tyler -
itamar -
Joe McManus -
Jon Hermansen -
Mahavir Jain -
Norbert Wegener