ramips: Fix root volume for tplink-er605-v2 #11715
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mar-kolya
force-pushed
the
tp-link-er605-v2-fix-root-volume
branch
from
83a4c61 to
25121e9
Compare
DragonBluep
reviewed
Jan 7, 2023
| bootargs = "console=ttyS0,115200 noinitrd"; | ||
| // Override bootargs because u-boot passes wrong root parameter. | ||
| // Instead allow kernel determine root automatically by looking for rootfs volume | ||
| bootargs-override = "console=ttyS0,115200 noinitrd ubi.mtd=3,2048"; |
There was a problem hiding this comment.
Please also keep bootargs to override the default value in the mt7621.dtsi. 6361a95
bootargs-override = "console=ttyS0,115200 noinitrd ubi.mtd=3,2048";
Although this will not pass to the kernel, it can make the device tree more robust.
mar-kolya
force-pushed
the
tp-link-er605-v2-fix-root-volume
branch
from
25121e9 to
3b227da
Compare
mar-kolya
changed the title
|
@DragonBluep just a kind ping on this. Anything else that is missing here? |
hauke
reviewed
Jan 14, 2023
| @@ -12,6 +12,9 @@ | |||
|
|
|||
| chosen { | |||
| bootargs = "console=ttyS0,115200 noinitrd"; | |||
| // Override bootargs because u-boot passes wrong root parameter. | |||
| // Instead allow kernel determine root automatically by looking for rootfs volume | |||
| bootargs-override = "console=ttyS0,115200 noinitrd ubi.mtd=3,2048"; | |||
There was a problem hiding this comment.
What does the 2048 in ubi.mtd=3,2048" do?
Sorry I am not very familiar with this part of the kernel.
There was a problem hiding this comment.
Stock FW has this, as well as u-boot.
I think this the ubi header offset on the device. http://www.linux-mtd.infradead.org/faq/ubi.html has some information on this.
This device has two sets of volumes: main ones (`kernel`, `rootfs`, etc) and
'backup' (`kernel.b`, `rootfs.b`, etc). Bootloader tries to determine which set of
volumes to use by looking at contens of `extra-para` and `extra-para.b` volumes.
These volumes contain JSON that looks like this:
```
{
"dbootFlag": "1",
"integerFlag": "1",
"fwFlag": "GOOD",
"score":1
}
```
It looks like the bootloader looks for `"fwFlag": "GOOD"` (as opposed to `BAD`)
then it compares `score` field - whichever 'good' volume has bigger score wins.
This determines which set of volumes to use to boot.
So for example if `extra-para` is good and has bigger score then `kernel`,
`rootfs`, etc volumes are used. This means bootloader needs to explain to the
kernel which volume to use for the rootfs. After looking at bootloader code with
disassembler I think it contains a bug. Relevant part of code looks something
like this:
```
if (image_id == 0) {
rootfs_volume_id = 8;
rootfs_volume_name = "rootfs";
}
else {
rootfs_volume_id = 0xf;
rootfs_volume_name = "rootfs.b";
}
sprintf(
&buffer,
0x800,
"console=ttyS0,115200 noinitrd ubi.mtd=3,2048 ubi.block=0,%s
root=/dev/ubiblock0_%d DKMGT_IMAGE_ID=%d DKMGT_IMAGE_TYPE=ubi",
rootfs_volume_name,
rootfs_volume_id,
image_id
);
```
Where `image_id == 0` if 'normal' (not '*.b' set of volumes is used).
However from device dumps we know that from the factory `rootfs.b` has id 8 and
`rootfs` has id 15.
So from above we can see that ids and names of rootfs volumes do not match. More
over - they are hardcoded in the bootloader.
Both things are problematic for OpwnWRT which completely removes volumes on
update meaning that volume ids may actually change.
So instead of relying on bootloader to provide the kernel with root device this
patch forces kernel to determine root automatically - and it defaults to
`rootfs` volume which is correct for our purposes.
Overall this makes image boot fine from flash after sysupgrade from inirams.
assuming `extra-para*` volumes make bootloader use non-'*.b' set of volumes.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
hauke
force-pushed
the
tp-link-er605-v2-fix-root-volume
branch
from
3b227da to
62dbcb8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This device has two sets of volumes: main ones (
kernel,rootfs, etc) and 'backup' (kernel.b,rootfs.b, etc). Bootloader tries to determine which set of volumes to use by looking at contens ofextra-paraandextra-para.bvolumes. These volumes contain JSON that looks like this:It looks like the bootloader looks for
"fwFlag": "GOOD"(as opposed toBAD) then it comparesscorefield - whichever 'good' volume has bigger score wins. This determines which set of volumes to use to boot.So for example if
extra-parais good and has bigger score thenkernel,rootfs, etc volumes are used. This means bootloader needs to explain to the kernel which volume to use for the rootfs. After looking at bootloader code with disassembler I think it contains a bug. Relevant part of code looks something like this:Where
image_id == 0if 'normal' (not '*.b' set of volumes is used). However from device dumps we know that from the factoryrootfs.bhas id 8 androotfshas id 15.So from above we can see that ids and names of rootfs volumes do not match. More over - they are hardcoded in the bootloader.
Both things are problematic for OpwnWRT which completely removes volumes on update meaning that volume ids may actually change.
So instead of relying on bootloader to provide the kernel with root device this patch forces kernel to determine root automatically - and it defaults to
rootfsvolume which is correct for our purposes.Overall this makes image boot fine from flash after sysupgrade from inirams. assuming
extra-para*volumes make bootloader use non-'*.b' set of volumes.Signed-off-by: Nikolay Martynov mar.kolya@gmail.com