<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
<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>
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