| 06:06 | jnettlet[m]> | Here is a mainline u-boot for the mx6. https://github.com/SolidRun/u-boot/tree/master-mx6 |
| 06:07 | jnettlet[m]> | next patchset is device-tree overlays |
| 08:38 | topi`> | jnettlet[m]: would that branch be suitable for production? |
| 08:38 | topi`> | I've noticed one bug that pops up over and over again in the older uboot's ext2 implementation. Sometimes symlinks get buggy so having symlinks in your /boot ends up in tears |
| 08:39 | Ke> | experience is shown that if you want to be a good engineer, you do the QA for yourself |
| 08:39 | Ke> | just let others take care of crypto and security |
| 08:39 | topi`> | except in tight schedules, and then you do the QA at the customer's :) |
| 08:39 | Ke> | ah, you mean the reality |
| 08:40 | topi`> | the more you plan ahead, the harsher will the contrast be, between plans and reality |
| 08:40 | Ke> | "we" have done some subcontracting to many companies that do not seem to have any qualified engineers, everything is subcontracted |
| 08:40 | topi`> | this is the new normal. |
| 08:40 | Ke> | or mostly received as a package from ODM/OEM |
| 08:41 | Ke> | sure |
| 08:46 | jnettlet[m]> | topi`: that is current mainline so it is reasonably tested. I have tweaked some of the memory configurations but in general their settings matched ours. |
| 08:47 | topi`> | I guess the dram controller on the i.mx6 is not as tricky as it is on the Marvells |
| 08:47 | topi`> | also, not as high performance... |
| 08:48 | jnettlet[m]> | And most customers use NXPs configuration spreadsheet. U-boot basically mimics those formulas |
| 08:50 | topi`> | Ke: did you already succeed in making a watchdog for the kernel boot to uboot code? |
| 08:50 | Ke> | not yet |
| 08:50 | Ke> | seems to be source code change kind of thing |
| 08:50 | topi`> | I'm also trying to achieve something similar, but the meaning is to detect whether the kernel was able to successfully boot rootfs, and if not, then do a full factory reset |
| 08:50 | Ke> | somehow it seems there are no watchdog commands on u-boot everything happens at source code modification level |
| 08:50 | topi`> | (restore the image stored on a certain partition on emmc) |
| 08:50 | Ke> | sure |
| 08:51 | Ke> | only in my case the first boot always fails |
| 08:51 | topi`> | well, it sounds like you need a watchdog :) |
| 08:51 | Ke> | I could also try early printk and whatnot |
| 08:51 | topi`> | if it's about the DRAM setup, then you most probably won't get any early printks even |
| 08:51 | Ke> | it's not like I would be pathologically unable to fix the problem |
| 08:52 | Ke> | dram setup is completely fine, even at a level where dram survives over boot |
| 08:53 | Ke> | I was considering running u-boot memtest thoug |
| 08:58 | jnettlet[m]> | topi`: I have patches to enable the watchdog in uboot |
| 08:59 | jnettlet[m]> | For MX6 |
| 09:02 | Ke> | jnettlet[m]: is the doggo shut down before booting linux, or does linux need to be able to reach wd in certain time |
| 09:04 | jnettlet[m]> | Ke: i set the timer in SPL for a time that is long enough for systemd to come up and start servicing the watchdog |
| 09:05 | Ke> | ie. not shut down, I guess |
| 09:06 | Ke> | is there some configuration for it, or does it always require source modifications? |
| 09:07 | jnettlet[m]> | It requires a source modification. Although if you enabled uenv support in SPL that could be used for configuration. |
| 09:08 | Ke> | but you have to write that configuration support yourself obviously |
| 09:18 | jnettlet[m]> | There are userspace tools to modify the uboot environment |
| 09:20 | Ke> | you mean u-boot by default reads some env variable to enable watchdog? |
| 09:20 | jnettlet[m]> | Ke: no that would need to be added, but would be a trivial patch |
| 09:21 | Ke> | sure |
| 09:22 | jnettlet[m]> | topi`: oh wait that branch is missing some cache alignment patches for mx6. Only necessary if you are using the network. I will push that later today |
| 09:34 | topi`> | why does the network suffer from cache alignment? :) |
| 09:35 | topi`> | jnettlet[m]: did I understand that the watchdog should be set up in SPL, and not in uboot? |
| 09:35 | topi`> | probably needs at least 60 seconds, to successfully allow linux to load and boot |
| 09:36 | jnettlet[m]> | I set it in SPL, so if uboot gets upgraded and fails you can initialize recovery from there |
| 09:36 | topi`> | I'm willing to test out some watchdog experiments, so that Ke can get the stuff going :) |
| 09:36 | jnettlet[m]> | Our base Debian image boots in around 12 seconds |
| 09:36 | topi`> | will probably also fit my mcbin with a watchdog, because it doesn't seem to be doing well these days |
| 09:37 | topi`> | jnettlet[m]: if the SPL watchdog bites, what are your avenues for a backup, then? Load UBOOT from a different place? |
| 09:37 | jnettlet[m]> | Yes |
| 09:37 | jnettlet[m]> | So with emmc you can use the second boot hardware partition |
| 09:37 | topi`> | I align my stuff to start from sector 2048, that means there's only 1MB of space for uboot |
| 09:38 | topi`> | does SPL know how to access the HW partition? |
| 09:38 | topi`> | all I remember is that there are some confusing flags that need to be fiddled with, using emmc-tools, to be able to write there |
| 09:38 | jnettlet[m]> | In the mainline uboot it can be setup |
| 09:39 | topi`> | why does that matter? by the time UBOOT is running, the hwboot partition has already been accessed (to load uboot!) |
| 09:40 | topi`> | oh, SPL code is also compiled from uboot src |
| 09:40 | topi`> | sorry |
| 09:40 | topi`> | I'm being stupid here :) |
| 10:06 | jnettlet[m]> | No worries. |
| 10:06 | jnettlet[m]> | It is early still. |
| 15:08 | vpeter> | Artox: In case you missed - http://forum.solid-run.com/linux-on-cubox-i-and-hummingboard-f8/invalid-signature-in-debian-repo-t3393.html#p22533 |
| 15:45 | suihkulokki> | this mcbin came with |
| 15:45 | suihkulokki> | U-Boot 2017.03-armada-17.10.1-g440395a (Oct 20 2017 - 10:10:15 -0700) |
| 16:00 | suihkulokki> | seems cold booting is challenge |
| 16:01 | suihkulokki> | u-boot is new enough to have bootefi but custom env preventing automatic installer |
| 17:02 | Artox> | vpeter, :( |
| 17:02 | Artox> | It is a sad story |
| 17:02 | Artox> | I extended the key more than a week ago |
| 17:03 | Artox> | people just need to fetch it from the repos (Release.key) |
| 17:03 | Artox> | problem is: no -keyring package |
| 17:03 | Artox> | and university just started full speed again |
| 17:04 | Artox> | https://repo.solid-build.xyz/debian/jessie/bsp-imx6/Release.key |
| 17:04 | Artox> | should be the same key as for wheezy, if you want to jump in and reply |
| 17:06 | vpeter> | Artox: Rather not - not familiar with Debian. |
| 17:08 | Artox> | I'll try to remember replyng later tonight, homework comes first |
| 17:10 | vpeter> | Obviously :-) |
| 17:11 | Artox> | I have the chance to turn my back on all lectures, by passing all of them this winter |
| 17:11 | vpeter> | What do you study if no secret? |
| 17:12 | Artox> | CS |
| 17:27 | topi`> | suihkulokki: why does custom env prevent automatic installer? |
| 17:28 | topi`> | I'm preparing an image for production, does anyone know if the emmc chips have a tendency to "shrink" in blocks due to bad blocks when using year after year? |
| 17:28 | topi`> | they did do that a while back, or then I just imagined |
| 17:28 | topi`> | so I want to make the last partition slightly smaller than what would otherwise be available to it |
| 17:32 | vpeter> | topi`: For Armbian I read while ago: On SD cards with just 4GB or less we leave 5 percent unpartitioned, with 8 GB it's 2% and above 1%. |
| 18:13 | topi`> | with 8GB 2% makes it 160MB |
| 18:13 | topi`> | but SD cards are probably lower quality than emmcs |
| 18:18 | vpeter> | New sd cards has very different capacity. Wondering how much difference is with emmc. |
| 18:45 | topi`> | I googled the id code for the Samsung device on HB Gate, and it always showed up as 7.28 GiB in the kernel logs on various devices |
| 18:46 | topi`> | Samsung 8GME4R |
| 18:47 | vpeter> | GiB - what about in B :) |