08:47 <ykhan_> Hello all. I am trying to boot rockchip linux v3.10.104 on a custom rk3288 based board. The rootfs is on eMMC and parition format is GPT. I am unable to load the rootfs. I have tried passing the mtdparts=rk29xxnand:<partition-info> in the kernel command line and can see various mmcblkp* partition files getting created in the kernel boot log but the kernel fails to detect the rootfs and crashes at unable to mount root failure.

08:49 <EmilKarlson> if the exact error is rootfs, then you'll need to enable appropriate filesystem support

08:50 <EmilKarlson> people here mostly favour more upstreamish kernels

08:57 <inode> ykhan_: put the kernel messages in a paste bin so we can all see what you're seeing

08:57 <ykhan_> Thank you, the filesystem support is enabled. I will pastebin the log.

09:40 <ykhan_> Here's the pastebin. Now I am loading the rootfs from the ext4 formatted SD card successfully. But I am still unable to mount GPT formatted eMMC partitions using mount utility. This indicates that there is some problem with how these partitions are being created by passing the mtdparts=rk29xxnand: command line parameter. The pastebin contains logs of both SD and eMMC partitions.

09:42 <ykhan_> https://pastebin.com/4MGY7Sk5

09:44 <EmilKarlson> your log is truncated at the end, I believe=

09:47 <EmilKarlson> you seem to be having 5 partitions 1-5, and you are mounting partition 7?

09:54 <ykhan_> You are right, sorry my bad. I have tried a different kernel command line and it is passing two extra partitions reserved1 and reserved2. I don't think it should be causing the problem as the offset and size of the rootfs would stay the same. But still, let me send the pastebin of original command line..

09:54 <inode> i think you have a mismatch between the "mtdparts=rk29xxnand:..." definition and the GPT you've defined on mmcblk0

09:55 <inode> i haven't looked at rockchip-flavoured 3.x sources, but i gathered from looking at 4.x sources that the rk partitions were added purely on what "mtdparts=rk29xxnand:..." had defined on the command line

09:56 <inode> and ignored the GPT entirely

09:57 <inode> so if you have 7 partitions declared,, you'd get 7 partitions recognized (line 721) and a device nodes created for each (lines 1125 - 1135)

10:00 <inode> iirc, there was also something about the "mtdparts=rk29xxnand:..." definitions having a 0x2000 offset due to LBA

10:02 <inode> something like, the command line says u-boot partition is at 0x2000 but it's actually at offset 0x4000

10:24 <ykhan_> inode: I think you are pointing in the right direction. I also feel this has something related to mtdparts=rk29xxnand option. Nevertheless, here is the correct command line that matches the GPT table but still not working. https://pastebin.com/B4y9D90i

10:27 <inode> ykhan_: i'd try declaring the mtdparts=rk29xxnand:... offsets as 0x2000 less than what you've declared them as in your gpt

10:29 <ykhan_> inode: I know there is an offset of 0x2000 while writing to flash in loader mode vs maskrom mode. I always flash in the maskrom mode so I assume the offsets must be correct. But still worth a shot, thanks for the suggestion

10:30 <inode> a possible means to confirm this suspicion would be to read a chunk of data from the mmc device node (ie. mmcblk0) from the offset you've defined in your gpt

10:30 <inode> and then verify if the chunk in fact begins with a valid partition header

10:31 <ykhan_> inode: In fact, mount with specifying offset on the root mmc node works so that means the offsets must be correct. Let me show you.

10:35 <ykhan_> inode: https://pastebin.com/Kc9vNcXL

10:36 <inode> ykhan_: ok

10:40 <inode> if you got a panic and your root= parameter value was sane, have you tried including rootwait on the kernel command line?

10:42 <ykhan_> inode: No I haven't tried that option. Will give it a go.

10:46 <ykhan_> inode: I was also wondering if there is any proper way of verifying the content of partition device files (/dev/mmcblk0p5) to see if it points to the correct sectors on the block device. If rootwait doesn't work, I might try creating a test binary based on libblkid to verify the filesystem contents. Any better suggestion is highly welcome.

10:50 <inode> ykhan_: you could look at the PHY-SEC and LOG-SEC values listed for each partition with lsblk -O if that helps

10:52 <inode> sorry ignore those columns, they are sizes not offsets

10:58 <inode> i guess another crude option might be to compare something like dd if=/dev/mmcblk0 of=x bs=512 count=8 skip=${PART_OFFSET} vs dd if=/dev/mmcblk0p${PART_NUM} of=y bs=512 count=8

11:00 <inode> does hash(x) == hash(y) ?

11:00 <inode> *shrug*

11:08 <ykhan_> inode: Great idea, I was not sure if the partition device points directly to the root node plus partition offset. Thank you, I will try this.