<DigitalKiwi> https://sourceforge.net/p/libpng/bugs/230/ is this helpful
<{^_^}> davisking/dlib#264 (by miscellanea, 3 years ago, merged): Add arm files for libpng from official libpng v1.6.7 to support neon …
<samueldr> it might be, depends on how freeimage is actually using libpng
<clever> pbb: the entire username for haskell-init is 2mb
<clever> pbb: userland*
<clever> pbb: how large is the userland for u-root?
<pbb> 4.5MB
<pbb> lol
<pbb> it's Go
<clever> ah yeah, go tends to build static things
<pbb> I think rust could achieve better size
<pbb> go has a big runtime component
<clever> is the kexec in go as well? or are you still shelling out to ELF kexec?
<pbb> I think it's doing the syscall directly from go
<samueldr> in my case it's mostly because I'm not familiar with either, and for the few steps taken with each, Rust seemed to be more my jam
<samueldr> nothing against though :)
<clever> pbb: that feels wrong, given how badly ive seen kexec break in the past...
<clever> pbb: which library are you using for it?
<samueldr> depending on how u-root works, it might be feasible to rely on u-root's userland tools, while having an app built in something else
<pbb> they are literally just doing the syscall
<samueldr> pbb: K20 pr K20 pro?
<pbb> samueldr: K20
<pbb> without pro
<samueldr> good, so davinci, I presume
<pbb> yes
<pbb> I started adding support in my fork
<clever> pbb: ah, but it looks like its also parsing the linux ELF file, and breaking it up into segments already
<pbb> 1) I don't know what some parameters in the device nix files are
<clever> pbb: that parsing stuff was once broken (due to hardening flags) with the kexec binary in nixos
<pbb> 2) the kernel fails to compile with the mobile nixos kernel builder
<samueldr> oh, btw, pbb, feel free to ping me (here) with Mobile NixOS issues, at worst I'll simply be busy and answer when I have the time
<clever> pbb: where is line 21's Load( called from?
<clever> pbb: oh, nice, github can answer that now
<samueldr> e.g. TWRP
<samueldr> but it's *highly* likely they're the same tissot and lavender
<pbb> how can I get them from a TWRP image?
<samueldr> if you nix-shell path/to/mobile-nixos, it'll open up a shell with a few tools
<samueldr> you'll get unpackbootimg
<samueldr> mkdir some-dir unpackbootimg -o some-dir -i twrp.img # IIRC
<clever> pbb: yep, thats all the logic i didnt want to re-implement in haskell, but go nut already did it in go, lol
<samueldr> mkdir some-dir ; unpackbootimg -o some-dir -i twrp.img # IIRC*
<samueldr> it'll print them to the console, and also dump a bunch of files in some-dir... among others, files containing those same values in printed
<clever> pbb: yep, it even has the trampoline, which may be tricky to get into the haskell binary
<samueldr> the "soc" value, is the name of the SoC, as per the OEM... Qualcomm are a bit annoying with those names
<pbb> thanks, got those values :)
<pbb> should I copy the cmdline 1:1?
<samueldr> as of right now, yes
<samueldr> we might end up not using those at all
<samueldr> I'm still gleaning information :)
<samueldr> (speaking of... I might have bought myself a new personal cellphone... so one more bit of data soon)
<samueldr> so, going back to SOC name
<clever> samueldr: and here's the fun part, can you get rust to compile this? :P
<samueldr> I go with what GSM Arena uses, which is likely fun
<pbb> I went with what I saw in the repository names for my device
<clever> pbb: oh, even worse, u-root will only work on x86-64, it wont work on i686, it wont work on arm
<samueldr> here it would be SDM730
<pbb> yes that's what I chose too
<samueldr> they started dropping "msm" and using "sdm" instead
<clever> pbb: you need to fill in the missing trampolines for other arches
<samueldr> great
<samueldr> clever: that's only if you implement like "real" booting, right?
<samueldr> kexec wouldn't need ASM?
<clever> samueldr: kexec always needs that asm trampline
<samueldr> right, but I can use another userland kexec :)
<clever> yeah
<pbb> yes they also have a wrapper for kexec-tools in u-root
<clever> you can just ship the ELF binary nixpkgs already builds
<samueldr> I wouldn't necessarily want to build a userland, but rather prefer using a known good userland
<samueldr> and later leave crazy peeps like... you clever... do fun stuff :)
<clever> framebuffer seems like a fairly simple thing to handle from haskell code
<pbb> ok next thing for me is to get the kernel to compile
<samueldr> my sanity is not worth dealing with implementing kexec in addition to working with phones!
<samueldr> pbb: have you got a config file?
<pbb> yes
<clever> samueldr: oh, since you already have nixos booting, what happens if you just `systemctl kexec`
<clever> samueldr: that should just tell systemd to reboot via kexec
<clever> samueldr: if that works, youll have a decent amount of info
<samueldr> clever: don't know yet, but I figure since the kernels aren't built with kexec on (yet) it might fail?
<pbb> and a source tree from lineageos 16.0
<pbb> but it's not compiling
<clever> samueldr: how it fails will answer a lot about where we need to go next
<samueldr> pbb: can you share the output?
<pbb> I will try it again tomorrow and save the log
<pbb> I tried on the weekend but didn't save the output unfortunately
<samueldr> do you remember what it looked like?
<pbb> errors, many errors
<samueldr> my build machine is currently tied into doing non-reproducible build of lineageos, in preparation for my next phone... in waiting for an actually worthier OS :)
<samueldr> hmmm
<samueldr> ah, it's still downloading, not building
* samueldr sneaks in a quick build
<pbb> I always use the lineage4microg docker cicd container for building lineageos
<pbb> it should be kinda reproducible
<samueldr> I'm using phhusson's treble experiments's docker thingy
<samueldr> yeah, kinda
<samueldr> since the device I'm going to use it on can use GSIs, and AFAIK has not had a "proper" port
<samueldr> fun thing: I'm 99% sure I can use a mobile-nixos built kernel with GSIs, as long as I keep the config stock~ish
<pbb> hmmmm
<pbb> I am not so sure about that
<clever> [374/2315] Generating radv_gfx10_format_table.h with a meson_exe.py custom command.lib.cpp.o'.and_wayland-drm_wayland-drm-protocol.c.o'.ocol.c.o'.
<pbb> depends I guess
<clever> this bisect is going to take a while
<samueldr> pbb: I was booting MIUI accidentally with my first builds :)
<pbb> on my phone the kernel source is the thing keeping developers from building a non-GSI android 10 rom
<pbb> I'm using a GSI too at the moment, because of that
<samueldr> but never tried using it... maybe something is still missing
<pbb> samueldr: lol ok, but you based your mobile-nixos image on the kernel source that would be used for this android version, right?
<pbb> because there is no kernel source for my device with android 10
<samueldr> the xiaomi open source tree, as released by xiaomi
<samueldr> with their config
<pbb> ok then it makes sense that it works if the versions match
<samueldr> though I guess it was missing the QACLD stuff, not 100% sure yet
<pbb> but I doubt the android 10 GSIs would work well with the android 9 kernel xiaomi released for davinci
<samueldr> pbb: is your source tree up to date?
<pbb> samueldr: it's pretty up-to-date with upstream linux, yes
<samueldr> sorry, your mobile-nixos one :)
<samueldr> seemed to be missing the sdm730 option
<pbb> hmm it should be up to date
<samueldr> I figure that's not the issue you had, and that the kernel *did* start to be built
<pbb> yes it did
<pbb> ah yeah I didn't commit everything before I shut off that build machine I was using
<samueldr> :)
<samueldr> that repo thing is really eating at my bandwidth
<pbb> samueldr: I fixed that thing
<pbb> kernel now starts building if you pull again
<samueldr> (I side-stepped the issue)
<pbb> ok
<pbb> the funny thing is those offset parameters were all correct, I copied them from tissot
<samueldr> I was mainly verifying it wasn't *that* issue...
<pbb> no it wasn't
<samueldr> yeah, most of them are shared in qualcomm devices of a same "vintage"
<samueldr> and for a couple generations even
<samueldr> unsurprisingly
<pbb> ok I've started the build, even though I could only test with cross-compiling for now without a proper arm build machine
<pbb> now it's building the toolchain I guess
<pbb> we'll see tomorrow
<samueldr> all stage-1s should build with cross-compilation, as a goal to Mobile NixOS
<samueldr> in fact it wouldn't surprise me that OEM downstream kernels fail to build with native builds
<pbb> oh
ryantrinkle has joined #nixos-aarch64
<samueldr> no reason, plain cynicism :)
<pbb> makes sense, they probably always cross-compile
<clever> related, the fork of gcc i was using for VC4 cross compile
<samueldr> most definitely do
<clever> it only builds with out of tree builds
<clever> when you ../gcc/configure
<clever> whoever forked it to add vc4, only built it that way, and broke in-tree builds
<pbb> what the f I'm getting a hash mismatch in correct-pwent-parsing-issue-and-resulting-build.patch for glibc
<clever> pbb: i think i saw that in #nixos already, the patch was changed ages ago, but due to binary cache reasons, it wasnt re-fetching
<pbb> hm I see
<pbb> and in my case one of my machines (the coordinating one) has the old version in the store, but the other (building) one doesn't
<pbb> so either way I get a hash mismatch
<pbb> I guess
<pbb> no that doesn't make sense
<pbb> I don't know
<pbb> enough for today, I'll try to build again tomorrow
ryantrinkle has quit [Ping timeout: 265 seconds]
<samueldr> I had a hash mismatch too
ryantrinkle has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 250 seconds]
h0m1 has joined #nixos-aarch64
<samueldr> looking at it idly while doing misc. stuff
<samueldr> it looks like that (at least for the xiaomi source) it might not compile at all with gcc
<samueldr> from the OEM kernel
<samueldr> Linux version 4.14.83-perf+ (builder@c4-miui-ota-bd44.bj) (clang version 6.0.9 for Android NDK) #1 SMP PREEMPT Sun Oct 27 22:42:46 CST 2019
<samueldr> looking to see if a clang-based builder is trivial
<samueldr> it *may* end up almost a requirement anyway since AFAIK the official android tooling is all based on clang
orivej has joined #nixos-aarch64
<clever> samueldr: https://www.sparkfun.com/products/15809 a 4mbyte (32mbit) spi flash chip... 8 times bigger then what the rpi4 has...
<samueldr> yeah
<clever> samueldr: i wonder what the boot rom will do if the chip is bigger then expected...
<samueldr> I think the series goes up to 16MB, not sure though
<samueldr> ugh, had to pick the wrong raspberry pi to check
<clever> -rw-r--r-- 1 clever users 2.8M Nov 2 18:04 start.elf
<clever> thats big enough to hold the entire gpu firmware, and still have some space to spare
<samueldr> I don't see the spi flash chip on the 4
<samueldr> clever: doesn't say where it is :)
<samueldr> nothing on that side is a an SPI chip
<clever> samueldr: what are the 3 things between the audio and usb controller?
<samueldr> that's what I was about to check
<samueldr> written so smol
<samueldr> about to test that phone's manual focus ability :)
<clever> 2 of them have 8 pins each, so those are likely
<clever> samueldr: not enough focus on that image, maybe you can do better?
<samueldr> how's that?
<clever> much better!
<clever> compare to what i just linked, and youll see how drastic the diff is
<samueldr> I can do better, it looked better on display
<samueldr> yeah
<clever> samueldr: is the topleft chip 1H909?
<clever> google cant find a single thing on those chips
<clever> samueldr: checking the schematic, i can see a 6pin chip connected to the AV jack
<clever> and i do see a 6pin thing, with an oddly symetrical set of parts around it, on your images
<samueldr> the one with what looks like three caps going to like Z167?
<clever> yeah
<clever> thats something to do with audio
<clever> oh
<clever> its taking a pwm square wave, and running it thru a low pass filter, to turn it into analog
<clever> the chip is a pair of buffers, to drive things and prevent backflow
<clever> and the caps then knock off the high freq
<clever> but the 8 pin things right next to it, arent shown on the schematic
<clever> so they arent involved in audio?
<samueldr> couldn't find results about those numbers
<clever> same
<clever> samueldr: do you have an ohm meter?
<clever> 176 flashrom -p "linux_spi:dev=/dev/spidev0.0,spispeed=${SPI_SPEED}" -w "${TMP_EEPROM_IMAGE}" || die "flashrom EEPROM update failed"
<samueldr> I wouldn't really want to poke around with it :)
<clever> 169 dtoverlay spi-gpio40-45
<clever> 171 modprobe spi-bcm2835
<clever> samueldr: its using regular old flashrom on the spi device, to update the firmware
<samueldr> yeah
<clever> samueldr: so the chip is likely wired to the spi pins on the gpio header?
<samueldr> I'm beginning to think it could be on-die
<clever> oh wait
<clever> 163 # Bootloader EEPROM chip-select is muxed with audio pin so disable audio
<clever> 164 # LDO first to avoid sending noise to analog audio.
<clever> 165 "${VCMAILBOX}" 0x00030056 4 4 0 > /dev/null || true
<clever> 166 dtparam audio=off
<clever> they put the bloody chip select pin on one of the audio channels, lol
<clever> thats a strong sign that the spi is near the audio stuff
<clever> 168 # Switch the SPI pins to boot EEPROM
<clever> 169 dtoverlay spi-gpio40-45
<clever> ./boot/overlays/spi-gpio40-45.dtbo
<clever> [nix-shell:~/apps/rpi/firmware]$ dtc -I dtb -O dts boot/overlays/spi-gpio40-45.dtbo
<clever> cs-gpios = <0xffffffff 0x2b 0x01 0xffffffff 0x2c 0x01 0xffffffff 0x2d 0x01>;
<clever> brcm,pins = <0x2d 0x2c 0x2b>;
<clever> brcm,pins = <0x28 0x29 0x2a>;
<clever> its clearly doing something with gpio 40 to 45
<clever> samueldr: dang, those arent on the gpio header, though it makes sense why they may keep them safe
<clever> gpio 40/41/42 (0x28/0x29/2a) are either PWM0/PWM1/GPCLK1 or SPI2_MISO/SPI2_MOSI/SPI2/SCLK
<clever> 43/44/45 are 3 chip enable lines, for spi2, CE0/CE1/CE2
<clever> and flashrom is targeting 0 i think?
<clever> so gpio43 somehow leads to the spi flash
<samueldr> oops
<clever> and the data in/out, are on the headphone jack
<samueldr> I was taking slo-mo video of the board
<samueldr> the quality was terrible
<clever> samueldr: if i'm reading this right, you might HEAR the boot code, if you have headphones plugged in
<samueldr> looked closely with the camera
<samueldr> can't see anything obviou
<samueldr> obvious*
<samueldr> oh!
<samueldr> using flashrom it might be possible to identify the brand?
<clever> samueldr: likely, but youll need to do the dtoverlay and mailbox stuff to enable those pins
<clever> samueldr: also try hooking up some headphones to see if you can hear flashrom dumping it
<samueldr> I don't really have the setup to
<clever> this is still some decent progress, i should order my rpi4 before i forget again, lol
<clever> just probing those 2 chips with a scope while i flashrom it should reveal the truth
<clever> oh, interesting!
<clever> the schematic for the av jack, says both pwm1 and mosi, for the left audio channel!
<clever> that agrees with the elinux wiki and what i found via overlays
<clever> it definitely looks like they are reusing the left/right audio channels, for the data
<clever> wait....
<samueldr> could maybe be this chip
<clever> 163 # Bootloader EEPROM chip-select is muxed with audio pin so disable audio
<clever> 164 # LDO first to avoid sending noise to analog audio.
<samueldr> though unlikely
<samueldr> too many legs
<clever> which LDO are they refering to...
<samueldr> pretty sure you need only one
<samueldr> eight&
<samueldr> *
<clever> the 6pin thing is on a 3v3_aud line
<clever> which is tied to LDO_OUT!
<clever> they are specifically cutting power to that 6-pin audio boosting chip
<clever> before they spi away
<clever> so you wont hear the noise!
<samueldr> how likely is it that those two similar 8-legged chips are both SPI flashes
<samueldr> there's one for the USB controller too, AFAIUI
<clever> that pretty much confirms it, they are doing the data on audio left/right
<samueldr> and it's next to the audio stuff
<clever> samueldr: the usb controller firmware is updated with a static ELF binary, rather then flashrom
<clever> [clever@amd-nixos:~/apps/rpi/rpi-eeprom]$ file vl805
<clever> vl805: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=7b7aaa0a89aaa7d37a1d95b1acd980fd286d80af, stripped
<clever> i suspect its in the usb controller itself, and updated over pci
<samueldr> right, but that doesn't tell anything about the location of its firmware :)
<samueldr> or alternatively
<clever> oh
<samueldr> the pi has two firmware chips
<clever> it could have its own spi flash, tied directly to the usb controller
<clever> samueldr: isnt that thing just to the north, the usb controller?
<samueldr> the heatsink is on top of the VLI chip
<samueldr> so yeah
<clever> and i see one of the legs of the top most chip, going directly to the usb controller
<samueldr> that video I mage of myself just moving the raspberry pi slowly is really good
<samueldr> I made*
<samueldr> yeah
<samueldr> two legs
<samueldr> most likely pathing under
<clever> i think 1h909 is the usb firmware, which you update over pci
<samueldr> to the fifth from the bottom on the left
<clever> and the 4h908 is the bootcode.bin firmware
<samueldr> that would be my assumptions currently
<samueldr> too
<clever> and those part numbers are pretty close...
<clever> The Raspberry Pi 4 has an SPI-attached EEPROM (4MBits/512KB), which
<samueldr> do you know what we've done?
<clever> -rw-r--r-- 1 clever users 95K Nov 2 20:27 vl805-00013701.bin
<clever> 760
<clever> > 95 * 8
<{^_^}> 760
<samueldr> we might have either confirmed the info or created confusion by being the only search result about that
<clever> the vl805 firmware is ~1mbit
<samueldr> (whenever my logs are indexed next)
<clever> while the rpi firmware is 4mbit
<clever> the usb firmware chip starts with a 1h, the rpi chip with a 4h
<samueldr> ooh
<samueldr> my mom told me about your kind of people
<samueldr> clever people
<clever> lol
<samueldr> they're good to be in company of :)
<clever> those part numbers pretty much confirm things
<samueldr> there's good correlation
<clever> even if we cant read them, lol
<samueldr> 1h909, 4h908, I'm sure of
<clever> and this chip is 32mbit, and has a 32 in its number
<samueldr> yeah, but vendors all have their scheme
<samueldr> like IIRC Q is for QFN here
<samueldr> (I read about that series since it's frequent on motherboards)
<samueldr> (and present on the chromebit, in another package)
<samueldr> I was wrong
<clever> every vendor may do it differently
<samueldr> yeah
<clever> flashrom may reveal the vendor and part#
<samueldr> might not look like so, with the picture blown up on your monitor
<samueldr> but that part is ₛₘₒₗ
<samueldr> ˢᵐᵒˡ even
<clever> error, unrenderable glyphs!
<clever> lol
<clever> i can only see the s and l from the 2nd one
<clever> the rest are just boxes
<samueldr> 3mm on their narrow axis
<clever> and somebody else has already soldered the pads on the usb chip, which are even closer
<samueldr> calipers won't reach on their larger
<samueldr> would say about 6mm
<clever> this guy just jumpered the pcie lanes to the usb3.0 lanes
<clever> oh, but now i can see where the usb firmware chip goes!
<clever> the one i couldnt confirm, is just going into the side of the pad
<samueldr> rotate the picture 180°
<clever> and the 2 others on the other side, also go directly into it, so thats 4 links
<clever> mosi miso cs clock, all accounted for!
<clever> and if i look at the same pins on the rpi firmware chip
<clever> i can see one of them goes directly to an audio channel on the boosted thing
<clever> thats definitely it
<samueldr> lol
<samueldr> I hadn't realized
<samueldr> there's a triangle on the board!
<samueldr> to help you orient the chip
<clever> 164 # LDO first to avoid sending noise to analog audio.
<clever> oh, this comment isnt saying noise to the chip
<clever> its literally, the noise i was asking you to listen to!
<samueldr> I won't
<clever> they turn off the audio amp, so you cant hear it
<samueldr> I'm betting there won't be
<clever> you would have to comment out that line of the script to hear the data
<clever> the script, for reference
<clever> 165 disables the audio amp, 166 tells the kernel to stop trying to route audio out the port
<clever> 169-171 configures the spi port to go towards the chip
<clever> 176 flashes it
<clever> then 178-180 undoes the setup, so audio will work once more
<samueldr> I guess that the VLI chip doesn't need to go through GPIO since it has its own ways
<clever> its directly wired to the usb controller, so you have to tell the usb chip to update its own flash, over the pci bus
<clever> which also means it might be at risk of bricking?
<clever> enless the reflash part is hard-wired into the chip
<clever> though, it must have a way to unbrick, how else did they program things at the factory?
<samueldr> magic!
<clever> pre-programmed spi chips are more expensive
<samueldr> don't let it out of the chip
<clever> samueldr: you can always put it back in, sparkfun had a product for that
<clever> samueldr: https://www.sparkfun.com/products/retired/10622 Magic Blue Smoke Refilling Kit
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever> samueldr: which country do you live in?
<samueldr> ...
<samueldr> is this a trick question? :)
<clever> nope
<samueldr> I'm in a neighbouring province!
<clever> ah
<clever> then youll have equal problems with out big nasty neighbor :P
<clever> america has export restrictions, on the bloody spi chip
<clever> Do you intend to sell or send these products to anyone in any of the following countries: Cuba, Iran, North Korea, Sudan, or Syria?*
<samueldr> ah, I was about to ask "nova scotia?" as a lark :)
<samueldr> sparkfun always has that question set
<clever> its only set on the rpi4 and the spi chip
<clever> the other products i'm ordering dont ask
<samueldr> well, I did order a raspberry pi zero from them
<samueldr> among other things
<clever> i had to answer this in email when i order an fpga a while back
<samueldr> do you get grossly overcharged by UPS?
<samueldr> or you use the more expensive USPS?
<clever> i have 4 major choices for shipping
<clever> usps, fedex, ups, or "economy"
<clever> and some have 2 tiers
<samueldr> maybe the order had restricted stuff, but each options were quite expensive
<samueldr> IIRC something like USPS being 20$, USPS 40$
<clever> "economy" is only $8, while the other ones go up to $60
<samueldr> oops, UPS being 20$, USPS 40$
<samueldr> but USPS/Canada Post can only charge 5$ for the service of doing the customs stuff
<samueldr> (in addition to the duties)
<samueldr> UPS charged me 52.89 of brokerage charges
<clever> i have had the surprise of paying those fees at the door once
<samueldr> that doesn't include the duty, taxes, and "other government charges" totalling 28.44!
zupo has joined #nixos-aarch64
<clever> Delivery Estimate: 1-4 Weeks
<samueldr> are you like... planning to hook that SPI chip to the board?
<clever> yeah
<samueldr> oof
<samueldr> are the voltages right?
<clever> 2.7V - 3.6V VCC
<clever> and the rpi is almost exclusively 3.3v
<samueldr> though otherwise I assume you're gonna use some tiny "magnet wire" to wire it
<clever> its just big enough to hold bootcode.bin and start.elf, with ~700kb to spare
<clever> how small can you make a uboot?
<samueldr> not sure
<clever> the other problem, is modifying bootcode.bin to actually look for start.elf in the spi chip
<clever> and modifying start.elf to look for uboot
<clever> the entire start.elf could be skipped if i port the open firmware
<samueldr> ~/.../rpitianocore/RPi3_UEFI_Firmware_v1.11 $ ls -lh RPI_EFI.fd
<samueldr> -rw-r--r-- 1 samuel users 2.0M Nov 19 13:39 RPI_EFI.fd
<clever> samueldr: oh, do we have datasheets for the vl805?
<samueldr> tianocore can fit in 2MiB
<samueldr> on sunxi u-boot with SPL is 6xxKiB IIRC
<samueldr> (frankly, if we can get tianocore it would be much better than u-boot)
<samueldr> so if, let's say, the back half of the SPI is available, it's likely
<samueldr> I wonder how big the rpi4 tianocore is
<samueldr> (not "will be", but "is" :))
<samueldr> though AFAIK the devs haven't distributed a binary of it yet
<clever> http://billauer.co.il/blog/2019/07/via-vl805-superspeed-pcie-linux/ "VIA VL805 USB 3.0 PCIe adapter: Forget about Linux"
<clever> thats weird, given that it now works in rasbian, lol
<samueldr> most likely they had help
<clever> samueldr: i'm having trouble finding a datasheet, which does imply an NDA was involved
<clever> http://labs.domipheus.com/blog/raspberry-pi-4-pci-express-it-actually-works-usb-sata-gpu/ "The VL805 datasheet is confidential which makes posting parts of it here tricky"
<clever> samueldr: boom!
<clever> and yep, spi pins in the right corner!
<samueldr> almost confirms the two chips
<samueldr> only because we don't *know* :)
<samueldr> ooh... it was linking with clang 7
<samueldr> tried a native build
<samueldr> failed
<samueldr> so a big thing we'll need is a working clangStdenv for cross-compilation
<samueldr> fails with clang_6, too, but still, it compiled
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
zupo has joined #nixos-aarch64
<samueldr> hmmm, forced the kernel to compile with gnarly hacks
<samueldr> with gcc
<samueldr> still has the same `dangerous relocation: unsupported relocati
<samueldr> on
<samueldr> when linking
<samueldr> "dangerous relocation: unsupported relocation"*
<samueldr> so it's not clang specific, and I'm now wondering whether it's because it would be linking with the same linker
<samueldr> what I can say for sure: that qualcomm code is a big mess :/
<samueldr> all in the qualcomm bits
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 252 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Ping timeout: 240 seconds]
Thra11 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
tilpner_ is now known as tilpner
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 245 seconds]
kai_w has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 240 seconds]
kai_w has quit [Quit: Konversation terminated!]
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has quit [Ping timeout: 276 seconds]
orivej has quit [Ping timeout: 265 seconds]