Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial port to motorola-potter (Moto G5 Plus) #147

wants to merge 3 commits into from


Copy link

telent commented May 14, 2020

This is more or less a copy of motorola-addison with some changes in the kernel config that I made experimentally and need to review before merge.

Good news: it boots, I can connect to it with adb or with USB networking
Bad news: it gets stuck at the "Mobile Nixos" splash screen, doesn't seem to be seeing the sd card where I put the rootfs image. Although there's a couple of lines in dmesg for mmc1, there's not nearly as much as there is for mmc0, and there's nothing in /proc/partitions

[    1.173625,6] sdhci: Secure Digital Host Controller Interface driver
[    1.173635,6] sdhci: Copyright(c) Pierre Ossman
[    1.173713,6] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.175842,0] qcom_ice_get_pdevice: found ice device ffffffc003ad3c00
[    1.175856,0] qcom_ice_get_pdevice: matching platform device ffffffc0b0235000
[    1.179494,0] qcom_ice 7803000.sdcc1ice: QC ICE 2.1.44 device found @0xffffff8001b70000
[    1.179880,0] sdhci_msm 7824900.sdhci: No vmmc regulator found
[    1.179893,0] sdhci_msm 7824900.sdhci: No vqmmc regulator found
[    1.180170,0] mmc0: SDHCI controller on 7824900.sdhci [7824900.sdhci] using 64-bit ADMA in CMDQ mode
[    1.210407,0] sdhci_msm 7864900.sdhci: sdhci_msm_probe: ICE device is not enabled
[    1.224882,0] sdhci_msm 7864900.sdhci: No vmmc regulator found
[    1.224896,0] sdhci_msm 7864900.sdhci: No vqmmc regulator found
[    1.225178,0] mmc1: SDHCI controller on 7864900.sdhci [7864900.sdhci] using 64-bit ADMA in legacy mode
[    1.246093,1] mmc0: Out-of-interrupt timeout is 50[ms]
[    1.246103,1] mmc0: BKOPS_EN equals 0x2
[    1.246112,1] mmc0: eMMC FW version: 0x07
[    1.246119,1] mmc0: CMDQ supported: depth: 16
[    1.246128,1] mmc0: cache barrier support 0 flush policy 0
[    1.255593,1] cmdq_host_alloc_tdl: desc_size: 768 data_sz: 253952 slot-sz: 24
[    1.255773,1] mmc0: CMDQ enabled on card
[    1.255786,1] mmc0: new HS400 MMC card at address 0001

In the next few days I have another device arriving, hopefully then I won't need to use this one for actual, y'know, telephony, and will be able to flash the rootfs normally

telent added 2 commits May 12, 2020
This is a combination of guesswork and comparison with the config from
my running Android rom (Omni).  Need to go back through it and find
out which of the changes are actually appropriate/required.
@telent telent marked this pull request as draft May 14, 2020
Now it finds the SD card! :-)
Copy link

samueldr commented May 15, 2020

Some extra credits:

I'm assuming the white LED is not enabled at all (or only when charging), from what I'm reading.

I'm assuming the following is the LED:

Can you add a patch enabling the LED by default, like the following ones?

This is a new standard I'm trying to get going in Mobile NixOS, where devices with a LED should default to enabling and lighting it with the kernel, as default-on. When and if software wants to control it later on for notification status, they'll simply configure it in the sysfs trees anyway.

(For multi-colour LEDs, one colour should be used for default-on, and another for battery-charging.)

Copy link

samueldr commented May 15, 2020

Just saying, in case you're cleaning up your commits, the novel changes and patches should stay separate commits. Here I mean the mmc patch addition, and possibly the LED enabling patch. Though if you do some fixups to the device config or kernel build, or even those patches, a rebase would be well-received :).

@samueldr samueldr added the type: port label May 15, 2020
Copy link

samueldr commented May 24, 2020

Oopsie, it's possible the LED thing can't work.

It uses leds-atc, which for addison will not work as expected. First, the driver needs to be tweaked to allow setting an initial state (trivial enough). Though, once done, it works, but something resets the state of the LED hardware-wise just after it lights-up at boot.

The thing that resets it doesn't notify the kernel; the kernel still thinks it's turned on if you try and read information in the /sys fs.

You may want to try applying that commit and see if it works for your device, but I guess chances are low.

Copy link

samueldr commented May 26, 2020

With #152 merged, this PR needs some changes. They should be rather trivial to implement. Tell me if there is anything non-obvious or broken.

Copy link

telent commented Jun 2, 2020

Just FTR, this PR is superseded by which starts from a more recent upstream (post-#152) and has better commit messages. At least, longer ones.

I'm going to give the led thing a go on that PR and let you know how ti goes

Copy link

telent commented Jun 3, 2020

Closing this in favour of #159

@telent telent closed this Jun 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.