From: Ian Campbell <hidden> Date: 2012-08-09 07:47:57
Hi all,
I've been using "fw_printenv" and "fw_setenv" from the u-boot-tools
package on my DreamPlug which work fine with this /etc/fw_env.config:
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
# MTD device name Device offset Env. size Flash sector size
/dev/mtd1 0x00000000 0x00001000 0x00001000
This corresponds roughly, but not exactly, with:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00001000 "u-boot"
mtd1: 00010000 00001000 "u-boot env"
mtd2: 00010000 00001000 "dtb"
But notice how "Env. size" and mtd1's size don't match -- if I use
0x10000 in fw_env.cfg then the tools don't work (checksums don't match).
This map appears to be hardcoded in u-boot & the kernel, u-boot has:
#define CONFIG_ENV_SECT_SIZE 0x10000 /* 64k */
#define CONFIG_ENV_SIZE 0x1000 /* 4k */
#define CONFIG_ENV_ADDR 0x100000
#define CONFIG_ENV_OFFSET 0x100000 /* env starts here */
(this is upstream u-boot, I've not checked the one shipped by the
factory)
The kernel has:
struct mtd_partition dreamplug_partitions[] = {
{
.name = "u-boot",
.size = SZ_512K,
.offset = 0,
},
{
.name = "u-boot env",
.size = SZ_64K,
.offset = SZ_512K + SZ_512K,
},
{
.name = "dtb",
.size = SZ_64K,
.offset = SZ_512K + SZ_512K + SZ_512K,
},
};
However u-boot has a comment next to CONFIG_ENV_SIZE about rounding the
size to a sector which "sf probe" under u-boot reports as being 64K
(consistent with CONFIG_ENV_SECT_SIZE). However /proc/mtd reports it as
4K. So I'm totally confused about who is wrong, other than the fact that
using the u-boot numbers in /etc/fw_env.config works...
Even then I'm not sure what the rest of the layout should look like. The
kernel's partitioning scheme seems to leave an awful lot of holes and
the dtb partition seems to be entirely a kernel thing.
I'd be happy to make a patch, I just have no idea what I would write in
it ;-)
Cheers,
Ian.
--
Ian Campbell
When some people discover the truth, they just can't understand why
everybody isn't eager to hear it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120809/d6f1314d/attachment-0001.sig>
From: Jason Cooper <hidden> Date: 2012-08-16 14:20:05
On Thu, Aug 09, 2012 at 08:47:57AM +0100, Ian Campbell wrote:
Hi all,
I've been using "fw_printenv" and "fw_setenv" from the u-boot-tools
package on my DreamPlug which work fine with this /etc/fw_env.config:
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
# MTD device name Device offset Env. size Flash sector size
/dev/mtd1 0x00000000 0x00001000 0x00001000
This corresponds roughly, but not exactly, with:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00001000 "u-boot"
mtd1: 00010000 00001000 "u-boot env"
mtd2: 00010000 00001000 "dtb"
But notice how "Env. size" and mtd1's size don't match -- if I use
0x10000 in fw_env.cfg then the tools don't work (checksums don't match).
I've always seen the u-boot environment set to 4k. The kernel
partitions came out of my head. When I added support for the dreamplug
to u-boot, I found out there was a bug in the factory supplied u-boot
which only allowed it to see the first 1MB of the 2MB flash. Also, the
factory supplied kernel didn't even have support for the flash.
So, I fixed u-boot, and figured the extra 1MB was too small for a
kernel, wasn't used by anybody else, and imho, the factory location of
the environment didn't leave much room for new u-boots.
I decided to move the environment and make a place for the dtb. As I
didn't want to constrain either one, I split the extra space between the
two.
Was that the best decision? Well, no one yelled at me and I was new to
the whole process, so that's how it went down.
As it is right now, if you configure your own u-boot to have, say
0x10000 bytes for the environment, you don't need to change your kernel
to support it. Just set the size and write it.
I'm open to suggestions and patches...
hth,
Jason.
From: Ian Campbell <hidden> Date: 2012-08-21 16:28:25
On Thu, 2012-08-16 at 10:20 -0400, Jason Cooper wrote:
On Thu, Aug 09, 2012 at 08:47:57AM +0100, Ian Campbell wrote:
quoted
Hi all,
I've been using "fw_printenv" and "fw_setenv" from the u-boot-tools
package on my DreamPlug which work fine with this /etc/fw_env.config:
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
# MTD device name Device offset Env. size Flash sector size
/dev/mtd1 0x00000000 0x00001000 0x00001000
This corresponds roughly, but not exactly, with:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00001000 "u-boot"
mtd1: 00010000 00001000 "u-boot env"
mtd2: 00010000 00001000 "dtb"
But notice how "Env. size" and mtd1's size don't match -- if I use
0x10000 in fw_env.cfg then the tools don't work (checksums don't match).
I've always seen the u-boot environment set to 4k.
Right, so it seems like that is the right size for the kernel to report
then?
The kernel
partitions came out of my head. When I added support for the dreamplug
to u-boot, I found out there was a bug in the factory supplied u-boot
which only allowed it to see the first 1MB of the 2MB flash. Also, the
factory supplied kernel didn't even have support for the flash.
So, I fixed u-boot, and figured the extra 1MB was too small for a
kernel, wasn't used by anybody else, and imho, the factory location of
the environment didn't leave much room for new u-boots.
I decided to move the environment and make a place for the dtb. As I
didn't want to constrain either one, I split the extra space between the
two.
Was that the best decision? Well, no one yelled at me and I was new to
the whole process, so that's how it went down.
;-)
I'm not saying the partitioning scheme is wrong or trying to criticize,
I just noticed that upstream u-boot and the kernel are inconsistent.
I haven't looked at the factory u-boot, I wouldn't be too torn up if it
matched neither of the other two though.
As it is right now, if you configure your own u-boot to have, say
0x10000 bytes for the environment, you don't need to change your kernel
to support it. Just set the size and write it.
I'm open to suggestions and patches...
I think upstream u-boot and the kernel should match, but I'm not really
sure which one should be changed to match the other.
At this point I suppose it is generally easier for people to change
their kernel so that should be the one to change?
Ian.
--
Ian Campbell
Current Noise: Crowbar - Counting Daze
* gb notes that fdisk thinks his cdrom can store one terabyte
-- Seen on #Linux
From: Jason Cooper <hidden> Date: 2012-08-28 15:30:50
On Tue, Aug 21, 2012 at 05:28:25PM +0100, Ian Campbell wrote:
On Thu, 2012-08-16 at 10:20 -0400, Jason Cooper wrote:
quoted
On Thu, Aug 09, 2012 at 08:47:57AM +0100, Ian Campbell wrote:
quoted
Hi all,
I've been using "fw_printenv" and "fw_setenv" from the u-boot-tools
package on my DreamPlug which work fine with this /etc/fw_env.config:
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
# MTD device name Device offset Env. size Flash sector size
/dev/mtd1 0x00000000 0x00001000 0x00001000
This corresponds roughly, but not exactly, with:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00001000 "u-boot"
mtd1: 00010000 00001000 "u-boot env"
mtd2: 00010000 00001000 "dtb"
But notice how "Env. size" and mtd1's size don't match -- if I use
0x10000 in fw_env.cfg then the tools don't work (checksums don't match).
I've always seen the u-boot environment set to 4k.
Right, so it seems like that is the right size for the kernel to report
then?
quoted
The kernel
partitions came out of my head. When I added support for the dreamplug
to u-boot, I found out there was a bug in the factory supplied u-boot
which only allowed it to see the first 1MB of the 2MB flash. Also, the
factory supplied kernel didn't even have support for the flash.
So, I fixed u-boot, and figured the extra 1MB was too small for a
kernel, wasn't used by anybody else, and imho, the factory location of
the environment didn't leave much room for new u-boots.
I decided to move the environment and make a place for the dtb. As I
didn't want to constrain either one, I split the extra space between the
two.
Was that the best decision? Well, no one yelled at me and I was new to
the whole process, so that's how it went down.
;-)
I'm not saying the partitioning scheme is wrong or trying to criticize,
I just noticed that upstream u-boot and the kernel are inconsistent.
I haven't looked at the factory u-boot, I wouldn't be too torn up if it
matched neither of the other two though.
quoted
As it is right now, if you configure your own u-boot to have, say
0x10000 bytes for the environment, you don't need to change your kernel
to support it. Just set the size and write it.
I'm open to suggestions and patches...
I think upstream u-boot and the kernel should match, but I'm not really
sure which one should be changed to match the other.
At this point I suppose it is generally easier for people to change
their kernel so that should be the one to change?
Before we go changing anything, what is the maximum size a uboot
environment or a dtb can be? Until we can nail that down, I'm inclined
to leave the partitions at their current locations and only adjust the
size of the environment down to 4k in the kernel.
This way, a user foolishly attempting to write more than 4k will get an
error.
If a user changes out their uboot to get a larger environment, they can
adjust the dts as well. No kernel rebuilding necessary.
thx,
Jason.
From: Ian Campbell <hidden> Date: 2012-08-29 09:04:13
(lets add the u-boot list, like I should have done in the first place.
For u-boot@ folks the thread starts at
http://www.spinics.net/lists/arm-kernel/msg188462.html and concerns the
discrepancy between the size of u-boot's environment defined by u-boot
and the kernel)
On Tue, 2012-08-28 at 11:30 -0400, Jason Cooper wrote:
Before we go changing anything, what is the maximum size a uboot
environment
grepping for CONFIG_ENV_SIZE in the u-boot source shows examples of
basically every conceivable size. The biggest I could see was 256K. That
seems pretty huge compared to the sorts of things stored in here though
(I expect it happens to be the underlying sector size)
BTW, I see that in u-boot CONFIG_ENV_SECT_SIZE is 64K while
CONFIG_ENV_SIZE is only 4K. Looking at README this would be discouraged
(it's intended to be used to allow u-boot and the env to share a sector,
which is dangerous) but the layout we use doesn't actually overlap
anything.
I've not had much luck googling for the spec of the actual SPI part in
the dreamplug and my one is at home so I can't look for part numbers.
or a dtb can be?
Single digit numbers of K seems to be the norm (at least for vexpress
platforms). Allowing for a pretty huge factor for expansion even just 4K
would be enormous (although that strikes me as the sort of statement
which comes back to haunt people ;-)).
Until we can nail that down, I'm inclined
to leave the partitions at their current locations and only adjust the
size of the environment down to 4k in the kernel.
That sounds sensible.
This way, a user foolishly attempting to write more than 4k will get an
error.
If a user changes out their uboot to get a larger environment, they can
adjust the dts as well. No kernel rebuilding necessary.
I hadn't spotted that this was in DTS now (although I should have
guessed). Either way this sounds reasonable to me.
Ian.
--
Ian Campbell
How sharper than a hound's tooth it is to have a thankless serpent.