247 Members
3 Servers

Load older messages

Timestamp Message
16 Feb 2019
22:57:45@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> now i need to sleep. i'm so tired that i'm having hard time remembering what i'm actually trying to accomplish :D
22:57:52@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> good night people!
23:34:16@_discord_476183048937930762:t2bot.iomrfixit2001 Now THAT patch looks like a keeper to me!!
23:34:53@_discord_476183048937930762:t2bot.iomrfixit2001 nuumio: great job! Will test when I'm able, but I expect if it's testing well for you that we finally have a fix 😃
17 Feb 2019
06:12:57@_discord_476183048937930762:t2bot.iomrfixit2001Redacted or Malformed Event
06:13:54@_discord_476183048937930762:t2bot.iomrfixit2001 And the million dollar question still is WHY the mmc driver is conflicting. But personally I think this is a reasonable workaround. 😃
06:14:19@_discord_476183048937930762:t2bot.iomrfixit2001Redacted or Malformed Event
06:15:00@_discord_476183048937930762:t2bot.iomrfixit2001 nuumio: one note... might want to wrap the whole mmc check in an ifdef PCIE_ROCKCHIP so it doesn't run if the kernel isn't compiled with pcie.
08:15:31@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> mrfixit2001: good point about PCIE_ROCKCHIP and true, the root cause of this is still a mystery
09:08:47@druth:matrix.orgdaru joined the room.
12:51:25@_discord_464344567496572929:t2bot.ioPine64Bot <kierank> Is there a way to make the rockpro64 automatically boot on power insertion
12:51:25@_discord_464344567496572929:t2bot.ioPine64Bot <kierank> or equally start up on power loss
12:59:30@_discord_464344567496572929:t2bot.ioPine64Bot <kilobyte> kierank: I have the opposite problem: the reset button rarely works without power cycling. Turning on power, on the other hand, is 100% reliable.
12:59:45@_discord_464344567496572929:t2bot.ioPine64Bot <kierank> Ah I don't use the reset button
13:00:53@_discord_464344567496572929:t2bot.ioPine64Bot <kilobyte> whether DP will work after boot is random, but if it doesn't come up, it's either the system not noticing it (can be ssh-ed in) or the usual USB crash, which often needs another power cycle
13:03:19@_discord_476183048937930762:t2bot.iomrfixit2001 nuumio: saw your updated commit, looking forward to testing it! If it checks out, you ok if I include it in my releases? I have been postponing My recalbox and Debian updates until this was fixed
13:03:50@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> mrfixit2001: just pushed squashed one: https://github.com/nuumio/linux-kernel/commits/Rp64Sdio0PcieWorkaround
13:04:10@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> and you're welcome to include it :)
13:05:28@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> i'm just about to start reading of dt overlays to check if ayufan's idea of loading sdio0 enabling overlay works too. i guess it would
13:05:59@_discord_476183048937930762:t2bot.iomrfixit2001 That's great and thanks!! Only suggestion (until I test it) is to include your default defer count of 50 in the documentation update.
13:09:42@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> ok, i'll update docs (also adding "Only enabled with CONFIG_PCIE_ROCKCHIP.") and overwrite that HEAD with force push
13:14:35@_discord_476183048937930762:t2bot.iomrfixit2001 😃 the idea of a dtoverlay is interesting. It may work, but I think it would require both another dt file and a kernel parameter to be added, right? Whereas your commit it "just works", which I like more 😃
13:25:19@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> just pushed again with updated docs. i think that overlay needs dt file (where sdio0 get enabled), overlays + configfs for it enabled (should be in ayufan's 4.4 already) and then loading the overlay (after boot with userspace tools)
13:25:52@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> this seems to sum it up nicely: https://elinux.org/R-Car/DT-Overlays
13:27:59@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> one side effect of the deferred probing is that sdmmc gets deferred too. i don't know if that would cause any trouble
13:30:26@_discord_476183048937930762:t2bot.iomrfixit2001 Yeah, but your commit doesn't require any of that 😉 as for a side effect, id suggest test booting off sd, emmc, and USB (do we even have a working SPI flash uboot for the pro to support USB boot?)
13:34:23@_discord_476183048937930762:t2bot.iomrfixit2001 What are your thoughts about tweaking your patch to use a preset max number if milliseconds to defer, rather than a defer count? Seems like it may give users better control.
13:44:45@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> it would certainly make it more clear how long it take before giving up on waiting for pcie
13:48:18@_discord_476183048937930762:t2bot.iomrfixit2001 😃 I think it's more aligned with other kernel settings as well.
13:48:22@_discord_464344567496572929:t2bot.ioPine64Bot <nuumio> that default count of 50 is just something that i guessed would be enough

There are no newer messages yet.

Back to Room List