| 10:01 | topi` | jnettlet: a suggestion for UBOOT: can the boot scripts be modified in such a way that if the user breaks the sequence and defines "custom_bootargs", then they would override anything that normally would come through "mmcargs" |
| 10:01 | topi` | this way I could quickly modify e.g root=xxx without having to do the ext2load stuff manually for zimage and the dtb... |
| 10:02 | jnettlet | topi`, why not just set your own custom mmcargs? |
| 10:03 | topi` | doesn't it get overridden when I do "run loadbootenv; run importbootenv" |
| 10:04 | topi` | in mmcboot, mmcargs will get overwritten |
| 10:04 | topi` | oh, if I define my own "mmcargs" then of course it'll work |
| 10:20 | jnettlet | topi`, did that work okay for you? |
| 10:28 | topi` | my kernel got stuck once again after WDOG reset... |
| 10:28 | topi` | I think this must be because I noticed the pcie lines back in dmesg, even though I thought I disabled them from the .dtb |
| 10:29 | topi` | I also verified from /sys/firmware/devicetree that the pcie@xxxxx/status did say "okay" instaed of "disabled". It correlates nicely with this behaviour of getting stuck |
| 10:30 | topi` | duh, "run mmcboot" ended up without kernel img |
| 10:31 | topi` | I did loadbootenv and importbootenv, maybe I'm missing a third script? |
| 10:33 | jnettlet | you need loadbootfile also |
| 10:34 | topi` | OK |
| 10:34 | topi` | actually "run bootcmd" worked fine |
| 10:35 | topi` | nope, it overrode my bootargs |
| 10:52 | topi` | also I am no longer able to switch off the pcie (why?) ... I tried also setting node called &hdmi to disabled, but it did not affect anything |
| 10:53 | topi` | kernel make said DTC arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dtb |
| 10:54 | topi` | so I guess it did recompile that dtc after I edited imx6qdl-hummingboard2-som-v15.dtsi |
| 10:55 | topi` | I need to trace this down to the last bit... |
| 10:59 | topi` | I remember I did check yesterday that the pcie messages stopped coming to dmesg after you suggested disabling in in the device tree... |
| 10:59 | topi` | wtf is going on now |
| 11:05 | topi` | a-ha! |
| 11:05 | topi` | uboot says: |
| 11:05 | topi` | Loaded imx6q-hummingboard2.dtb |
| 11:06 | jnettlet | oh because you aren't running the autodetect script for the fdtfile |
| 11:07 | topi` | I'll check the uboot vars |
| 11:07 | topi` | I reverted to a stock uboot image, maybe that was the "ages old" one |
| 11:08 | jnettlet | oh possibly |
| 11:08 | topi` | yes, it does not detect the emmc |
| 11:08 | topi` | mmc dev 1; mmcinfo gives empty sd |
| 11:11 | topi` | I'll grab the uboot .deb from repo.solid-build.xyx... |
| 12:43 | Artox | topi`, the problem should be the default bootcmd loading uEnv.txt |
| 12:43 | Artox | and that one used to contain something, like mmcargs to wrap a call to setenv for bootargs |
| 12:43 | Artox | imo its a bit messed up |
| 12:44 | Artox | there should be no setenv-call in uEnv.txt, just var= lines. |
| 12:44 | Artox | That lone however does not allow what you seek |
| 12:45 | topi` | that's why I proposed a quick and dirty "override" variable :) |
| 12:47 | Artox | "mmcargs=setenv bootargs quiet console=${console},${baudrate} root=${mmcroot};" |
| 12:48 | Artox | if we add this to mmcargs, anyone who overwrites mmcargs again uses the feature instantly |
| 12:48 | topi` | Artox: have you tested the spl.bin in jessie/cubox-i-uboot.dpkg that it works also when booting from eMMC? |
| 12:48 | Artox | if there is a boot.scr, we can't do anything |
| 12:48 | Artox | topi`, Never |
| 12:49 | topi` | where does the spl.bin come from, then? |
| 12:49 | Artox | sdcard |
| 12:49 | Artox | I only have boards that boot from sdcard |
| 12:49 | topi` | OK |
| 12:49 | Artox | ofc if the fuses are set right, I expect the same SPL to work, but I never tried myself |
| 12:50 | topi` | we tried one; it refused to boot and basically bricked the board |
| 12:50 | topi` | unless the keep-emmc-in-reset trick works... we haven't tried |
| 12:50 | Artox | you mean you wrote to the emmc once? |
| 12:50 | topi` | yeah |
| 12:50 | topi` | I prepared an image, and then the image was flashed to the emmc |
| 12:51 | Artox | I know the marvell boards would read SPL from boot0 partition |
| 12:51 | topi` | notice that if the emmc is totally empty, the BootROM won't even try to boot from it, and instead it offers usb-otg boot |
| 12:51 | Artox | no offset afaik |
| 12:51 | topi` | yeah |
| 12:51 | topi` | we just wrote spl+uboot to the normal sdcard locations, but emmc, and the SPL booted |
| 12:51 | topi` | but that was an older SPL from some old jessie image |
| 12:52 | topi` | it basically refused to load from emmc, and instead reverted to loading uboot.bin from SDcard, but that's okay for our purposes |
| 12:52 | Artox | sure |
| 12:53 | topi` | the emmc boot support seems to be the least well tested area... |
| 12:54 | Artox | that should be pretty accurate |
| 12:54 | Artox | becaise nots not fun to work with |
| 12:54 | Artox | so back to your question |
| 12:54 | Artox | https://github.com/mxOBS/deb-pkg_u-boot-cubox-i/blob/master/include/configs/mx6_cubox-i.h#L296 |
| 12:54 | Artox | This is the place where we could append to bootargsd |
| 12:54 | Artox | if there is no boot.scr |
| 12:55 | topi` | right |
| 12:55 | Artox | and the mmcargs isn't doing evil stuff such as calling bootz |
| 12:55 | topi` | well I just want to be able to break the boot, and set an alternate bootargs, and then continue booting :) |
| 12:55 | Artox | if you want to propose a patch, feel free |
| 12:56 | topi` | :) |
| 12:56 | Artox | I am too tired, and I am supposed to prepare for class |