profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/samueldr/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Samuel Dionne-Riel samueldr Mobile @NixOS (@mobile-nixos) samueldr pretty much everywhere? https://samuel.dionne-riel.com/ @NixOS committer, Mobile NixOS founder. Hard at work putting it on your phone.

samueldr/cross-system 28

Minimal config to cross-compile a NixOS system image for arm platforms

nix-community/nix-review-tools 12

WIP tooling [maintainer=@samueldr]

nixcon/nixcon-meta 2

Things too small to get their own repos

samueldr/demo-xkbcommon 1

Demo of libxkbcommon usage, with compose support (dead keys)

samueldr/hack-merged-icons 1

A small NixOS module for a huge hack

mobile-nixos/make_ext4fs 0

Work repo // upstream → https://git.openwrt.org/?p=project/make_ext4fs.git;a=summary

startedpinpox/wallpaper-generator

started time in a day

pull request commentNixOS/mobile-nixos

google-blueline: init

Oops, didn't comment on this port:

Hi!

We just had some major~ish changes, at least one affecting new ports. I would heavily suggest rebasing on top of the latest master update.

The main change affecting ports is that we now have required kernel configuration options, which set known good values to a lot of "difficult to guess" options. A simple bin/kernel-normalize-config should be all that is needed.

Hope this helps!

In theory you just need to normalize. IIRC normalizing automatically handles setting the right values for that new correctness harness.

samueldr

comment created time in 4 days

pull request commentNixOS/nixpkgs

Add Plasma Mobile Gear 21.05

Reviews from @NixOS/qt-kde peeps.

I'm pretty sure nothing was left TODO, and that was why I asked for a review from @ttuegel. Mainly a review since it adds a new directory under pkgs/applications that uses maintainers/scripts/fetch-kde-qt.sh.

samueldr

comment created time in 4 days

issue commentTow-Boot/Tow-Boot

Investigate `upstream_kernel` option for rpi4 users?

upstream_kernel AFAIUI only affects which files gets loaded by the vendor firmware. Having to rely on the vendor firmware's behaviour for this would be a failure with Tow-Boot's goals of making things simpler. And really what this would do is select a specific dtb file that the vendor firmware loads before Tow-Boot is loaded.

Though this does open a parallel question, which is maybe what you really meant:

Should the dtb filename to load be an "firmware option" configurable by end-users?

Even one step further:

Should dtb filename rather be a list of valid names to look for, rather than a static name? and in that case Should the preferred dtb filename order be a firmware option configurable by end-users?

colemickens

comment created time in 7 days

issue commentNixOS/mobile-nixos

pine64-pinephone: Phosh boot delayed by network-online.target (6.7s for my Wifi; timeout for when there is no signal)

You think 18 seconds is a long boot? Looks at android boot times...

tomfitzhenry

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot [new model]

Indeed, it already does in somesituations!

cwyc

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot [new model]

Jesus fuck, Broadcom.

For once the problem actually comes from the tradition of assuming the kernel knows best about the hardware's own description. The firmware is doing the right thing: describing its own hardware.

The kernel's view about device trees should, in my opinion, always have been built as discrete overlays on top of the firmware-innate FDT, rather than wholesale overriding it.

It would also have made loading overlays by the firmware automagically work. E.g. those raspberry pi overlay bords with an on-board DTB overlay that the firmware loads.

cwyc

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot [new model]

It might be more viable to forward the entire DT, and then apply overlays as real overlays at boot time

If only it was this simple. We need to support one boot flow, or get much much more resources if we need to start supporting more boot flows.

The boot flow that was decided upon by predecessor decision makers, and is the preferred boot flow by mainline U-Boot is the Generic Distro Configuration Concept. This is what boots all mainline-supported boards through our universal images. Whether it is the SD card, or transitively the UEFI iso.

Now, this was actually tangential to the problem, but it sets the scene for what comes here: we need to load the kernel provided device tree binaries. While mainline states that it's not necessary, the reality is that it is necessary to load the device tree binaries from the same revision the kernel was built from. Mainline fixes too many things in their opinion about the device trees.

cwyc

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot [new model]

(That overlay change wouldn't work really, as it would break older BCM2711B0 boards AFAIUI.)

cwyc

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot

Yes, without testing (I can't not having a newer pi4), I can say I see it's likely 100% that.

What will need to happen is that somehow U-Boot will need to be aware of properties to "forward" from the "firmware-native" DT.

cwyc

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot

Yes, sorry, as you might now see I updated the post since I saw the source. And I hate every ounce of it.

cwyc

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot

Now that I've read that forum post...

I think the problem is that the CM4, like newer Pi 4s, has a BCM2711C0.

Sounds like a hardware revision that isn't being accounted for in mainline, and maybe not even in the vendor kernel, and instead being handled entirely on their firmware? UGH!

cwyc

comment created time in 8 days

issue commentNixOS/nixpkgs

Raspberry Pi 4: Can't mount SD card during boot

(Answering for the DT issues)

@K900 your link isn't where your overlay values are being set:

  • https://github.com/raspberrypi/linux/blob/4a929be607a35b33f4d56a77e4ac70613b674e2c/arch/arm/boot/dts/bcm2711.dtsi#L435
		dma-ranges = <0x0 0xc0000000  0x0 0x00000000  0x40000000>;

Your overlay value sets it at:

            dma-ranges = <0x00 0x00 0x00 0x00 0xfc000000>;

How did you get the values you're using?

I see the pre-built dtb uses the same as the vendor kernel and mainline does:

dma-ranges = <0x00 0xc0000000 0x00 0x00 0x40000000>;

(verified throuch dtc --sort ....)

So, something knows to affect the dma-ranges property of the emmc2bus, and we'd need to figure our what is, and why it is, so we can then ask around at mainline (where?) about a proper solution I guess.

In theory, if your values comes from the running U-Boot, U-Boot should have loaded the .dtb found on the SD card image, which in turn should be coming from the raspberrypi/firmware repo. Though maybe it's not loading the .dtb file as I expected?

Now, if it's coming from a non-U-Boot boot (or if U-Boot doesn't load the .dtb file as I assumed) then it means the vendor firmware itself is setting it to that value. Which might mean something is wrong in those dts files. But it would surprise me that the foundation's device tree is wrong. Especially since @alyssais tested against linux_rpi4 AFAIUI.

cwyc

comment created time in 8 days

create barnchsamueldr/sunxi-tools

branch : wip/f1c100s-forward-port

created branch time in 9 days

fork samueldr/sunxi-tools

A collection of command line tools for ARM devices with Allwinner SoCs.

http://linux-sunxi.org/

fork in 9 days

pull request commentNixOS/mobile-nixos

Pin Nixpkgs (without Flakes)

Good catch; they should be removed. They're largely useless without providing --arg pkgs or doing other operations.

samueldr

comment created time in 9 days

create barnchsamueldr/u-boot

branch : wip/powkiddy-v90-mainline

created branch time in 9 days

startedlibrerpi/lk-overlay

started time in 10 days

issue commentNixOS/nixpkgs

option boot.loader.grub.memtest86.enable not taking effect for iso image builds

It would be required to be optional, as AFAIUI the passmark memtest86+ binary is not Free software, and might not be redistributable here.

cherusk

comment created time in 15 days

issue commentthefloweringash/kevin-nix

LICENSE, or lack thereof

Thanks!

samueldr

comment created time in 15 days

pull request commentNixOS/mobile-nixos

asus-dumo: fix make-kernel-its for recent makeimage

Thanks, I had something temporary going in a WIP branch

  • https://github.com/samueldr-wip/mobile-nixos-wip/commit/87a34c9b1542c9c568c104fbcd956056a6ddd745

I wonder why you ended up fixing this though. I'm 99.99% sure I'm the only individual on earth using a "scarlet" class chromeos device with non-ChromeOS on it.

r-burns

comment created time in 15 days

issue commentNixOS/nixpkgs

PSA: systemd in initramfs

cc @ElvishJerricco

@kirelagin if you hadn't seen, #120015 exists.

Hopefully you can collaborate :).

kirelagin

comment created time in 15 days

issue commentNixOS/nixpkgs

option boot.loader.grub.memtest86.enable not taking effect for iso image builds

The NixOS iso installer does not use the modules system's GRUB generator (or any other) for the boot files.

I'm not saying your issue is invalid, I'm saying this is the reason.

To automatically make use of anything provided by those modules, the iso image building would need to be revamped to re-use the tooling provided in the modules system, and the tooling in the modules system would need to be reworked to work better for "non system" use cases.

cherusk

comment created time in 15 days

PR opened NixOS/nixpkgs

sunxi-tools: 2018-11-13 -> 2021-08-29
Motivation for this change

Update sunxi-tools.

Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

  • Built on platform(s)
    • [x] x86_64-linux
    • [ ] aarch64-linux
    • [ ] x86_64-darwin
    • [ ] aarch64-darwin
  • [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • [ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • [ ] Tested execution of all binary files (usually in ./result/bin/)
  • 21.11 Release Notes (or backporting 21.05 Release notes)
    • [ ] (Package updates) Added a release notes entry if the change is major or breaking
    • [ ] (Module updates) Added a release notes entry if the change is significant
    • [ ] (Module addition) Added a release notes entry if adding a new NixOS module
  • [x] Fits CONTRIBUTING.md.

Tested only sunxi-fel, but if other tools fail, it's unlikely due to packaging due to how they're made.

+5 -5

0 comment

1 changed file

pr created time in 16 days

create barnchsamueldr/nixpkgs

branch : updates/sunxi-tools-2021-08-29

created branch time in 16 days

push eventsamueldr/wip-pinebook-pro

Pierre Labadens

commit sha c212558fba199ce2b14d69de31185a6f1cdd3929

keyboard-updater: 2020-01-22 → 2021-07-28

view details

Pierre Labadens

commit sha 359360935c637b5778554c41b17dd49a2f31c080

README.md: document keyboard controller Add a paragraph about identifying the SH68F83 keyboard controller IC.

view details

Samuel Dionne-Riel

commit sha 7df87f4f3baecccba79807c291b3bbd62ac61e0f

Merge pull request #31 from plabadens/keyboard-updater keyboard-updater: 2020-01-22 → 2021-07-28

view details

push time in 17 days

PR merged samueldr/wip-pinebook-pro

keyboard-updater: 2020-01-22 → 2021-07-28

Bump the keyboard updater to dragan-simic/pinebook-pro-keyboard-updater@bd8d2ea48992b3e6ddd0b9435d21b74cdcf97224. The new version appears to fix the sluggishness of the touchpad, and keeps touchpad latency below 10ms. This PR resolves #30.

While this doesn't change from previous versions, it seems one version (SH61F83) of the keyboard controller only tolerates 8 writing cycles. The best (only) way of identifying it is to disassemble the laptop. Also, it would be nice to know/verify where that new binary blob we're flashing comes from.

  • [x] Switch to latest version 2021-07-28
  • [x] Document steps to identify the SH61F83 IC
  • [ ] Test the new firmware extensively
+9 -4

5 comments

2 changed files

plabadens

pr closed time in 17 days

issue closedsamueldr/wip-pinebook-pro

Update keyboard/touchpad firmware updater to new fork, with new touchpad firmware

We should have a firmware updater for the touchpad like for the keyboard:

From https://forum.pine64.org/showthread.php?tid=14531

I'm feeling happy, excited, and a bit privileged Cool to announce the availability of the new vendor-provided touchpad firmware that fixes the issues we've all been experiencing with the Pinebook Pro touchpad. One of the biggest issues was the initial lag upon finger movement, about which you can read more in this forum thread; it has been confirmed multiple times to be a touchpad issue and not a Linux issue.

Based on the testing already performed by a few community members, myself included, this firmware update makes the touchpad very responsive and there are no traces of the dreaded initial delay. I've also performed tests using the evtest utility, to eliminate any subjectivity, and the measured latency stays around or below 10 ms... The numbers don't lie. Smile You can read more about the evtest results with the old firmware in the above-linked forum thread.

I've prepared an updated version of the keyboard and touchpad firmware update utility, which is available on GitHub. Beside the updated touchpad firmware, my fork of the firmware updater brings other improvements, including improved feedback/status messages, improved handling of command-line arguments, added ability to cancel each update step, and improved documentation.

closed time in 17 days

colemickens

pull request commentsamueldr/wip-pinebook-pro

keyboard-updater: 2020-01-22 → 2021-07-28

Yeah, that's basically what I assumed without looking.

I wonder if there's something in the programming mode flow that identifies the chip, which could be used... but that's more for the upstream~ish vendor utility than ours.

I'll merge, but there's literally no good way to prevent people from (maybe!) bricking their touchpad/keyboard firmware... BUT nothing changes compared to the previous state.

plabadens

comment created time in 17 days

pull request commentsamueldr/wip-pinebook-pro

keyboard-updater: 2020-01-22 → 2021-07-28

No software way to detect the controller, right?

plabadens

comment created time in 17 days