Am 11.08.2016 um 13:49 schrieb Daniel Golle:

Hi!

On Thu, Aug 11, 2016 at 04:28:47AM -0700, J Mo wrote:

...

I got that good old feeling... like I just jumped onto a bag of flaming poo. Ha ha

On 08/11/2016 03:40 AM, Daniel Golle wrote:

...

Understandable. However, we also need to experiment and figure out the mess left behind by $vendor which often doesn't leave a lot of reasonable options for 3rd-party firmware to be installed. With regard to that specific hack, I never truly understood why it was needed in first place -- I'm not using it on any UBI-enabled device and believe it's some kind of work-around to allow ubinized images to be written via nandwrite, initially in order to support the vendor/stock sysupgrade-format of a specific device (NETGEAR WNDR4300). Please correct me or add the missing bits needed to understand the use-case. It was added to OpenWrt long ago in r38681...r38683 and by now needed to be fixed several times in r42940, r43287, r44658, r44801 and r44881. Later on it was re-used by a bunch of other devices, e.g. bcm4708-netgear-r6250, bcm4708-netgear-r6300-v2, bcm4708-buffalo-wzr-1750dhp, bcm47081-buffalo-wzr-600dhp2 and probably some more.

Gabor and Rafal should know more about it and why exactly this is needed and supposedly cannot be solved without this hack.

I'm also confused about WTF that patch does. If it was device-specific to comply with OEM-hackery, why apply it generally?

I reckon because it's generic in the sense that it's used by more than one target (ar71xx, bcm47xx) and we don't do any device/board specific patching at all.

...

Hm, I just found another example. I don't know why this didn't turn up in my searches yesterday since it's a perfect match with the EXACT error. This too was on a QSDK AP148:

https://patchwork.ozlabs.org/patch/509468/

I think I'll go rip that patch out here in a bit, recompile my image, and see what happens.

In the end, this will at least give you some consistency in terms of U-Boot's and the Kernel's UBI implementation. Ie. either both work or both fail (e.g. to attach a not entirely erased/formatted UBI device with left-overs from previous uses of the stock fw). In case you are flashing the firmware using ubiformat, this shouldn't be a problem anyway.

...

...

[...]

Thanks for the insight.

The idea was to have a UBI with three volumes: kernel, rootfs(squashfs), and the rootfs_data overlay(ubifs).

One of my problems is that someone thought it was a great idea to name the SMEM NAND UBI partition "rootfs". There's a patch out there which is supposed to fix that, (rename to "ubi") but it's apparently not working for me. The auto rootfs selection method might be trying to use the smem/mtd parition named "rootfs" instead of the UBI volume named "rootfs"?

No, these are two different things and it shouldn't matter. However, in order to have your UBI device auto-attached without any cmdline parameters it needs to be named 'ubi', so simply changing the name of the MTD partition in the device-tree should do the trick.

...

And yes, my DTS has: bootargs = "console=ttyMSM0,115200n8 ubi.mtd=11 root=ubi0:rootfs rootfstype=squashfs";

Is that not valid? Looks right to me.

squashfs doesn't work on UBI character devices but rather likes block devices only, just like most filesystems. Thus, rootfs detection works automagically in OpenWrt/LEDE, just having a ubi volume named 'rootfs' should do the trick and automatically decide whether the volume is UBIFS and thus would be mounted similar to what you tried to do now -- or to create a ubiblock-device and select that to be mounted as rootfs. In any case, you shouldn't need any kernel command-line parameters for that, so simply drop everything past 'console=ttyMSM0,115200n8' (and btw, this can also be done nicer by setting stdout-path rather than hacking the cmdline).

...

...

Right. Depending on whether U-Boot's UBI support or the kernel itself first touches the freshly-written UBI device things go wrong, becase only the hacked-up OpenWrt/LEDE kernel does the right magic on firstboot...

The kernel is in the UBI, so u-boot is going to attach it. I can't get around that without doing major reconstructive surgery to how this thing was designed to boot.

The number of OpenWRT/LEDE devices that have KERNEL_IN_UBI set are tiny. I think I only saw one or two others, and they were obscure or dev boards. This is likely why the issue hasn't come up before, and it could have been a problem for awhile and nobody noticed.

I do the excact same for all boards on the oxnas target and it works great. I even store U-Boot's environment inside UBI volumes. I reckon it really depends on how you flash the device in first place, ie. using raw nand-write (which may need the before mentioned hack to erase the remaining free-space) or using ubiformat (which shouldn't need that).

...

I don't know who's to blame. That's why I started this three-way cross posting clusterfark. =)

Not too bad, at least we get to discuss some forgotten uglyness now before it starts to affect more people...

...

I'm most tempted to blame the kernel rather than u-boot. After all, I can change the kernel, and the old kernel worked fine.

I reckon it's somewhere between the way the image was generated and written to the flash and then didn't get the right treatment on first-boot because U-Boot tried to access it before it got fixed-up. Again, if you just use ubiformat to write the image, you won't need any EOF-markers or other hacks (ie. thus you also shouldn't include them in the ubinized image!)

Did you intentional drop linux-mtd from the CC's after I offered you to discuss your patches on linux-mtd? ;-)

Thanks //richard