| 11:41 | topi`> | UBOOT gurus here, can somebody explain me why UBOOT first reads uboot.env and then writes to it? |
| 11:41 | topi`> | I want to avoid writes to eMMC |
| 11:42 | Ke> | did you have that boot successful tracking |
| 11:42 | Ke> | not sure, how it's implemented |
| 11:43 | topi`> | this is what's printed inthe serial console: |
| 11:43 | topi`> | reading uboot.env | auto-detected panel HDMI | Display: HDMI (1024x768) | In: serial | Out: serial | Err: serial | writing uboot.env |
| 11:43 | topi`> | (I changed linefeeds to bars, not to annoy the gods of IRC) |
| 11:43 | topi`> | if the CRC would be wrong, you'd expect it to complain about it, right? |
| 11:43 | topi`> | but it still writes uboot.env (to a FAT partition) |
| 11:44 | Ke> | I believe I have seen uboot complain about broken env and using the defaults |
| 11:44 | topi`> | yeah let's modify some VAR and see if it gets reset to a default value... |
| 11:45 | topi`> | I wasn't able to compile a working env-tool from uboot src repo, so I wrote my own tool in python |
| 11:45 | topi`> | it just reads the null-terminated env vars, deserializes them to a python dict, which can then be serialized back to disk w/ crc32 |