<samueldr> oh right
<samueldr> there isn't one or mainline
<colemickens> android-kernel/config.aarch64 comes from the PR you linked
<samueldr> good
<samueldr> we'll probably need to make one for mainline, based off that blueline_defconfig
<samueldr> because we need to tweak options
<samueldr> OR, introduce partial configs
<samueldr> so we can compose them
<samueldr> partial configs surely would be better in the end
<samueldr> blah!
* colemickens adds to list
<samueldr> make[3]: *** No rule to make target '/nix/store/9nza2zs0xal07h1anxi2qn4sd45j0q8l-linux-5.8.0-rc4-mainline-aarch64-unknown-linux-gnu/dtbs/5.8.0-rc4-mainline/hisilicon/hi3660-hikey960.dtb', needed by '__dtbs_install'. Stop.
* samueldr restarts, only building the bluecross dtb
<samueldr> blueline*
<samueldr> I didn't know the status of the mainline work on that device
<samueldr> that's somewhat exciting
<colemickens> for trying to get an image to boot, do I need the ability to capture adb passthrough?
<samueldr> hm?
<samueldr> I don't understand the question
<colemickens> Sorry, the Android Debug Cable, the postmarket wiki confirms my suspicion that a passthru board isn't always necessary.
<samueldr> heh
<colemickens> So if I don't need to capture adb, I have a FT232 and might be able to just hack something together.
<samueldr> that's my edit :)
<colemickens> I had a feeling
<colemickens> oh and the pass through part, ha, ok
<samueldr> it's more of a convenience thing
<samueldr> note that cable length may be important up to your serial dongle
<samueldr> (and still, DO order those passthrough breakout adapters, they're helpful!)
<samueldr> long cables from my breakout to the FTDI didn't work
<samueldr> but short did
<samueldr> here, long was the length that was already on a known-good serial adapter
<samueldr> short is ~3"
<colemickens> ok
<samueldr> (a bit less than 10cm for the other kind of people)
<samueldr> though the author of that repo (the android debug cable howto) didn't have issues with longer cables
<samueldr> it might be because of the specific breakout board too
<samueldr> it wouldn't surprise me that the cheap one harms signal integrity
<samueldr> if the pixel 3 is like the pixel 2 (likely to be) you should have serial output during the boot up too
<samueldr> like from the UEFI before even ABL is running
<colemickens> my ft232 still has a jumper on rxd/txd from when I got it, which I think is for testing; I think it must've been on the first time I tried to do something with it? oh dear.
<samueldr> I think it's expected that you set it between two values to setup the "voltage" level on that "not-ground-not-tx-not-rx" cable
<samueldr> or pin, here
<samueldr> or maybe for setting whether it's 5V or 3.3V
<colemickens> a comment on sparkfun says "The quickest and easiest way to make sure everything is working is to do a TX/RX loop-back. To do this, insert a jumper wire between TX and RX. Anything that is transmitted from the TX pin will be echoed back to the RX pin."
<samueldr> ah
<samueldr> makes sense too
<colemickens> weird, I definitely flashed esphome devices with this, I must've taken it off and put it back on. Regardless. This is fun, I'll be setup soon to test it out.
<colemickens> Were you doing a build? It sorta seemed like you'd made a smidge of progress or were trying something else?
<samueldr> yeah, looking at how to get your dtb built
<samueldr> I think I'm 1 or 2 builds to having it
<samueldr> obviously I won't be able to boot it :)
<colemickens> I'll be curious to see what steps you're doing. I don't really know what that entails at all :|
<colemickens> "get your dtb built" is magic to be right now :)
<samueldr> I think you know what a dtb is, at least at the higher level, right?
<samueldr> well, the proper name is FDT, .dtb is the extension for an FDT
<colemickens> vaguely that a device tree describes some sort of "how to access hardware" usually for arm type devices
<colemickens> if I'm giving my honest, without googling it rough understanding
<samueldr> I think it should be sufficient
<colemickens> "It is derived from the IBM OpenFirmware specifications and has been chosen as the default mechanism to pass low-level hardware information from the bootloader to the kernel."
<colemickens> ok
<samueldr> so basically the godawful way they chose to do this is not to have it be part of the hardware it describes
<samueldr> but somehow part of the operating system build
<samueldr> and you need to have it loaded *somehow*
<samueldr> AFAIUI linux can load a dtb that is appended to a kernel "image" (including zipped image)
tilpner_ has joined #nixos-aarch64
<samueldr> dtbs_install should, in theory, just build all dtbs and install them
<samueldr> but for some reason an unrelated board won't build
<samueldr> so I looked in the git history, found out the name of the dts (device tree source), and am trying to `make ` it
<colemickens> so Image.gz-dtb is Image.gz with the (built?) dtb stuck on the end?
<samueldr> yep
<colemickens> ok ok
<samueldr> with "OEM kernels", it's generally a step that's part of the make isntructions
<samueldr> since you build a kernel for a specific device
<samueldr> with mainline, it could be a generic kernel
<samueldr> and that's where my knowledge is a vague intuition
<samueldr> that it's appended somehow external to the build
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
<colemickens> So, as an aside and checking my understanding, are you not having this with PBP? Does it not use mainline? Or it just does the dtbs_install process and works as expected?
<samueldr> ah!
<samueldr> good question!
<samueldr> it can be provided through other means
<samueldr> one of them is in a bios-like fashion at a well-known address
<samueldr> in theory it should have been that the bios provides it and everyone's happy
<samueldr> but the kernel team decided they are gatekeepers of device trees (probably because some of poor quality)
<samueldr> so the "bios" needs to load what the kernel wants, for the kernel, in that well-known location
<samueldr> for most ARM SBCs it's u-boot that does that
<samueldr> if you look into our extlinux.conf files, it sets FDTDIR, which u-boot knows to look for $board_name at the right location (oversimplified) and it loads it at the well-known memory address
<colemickens> so for the pixel3 do you lean on the Android bootloader then?
h0m1 has quit [Ping timeout: 272 seconds]
<colemickens> I think I get that. On PBP, you build the bootloader, so you need to put the dtb in it so it cna stick it in memory for the kernel to read?
<samueldr> well, you're kinda forced to lean on ABL
<samueldr> (ABL being the UEFI android bootloader)
<colemickens> ok
<samueldr> though you could boot Tianocore
<colemickens> but presumably it would still need to do this dtb process too
<samueldr> presumably
<samueldr> though I'm not sure why the device tree eludes building
<samueldr> ++++ make 'O=$(buildRoot)' CC=/nix/store/d2bnfi2vlyz983di4a8py8b1s9zx7jyd-aarch64-unknown-linux-gnu-stage-final-gcc-debug-wrapper-6.5.0/bin/aarch64-unknown-linux-gnu-cc HOSTCC=/nix/store/x45gpnpvbq0l3b933k187qh53y1fg7ll-gcc-wrapper-9.3.0/bin/cc ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- sdm845-blueline.dtb
<samueldr> make[2]: *** No rule to make target 'arch/arm64/boot/dts/sdm845-blueline.dtb'. Stop.
h0m1 has joined #nixos-aarch64
<samueldr> something must be missing from the defconfig
<colemickens> +# CONFIG_EFI_ARMSTUB_DTB_LOADER is not set
<colemickens> I'm trying to wrap my head around if that's the desired value for us :)
<samueldr> cateee will help
<samueldr> >> If the device tree is provided by the platform or by the bootloader this option may not be needed
<samueldr> so I don't think?
<samueldr> do you know if the author of that fork is active somewhere?
<colemickens> #linaro-kernel
<samueldr> I was thinking blog posts, mailing lists, existing things they did
<colemickens> well, I haven't seen them active, but their nick is in there
<colemickens> ah, no
<samueldr> or better, some kind of yocto derivation or some kind of build system like that
<samueldr> it seems weird to me
<colemickens> looking. just found this on the way https://github.com/bluecross-dev
<colemickens> not sure if relevant
* colemickens theres probably some xda thread with a clue lol
<samueldr> looks android-ish
<colemickens> there's also lineage's crosshatch, but that's probably teh same or similar to the android-linux-stable kernel in android-kernel
<samueldr> yeah
<samueldr> got it
<samueldr> ++++ make 'O=$(buildRoot)' CC=/nix/store/d2bnfi2vlyz983di4a8py8b1s9zx7jyd-aarch64-unknown-linux-gnu-stage-final-gcc-debug-wrapper-6.5.0/bin/aarch64-unknown-linux-gnu-cc HOSTCC=/nix/store/x45gpnpvbq0l3b933k187qh53y1fg7ll-gcc-wrapper-9.3.0/bin/cc ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- qcom/sdm845-blueline.dtb
<samueldr> DTC arch/arm64/boot/dts/qcom/sdm845-blueline.dtb
* samueldr cleans up
bennofs__ has quit [Ping timeout: 264 seconds]
<samueldr> heh, it looks like building two kernels in parallel makes the build take ~2 times longer
<samueldr> I'm not even sure it is proper to cat like that
quinn has joined #nixos-aarch64
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
rajivr has joined #nixos-aarch64
<colemickens> samueldr: do you know how to check the offsets? (whatever those are? partition offsets?)
<colemickens> I also copied those frm the android PR but I don't know how they determined them either or to trust them ,etc
<samueldr> from the postmarketOS PR should be fine
<samueldr> but they're found using unpackbootimg
<samueldr> that tools is part of mkbootimg
<samueldr> which is in the shell.nix file of mobile nixos
<samueldr> you need a boot.img for the device, so e.g. from a factory flash file
<samueldr> or twrp is fine too
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
<colemickens> my fastboot seems finicky. It just stalls at Sending 'boot.img' (23196 KB).
<colemickens> I guess this is where the debug wire comes in handy
<samueldr> fastboot I've found sometimes doesn't work well on more recent devices
<samueldr> I do not know if it is expected to work fine with the pixel 3
<samueldr> hopefully it does
<colemickens> I'm going ot check and see if our android tools are up to date
<colemickens> up to date enough, downloading factory image to try to boot the stock recovery
<colemickens> it also does not boot, I'm going to take that as a good/bad sign. ha
<samueldr> recoveries and boot images are now extremely weird since
<samueldr> hmm
<samueldr> forgot the term
<samueldr> but boot.img now always hosts the recovery
<samueldr> in its initramfs
<samueldr> and default boot skips initramfs
<samueldr> system as root
<colemickens> weird
<samueldr> so I don't know if what you have is supposed to boot in a useful manner
<samueldr> it's also been making testing `fastboot boot ...` harder
<samueldr> I would maybe focus on getting the android kernel booting first, as the tooling is made to expect that
<samueldr> then you can at least rule out the tooling for mainline issues
<samueldr> (though yeah, serial will help too)
<colemickens> well, twrp says this should work and it doesn't.
<colemickens> part of the reason this device is getting RMA'd is a faulty USB port sooo I might be playing with fire.
<colemickens> but faulty mostly meant loose, I thought
<samueldr> might not help
<colemickens> this is a trip!
<colemickens> I feel like I'm getting trolled.
<colemickens> Also when I plug/unplugged the last time my wireless mouse stopped working until I replugged its usb reciver.
<colemickens> I am convinced linux's usb stack is badly buggy
<colemickens> it flashes bootloader_b and then turns around 10 seconds later and says it doesn't exist. that's not a bad usb connection. that's technology gaslighting me
orivej has joined #nixos-aarch64
<samueldr> :/
<colemickens> Okay, it flashed and failed into the bootloader too, "Enter reason: error boot prepare".
<colemickens> I already see a thing or two to tweak in default.nix, and parts on the way. I'll probably pick it up tomorrow or the next day.
<colemickens> $ unpackbootimg -i ~/Downloads/blueline-qq3a.200705.002/bootloader-blueline-b1c1-0.2-6374987.img -o ./test/
<colemickens> Android boot magic not found.
<samueldr> with the android kernel, right?
<colemickens> no, I haven't switched to :o
<samueldr> bootloader != boot.img
<colemickens> oh no
<colemickens> really?
<samueldr> bootloader is likely ABL, the UEFI program
<samueldr> that's my assumption
<colemickens> uh oh, yeah, the zip contains boot.img.
<samueldr> :)
<samueldr> I would work with the android kernel, if only because it reduces the questioning surface
<samueldr> I don't know if appending the FDT like I did is right
quinn has quit [Quit: ZNC 1.7.5 - https://znc.in]
<fps> hmm, i'm trying to get a systemd.service to run as a user. it starts allright, but for some reason PAM security limits do not apply to it..
<fps> ExecStart = "${pkgs.bash} -l -c ..." doesn't seem to be enough
zupo has joined #nixos-aarch64
<fps> oops, wrong channel :)
cole-h has quit [Quit: Goodbye]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
quinn has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
sphalerite has quit [Quit: WeeChat 2.6]
sphalerite has joined #nixos-aarch64
Gaelan has joined #nixos-aarch64
Gaelan_ has quit [Read error: Connection reset by peer]
elvishjerricco has quit [Ping timeout: 244 seconds]
elvishjerricco has joined #nixos-aarch64
globin has quit [Ping timeout: 260 seconds]
globin has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
mvnetbiz_6 has joined #nixos-aarch64
mvnetbiz_ has quit [Ping timeout: 256 seconds]
mvnetbiz_ has joined #nixos-aarch64
mvnetbiz_6 has quit [Ping timeout: 240 seconds]
mvnetbiz_8 has joined #nixos-aarch64
mvnetbiz_ has quit [Ping timeout: 260 seconds]
mvnetbiz_8 is now known as mvnetbiz_
mvnetbiz_ has quit [Client Quit]
mvnetbiz_ has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
quinn has quit [Quit: ZNC 1.7.5 - https://znc.in]
quinn has joined #nixos-aarch64
mla has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Danct12[m] has quit [Changing host]
Danct12[m] has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
quinn has quit [Ping timeout: 256 seconds]
quinn has joined #nixos-aarch64
zupo has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
Asmadeus has quit [Ping timeout: 244 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
nschoe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nschoe has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 264 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
nschoe has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
<DigitalKiwi> once again i am building ghc :(
<DigitalKiwi> why does it not get in hydra
<samueldr> too big
<samueldr> it gets into hydra
<samueldr> but the output doesn't get posted to the cache
<samueldr> (at least it was the issue if this hasn't been fixed)
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
<samueldr> I'm finishing up another update that will be an unmerged PR, too
<samueldr> I haven't tested 5.7 thoroughly though
<samueldr> I assume it's fine, but I don't know if it is
alp has joined #nixos-aarch64
<DigitalKiwi> is there a way to get it cached
<samueldr> upstream issue AFAIK
<DigitalKiwi> how come it works for x86_64-linux
<samueldr> they need to fix the thing that makes the build balloon up in size
<{^_^}> #66277 (by vcunat, 48 weeks ago, open): GHC too big for Hydra (aarch64 ATM)
<DigitalKiwi> is it possible for someone to manually add it?
<samueldr> nothing can be done manually in that process, by design
<DigitalKiwi> sad
<samueldr> the solution is to get upstream working on it https://gitlab.haskell.org/ghc/ghc/-/issues/17051
<DigitalKiwi> thanks for the links btw samueldr++
<{^_^}> samueldr's karma got increased to 248.9999999999998
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej_ has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64