Fw_setenv MTD Erase Error

For Developers
21

It would be nice to avoid splitting that extra partition off, and use the "offset" parameter ... But it doesn't work as you can see in this topic. :sob:

22

Sorry, catching back up :laughing:. On the padding - that's really only for the kernel and/or rootfs, right? Not about this partition at least, that's what I mean.

FYI, if I use any value except 0x1000 for the second parameter, then,

Warning: Bad CRC, using default environment

CRC is OK with 0x1000, so this really seems to be the correct length, agreed? But even with a 4k BLOCKSIZE, I still see,

MTD erase error on /dev/mtd2: Invalid argument
Error: can't write fw_env to flash

What's odd is that it's "invalid argument". Hmmm.

Thanks!

23

when you use printenv from u-boot console it gives you info at the end

have you done this?

24

Yep! I see this - believe this is what you're after, right?

Environment size: 172/4092 bytes

FYI, there is nothing in that partition initially, until a saveenv from U-Boot. Even then, the values are a bit bogus (e.g. MAC is incorrect / bogus).

25

I'm officially out of ideas :man_shrugging:

maybe you can backport this to the stable branch?
if you are using OKLI this is a bad idea though, the parser is not there, a lot more work....

26

NP, appreciate the thoughts! Thinking this isn't a showstopper, not a real big item - just note it for now, agreed?

Thanks!

27

OK, this device is very close - got the LED's working, button, just two minor things (mac address, Wi-Fi start on boot). Discuss them here, or open a new thread? Whatever you prefer!

Thanks.

28

it should be new thread

"Adding support for ...."

BTW, when you make your PR you should ask Adrian about this erase error thing

29

To throw in a few ideas here:
4K erase sectors device wide is a kernel config option, which needs to be set and compiled: MTD_SPI_NOR_USE_4K_SECTORS
When set, you will see all partitions in /proc/mtd have the 0x1000 erasesize.

If fw_setenv works with 4K erase sectors: fw_setenv may be having issues with the fake erasesize (partition size) generated by Openwrt's partial eraseblock patch. If a 0x1000 length erase is called with the faked 0xf000 erasesize, an -EINVAL will be generated here in spi-nor.c.

fw_setenv has some extra printed messages when compiled with DEBUG.
It is the SPI NOR erase that is failing:

if (ioctl(fd, MEMERASE, &erase) != 0) {
	fprintf(stderr,
		"MTD erase error on %s: %s\n",
		DEVNAME(dev), strerror(errno));
	return -1;
}

You could also print the u32s erase.start and erase.length before this to check.

2 Likes
30

ramips target supports 4k erasesize already

31

So nothing to try here it seems? Thanks!

32

OK, one other question - I can start a new thread if you'd rather, just say so!

Have almost everything working now ... buttons, LED's, etc. But wmac has me pulling my hair out! If I use ralink,mtd-eeprom = <&factory 0x0>; - well, then wireless doesn't even come up (factory reset, no wlan!). mediatek instead of ralink has no impact. But if I just go with status = "okay"; for the wmac ... then I see in the kernel log

mt76_wmac 10300000.wmac: Invalid MAC address, using random address 16:bc:41:f2:f2:2a

Which makes sense, but then wlan is present (and with that random mac). Huh? I did check,

. /lib/functions/system.sh
mtd_get_mac_binary u-boot-env 0x4

And this does get me a valid (and correct) mac address. But then no wlan, it's not happy. Have you seen this oddity before? I could just leave it to generate a random mac, but thinking that's not really "right".

Thanks!

33

do you mean this? usually u-boot-env is not read in binary mode
mtd_get_mac_binary factory 0x4

either way....it looks like the eeprom data is actually in the eeprom, not on flash?
so instead of ralink,mtd-eeprom
you need to just set the mac address alone

34

Never mind :laughing:. Seems you can't use ralink,mtd-eeprom with the mt7628. Changed wmac also to mtd-mac-address, and all is good. Wi-Fi working, also USB. I think I can get the PR ready now :grinning_face_with_smiling_eyes:.

Thanks!

1 Like
35

Please, do show me how?

This device is using 64k erasesize:

Openwrt generic config

target/linux/generic/config-5.4:# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set

ramips target does not have a kernel config.
Some of the subtargets set it, some do not:

grep -r CONFIG_MTD_SPI_NOR_USE_4K_SECTORS= target/linux/ramips/
target/linux/ramips/rt305x/config-5.4:CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
target/linux/ramips/rt3883/config-5.4:CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
target/linux/ramips/mt7620/config-5.4:CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
2 Likes
36

Ah ok my bad. I thought all the ramips subtargets had it...

37

I can try it, confirm that fixes the issue ... but handle that as a separate PR, as it's broader than this single device. Agreed?

Thanks!

38

it can be same PR, different commit

39

Checked, it works!

But this hits other devices as well, right? Just wondering if I want to include that in the fray ... LOL!

1 Like
40

OK, have at it :stuck_out_tongue_winking_eye:. Holding the change for 4 kB sectors yet, just until this one is clean. You know my fun with commits ... LOL!

Comments?

Thanks!