Thra11 has quit [Read error: Connection reset by peer]
Acou_Bass has joined #nixos-aarch64
v0|d has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
Thra11 has quit [Read error: Connection reset by peer]
Thra11 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
h0m1 has quit [Quit: WeeChat 2.6]
ris has quit [Ping timeout: 258 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 240 seconds]
<samueldr> wow, I greatly underestimated how much logging u-boot's SPL could do
<samueldr> still not at the first line of an error I'm trying to track, and > 3MB log
<samueldr> oh
<samueldr> it's actually not working
<samueldr> it's resetting in loop, that's why
aminechikhaoui has quit [Quit: The Lounge - https://thelounge.github.io]
aminechikhaoui has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 265 seconds]
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 268 seconds]
Thra11 has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
<craige> Finally got to flash that kernel I built on the way home for the blueline samueldr -> https://hydra.mcwhirter.io/build/1899
Acou_Bass has quit [Ping timeout: 245 seconds]
<craige> Good news is it doesn't crash. Bad news is it still has no frame buffer love but it's a promosing position to start from.
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 240 seconds]
<craige> I'm enjoying booting between slots though, with NixOS on slot a and android on slot b
Acou_Bass has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Ping timeout: 268 seconds]
tilpner has joined #nixos-aarch64
zupo has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 276 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 240 seconds]
h0m1 has joined #nixos-aarch64
ris has joined #nixos-aarch64
<samueldr> when the kernel will crash, it will switch to the other slot, craige
<samueldr> something to keep in mind
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
<craige> It never switched was handy but yeah, I'll keep that in mind. It's an interesting new world with these slots.
Acou_Bass has joined #nixos-aarch64
<craige> As a sidetrack, I got a LineageOS image that works.
<samueldr> nice
<samueldr> though yeah, the switching would also happen if we were trying to use slots A/B as a means for multi-boot
<samueldr> if the kernel was to somehow crash :/
<samueldr> though that must be wrong in some way
<samueldr> what if you update
<samueldr> boot
<samueldr> then two boots later it crashes
<samueldr> ... something must be available to flag it as "if it crashes, don't blame a bad slot"
* samueldr should look at ebay for pixel 2s
zupo has joined #nixos-aarch64
<clever> samueldr: that makes me wonder, the kexec crash kernel, could do a nixos rollback
<samueldr> we may not want a rollback on a simple crash
<samueldr> but rather a flag on successful boot
<clever> ive thought of that too with grub
<clever> it has a state file for saved default
<samueldr> in an ehanced generation thingy, `nixos-rebuild switch` would not switch the default, but only set the next (unverified) boot
<samueldr> yeah
<clever> so the boot entries can change the default when you trigger them
<clever> and then an activationScript can undo it
<samueldr> and then, once it reaches some target, likely display-manager for desktops, or something else, yeah
<clever> something else ive seen in some mobile devices
<clever> it runs a phone GUI normally
<clever> but if you dock it, it switches to a full desktop GUI
<samueldr> yeah
<samueldr> samsung dex
<samueldr> the most well-known implementation
<clever> so, mobile-nixos could swap between something and full-blown xfce, based on a switch
<samueldr> someone clever could implement it if they have the hardware with the right features
<samueldr> ;)
<clever> ;)
<samueldr> main issue is display out
<clever> in my pre-nixos days, i did also play with running several X's at once
<samueldr> which, to be fair, the only real option is eDP out via type-c
<samueldr> and that is not available on most phones
<clever> my kindle fire has mini-hdmi out
<clever> real hdmi, not jumbled in with the usb
<samueldr> yeah
<samueldr> I was thinking about new hardware
<clever> also, anoyingly, the kindle fire will route all audio over hdmi if plugged in
<clever> even if your using a dvi adapter to a pc monitor, with no speakers
<clever> so you have a choice between a big screen, or audio :P
<clever> i think the samsung galaxy s3, has hdmi on the usb connector, but its a special connector
<clever> that can also accept regular micro-usb
<samueldr> yeah, MHL I think so
<clever> thats the one
<samueldr> which has different implementations
<samueldr> one has more pins on micro-usb type plug
<samueldr> the other is just a normal micro-usb
<clever> the s3 has extra pins
<clever> clearly visible with a flashlight
<clever> ive also heard about apple's "design" and its problems
<clever> there just isnt enough reconfigurable pins on the lightning jack
<clever> so, they do h264 over usb, lol
<clever> and the dongle to do lightning->hdmi is basically just a raspberry pi
<clever> usb controller, hardware h264 decode, hdmi out
<clever> now you can get h264 compression artifacts on your web-pages when doing hdmi out :P
<samueldr> "just a raspberry pi" is a weird way to say "a full blown arm system that runs darwin"
<clever> if you where to get nixos on an iphone, then you basically dont even need gpu drivers at that point, to use the hdmi out
<clever> you can just generate an h264 stream, and shove it out the usb
<samueldr> I mean, you already could do that right now today with OTB usb devices
<samueldr> IIRC lightning has the same limitations in speed
<samueldr> OTG*
<clever> yeah
<samueldr> there's someone who's planned, hopefully started working, on making a usb dongle using an RPI0 as an HDMI out
<samueldr> using gadget mode
<clever> nice
<clever> and if you had a reverse lightning adapter, you could connect the apple hdmi adapter to a normal linux pc
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<t184256> I think you've reached the point where streaming h264 over Wi-Fi already makes more sense
<samueldr> wow, look at t184256 the fancy t184256 who's got wi-fi going on their mobile devices
<samueldr> ;)
<t184256> =D
<clever> t184256: now your just a chrome cast :P
<t184256> note: still saner than that 'cable'
<clever> my tv service is pretty whacky too
<clever> h264 over mpegts over rtp over multicast over 802.1q
<clever> with standard mpegts crypto needing a cam
<samueldr> hmm, refreshing and deepening my search for UART access for the pixel 2
<samueldr> looks like the pixel 3 might be using a suzyq in the end :/
<clever> samueldr: whats that?
<samueldr> but I'm having trouble finding info for the pixel 2 still
<samueldr> now I'm doubting my assumptions
<clever> samueldr: that reminds me, about the x86 usb debug stuff, heard of it?
<samueldr> I think so
<clever> for usb1/2, it was basically just a secondary mode in the usb controller
<clever> for the kernel side, its a dumb protocol like a uart, where you just shove bytes into a fifo and read bytes out
<clever> and then the usb controller deals with the complexity of the usb stack for you
* samueldr is pulling his hair out
<clever> but you need a special usb cable to link it to another pc
<samueldr> >> Android Serial Cable or Suzy-Q device
<clever> samueldr: you must have heard about how craige un-bricked the pixel 3 by now? and the fastboot version issues?
<samueldr> I think so yeah
<samueldr> YEASH
<samueldr> peeps at #grapheneos were quick to link to this
<samueldr> I have no idea why this page never was in the search results
<samueldr> I searched *so many* of the words in that page
<samueldr> it's just missing from the indexes of google, duckduckgo and bing
<samueldr> seriously getting tired of search engines not finding anything
<clever> samueldr: i remember the altavista and netscape navigator days, lol
<clever> samueldr: and related to what i'm doing in #nixos-dev, i was just thinking, for platforms like the rpi, you could hijack another core to implement a gdb server....
<clever> wait, that gives me another idea.....
<clever> samueldr: how complex would it be, to boot linux on a multi-core arm, and tell it "no touchy" for a certain arm core?
<samueldr> not sure it would strictly by no touchy
<samueldr> but there's a kernel param for that IIRC
<samueldr> and even runtime stuff for that
<clever> and what if you then ran some custom code on that core, that hijacks the usb interface, and runs a gdb server
<clever> so you could then read all ram, and pause execution of any core...
<samueldr> no idea how feasible it can be
<samueldr> oh, the cable can even be bought fully assembled and soldered
<samueldr> oh, not fully assembled, just a part of the assembly is assembled
<samueldr> specially pinging you since you're currently the one needing it the most :)
<samueldr> oh, I didn't realize, though this is neat
<samueldr> pixel devices apparently allow locking with a custom verified boot key
<clever> that sounds nice
<clever> i noticed that when unlocked, it has a 15 second warning/nag on every bootup
<samueldr> in theory should remove the nasty scary messages at boot
<samueldr> yeah
<clever> so you dont get exploited by a supply chain attack
<samueldr> yeah
<samueldr> some details about that
<clever> `toggle on the 'Enable OEM unlocking' setting. This requires internet access on devices with Google Play Services as part of Factory Reset Protection (FRP) for anti-theft protection`
<clever> craige: ahhh, i think its less about android being up to date, and more about the device phoning home, to ensure its not flagged as stolen
<samueldr> entirely makes sense too
<samueldr> (in an annoying way)
<clever> ive also heard horror stories about people doing a factory reset, then selling the phone
<clever> only for the buyer to discover, they need the google pw of the original owner, to finish the reinstall
<samueldr> yeah
<samueldr> FRP (and iCloud lock) are annoying
<samueldr> but at the same time, in our society, a necessity
<samueldr> reduces the value of stolen goods
<clever> samueldr: enless the ./flash-all.sh is updating the public keys for the trust root, i'm not sure what lock/unlock is doing, it seems to just be a boolean flag?
<samueldr> yeah, and it is also erasing the storage at the same time
<samueldr> so when you lock/unlock you lose the data
<clever> i think the `fastboot flashing unlock` already erases the data partition
<clever> samueldr: one area that needs careful research, is how does android pass the "enable oem unlocking" on to the bootloader?
<clever> samueldr: it would be interesting to toggle that from nixos too, but if you mess up, you might get it stuck into a state where you cant unlock and cant flash? or would it still accept flashing signed images??
<clever> and signed by who??
<samueldr> yeah, you're right, that this needs to be investigated
<samueldr> I was thinking about that
<samueldr> okay, so going from that docs for the UART cable, I have everything on hand, and it's going to be trivial to implement
<clever> i assume the fastboot source must be on a public google repo?
<samueldr> pixel 2 ordered... should arrive by the 7th
<samueldr> clever: search for ABL on codeaurora
<samueldr> or
<samueldr> wait until I give you this URL
<samueldr> ABL is the "new" android bootloader
<samueldr> for qualcomm devices based on XBL, which is Qualcomm's UEFI
<samueldr> though, as you can see, ABL is based on EDK2, so strongly suggests XBL is too
<clever> crazy idea, what would it take to port ABL to the rpi? or to emulate ABL in qemu? for testing purposes
<samueldr> clever: likely not much, considering EDK2 / TianoCore already is ported to it
<samueldr> well, rpi3
<samueldr> well, same for QEMU
<samueldr> though, not sure about all that
<samueldr> wondering if the android emulators (from the SDK) use a full boot or boot the kernels / systems directly
<clever> in the old days (before i got into android), the "emulators" where much more like the ios simulator
<clever> it was just an x86 dalvik interpreter, that used normal gui libraries to render to a "screen" (aka, a window)
<samueldr> I don't remember them being that way ever
<clever> thats how old it was :P
<clever> they switched over to running full linux+android in qemu
<samueldr> and I'm speaking about 2.0 era memories
<clever> ive only heard rumors of that method, and never actually seen it
<clever> the ios simulator is similar, its x86 libraries, that implement the same api as ios, and you can compile your ios app to run under x86 darwin
<samueldr> yeah, the iOS simulator is that
<clever> and at that point, its just a "normal" darwin app that uses a weird gui framework
<samueldr> and there's no real emulator
<samueldr> so you end up with weirdness for fancy stuff
<clever> the old android simulator just saves you from having to make 2 compiles, by having dalvik be a middle-man that the target already ran
ryantrinkle has joined #nixos-aarch64
<samueldr> as you can see, same person than on my last link :)
<clever> heh, nice
<samueldr> that's also the person that started the postmarketOS port for the Pixel 3
<clever> samueldr: oh yeah, and i still want to see an xnu based nixos
<clever> samueldr: xnu is open-source, how hard can it be to boot something nix generated, that is fully open source?
<samueldr> puredarwin might be a thing to look at
<samueldr> though it looks like parts of it have been closed down a bit more
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
Thra11 has quit [Ping timeout: 240 seconds]
Thra11 has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
gchristensen has quit [Quit: WeeChat 2.4]
{^_^} has quit [Remote host closed the connection]
gchristensen has joined #nixos-aarch64
{^_^} has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<samueldr> hmmm
<samueldr> apparently network boot has been added in a recent update to the rpi4
<gchristensen> !
<samueldr> (as expected)
<samueldr> they did say it was coming
* samueldr is looking for upstream docs and confirmation
<samueldr> well... downstream
<samueldr> that's not it
<samueldr> 2019-09-23
<samueldr> love how the docs still say network boot is coming soon
<samueldr> so apparently this also reduces the needed power consumption
<samueldr> so can be used from a usb port
<samueldr> and thus useful as a usb gadget
orivej has quit [Ping timeout: 264 seconds]
Thra11 has quit [Ping timeout: 268 seconds]
<clever> samueldr: nice
<samueldr> nothing new, really, considering other raspis could do that
<samueldr> but really nice nontheless to get the four onboard
<clever> the config is likely going to be better too
<samueldr> in theory, with the previously mentioned display thingy, and the two hdmi 4k outputs
<clever> previously, it was enabled with a fuse
<samueldr> yes
<samueldr> you could maybe get an (usb 2.0) display
<clever> and now that they have spi flash, fixing bugs should also be better
<samueldr> well, two displays
<samueldr> clever: yeah, that's how it happens
<samueldr> though annoying they put such a small spi flash
<samueldr> so no way to put u-boot or tianocore in there
<samueldr> speaking of
<samueldr> tianocore does already work
<samueldr> but no usb out of the type-a ports
<clever> also, i have the vc4 toolchain working in nixpkgs
<samueldr> yeah, saw the chatter in #nixos-dev
<samueldr> that's nice
Thra11 has joined #nixos-aarch64
<clever> currently, its stick at 9000 baud
<samueldr> now, write us some good vc4 widgets and watnots
<clever> stuck*
<samueldr> :)
<clever> how big is a typical uboot?
<samueldr> several hundred kilobytes AFAICT
<clever> the spi chip is 512kbyte
<clever> and an old bootcode.bin is ~52kb
<samueldr> ah, was about to say "but it still has to host the boot code"
<samueldr> not sure about the new one
<clever> -rw-r--r-- 1 clever users 2.8M Nov 2 18:04 /home/clever/apps/rpi/firmware/boot/start.elf
<clever> this is your biggest problem
<clever> under the broadcom firmware, you must load start.elf before linux
<samueldr> anyways, the raspberry pi foundation skimping again
tilpner has quit [Quit: tilpner]
<samueldr> (though I don't know for sure, maybe there are other reasons it wouldn't work)
<clever> oh, thats a whole new github repo for the spi flash
<samueldr> yeah
<clever> modprobe spidev
<clever> modprobe spi-bcm2835
<clever> looks like they are using the standard spi interface in linux to talk to it
<clever> flashrom -p "linux_spi:dev=/dev/spidev0.0,spispeed=${SPI_SPEED}" -w "${TMP_EEPROM_IMAGE}" || die "flashrom EEPROM update failed"
<clever> nice!, plain old flashrom!
<clever> so you can also use that to dump the current spi flash
<samueldr> nice, now give us enough space for a u-boot :3
<clever> in theory, you can just replace the chip with a bigger one
<clever> and use recovery.bin to make it bootable again
<clever> oh, interesting, what is vl805.....
<samueldr> the usb 3 chip
<clever> it has its own firmware
<clever> how big is that? .....
<samueldr> don't know
<clever> the official image is 94kb
<clever> [clever@amd-nixos:~/apps/rpi/rpi-eeprom]$ ./vl805 --help
<clever> bash: ./vl805: cannot execute binary file: Exec format error
<clever> samueldr: now what? lol
<clever> oh wait, duh
<clever> its an arm binary! lol
<samueldr> clever@_amd_-nixos
<clever> yeah, lol
<samueldr> you're even reminded of that!
<clever> i saw static and thought all nixos related issues would be gone
<clever> and didnt think of the arch :P
<clever> samueldr: looks like the VC4 is heavily vector based like i heard before
<clever> samueldr: it has an 64x64 2d matrix, of 8bit cells, that can be operated on as 8bit 16bit or 32bit values, and a single opcode can operate on 16 values at once, in either a row or column
<clever> samueldr: and it can repeat that opcode up to 64 times
<samueldr> hm, no idea what to make of that :)
<clever> samueldr: its heavily geared towards repeating a math operation on an array of data in bulk
<samueldr> like, gpu stuff I guess?
<clever> yeah
<samueldr> or even Video stuff
<clever> less 3d stuff, and more general graphics and maybe video decode
<samueldr> most probably video decode
<samueldr> considering its original purpose
<clever> ive heard that it also has hardware decode
<clever> so i'm not sure how much is implemented in vc4 vector ops, and how much is in actual hardware