<colemickens>
Say no more, I'm trying to figure out wth I was thinking again.
<samueldr>
it could have broke since then!
<colemickens>
we'll see, but I didn't even /look/ at my sway config soooo
<samueldr>
oh
* samueldr
preps a 5.9-rc3 build
<samueldr>
while I'm thinking of it
<samueldr>
though it'll be done in ~3 hours :/
<colemickens>
yeah, when I use the keybinding I defined it works great
<colemickens>
Its been months since I've used a laptop, guess I forgot.
<samueldr>
I never really needed a laptop since I got the damned machine
<samueldr>
so I don't even really know if it's a good laptop for laptop use cases!
<colemickens>
I am lucky to have a patio right now. It's a big relief to be able to go out there for a few hours from my mancave/den/office/"area".
<colemickens>
currently the PBP is nicely meeting expectations/needs for a firefox/termite thin-ish client machine.
t184256 has left #nixos-aarch64 ["Error from remote client"]
<samueldr>
hopefully an SoC vendor that's friendly to pine64-like integrators has something much more powerful for "soon"
t184256 has joined #nixos-aarch64
<samueldr>
but AFAIK there's nothing of the sort coming :/
<samueldr>
(I might not know that much though)
<colemickens>
samueldr: so... ALL last year, there was so much hype about the incoming wave of Windows ARM laptops this year and then.... ?
<samueldr>
oh, they're not from friendly SoC makers
<samueldr>
see, they're qualcomm machines
<colemickens>
Oh I didn't even realize any had actually dropped. I thought maybe Windows/ARM stuff just got quietly pushed back again.
<samueldr>
nah, it's there to die from being "useless" according to most tech reviewers
<samueldr>
see, dying the original death of the chromebooks
* colemickens
nods
<samueldr>
people still think chromebooks are useless!
<colemickens>
my dad sent me a pic of my cr-48 last night and asked if it was collectable yet
<samueldr>
does it collect dust?
<samueldr>
then yes
<samueldr>
(that's literally a bad joke)
<colemickens>
-_-
<samueldr>
I don't know that it'll ever be collectable, I think cr-48 had quite a big run
<samueldr>
and it's not that special?
<simpson>
I'm not sure if I have any Chromebooks left. They just broke down, one way or another, and didn't have the horsepower for staying up to date.
<samueldr>
simpson: don't misunderstand what I mean :)
<samueldr>
what I mean is that "review authorities" can kill a device or a company by causing their wishes to happen
<simpson>
samueldr: Oh, don't misunderstand me either. I have a strange love for the stupid little things; I used to work on them, and I remember having like a half-dozen on my desk at work.
<samueldr>
nice
<simpson>
Ha, yeah, I remember one of my personal Chromebooks getting updated, and then the update was an EOL build, and something about it broke the ability to to Developer stuff.
<samueldr>
like blackberry just before they scrambled to android... where they had their own ecosystem that was (and is still!) extremely secure
<samueldr>
:/ that's weird though
<samueldr>
only issue I had with a chrome-based device is a spicy pillow
<samueldr>
the machine still works fine, as long as it's tethered to the grid
<samueldr>
(the pillow is not near my house anymore)
<colemickens>
I rocked the first two Google Chromebook Pixels as dailydrivers with nixos. They were sweet devices. The latter one, two usb-c, two usb-a, hires 3:2 display, I wish I hadn't given it away...
<samueldr>
:o
juliosueiras has joined #nixos-aarch64
<samueldr>
the fancy chromeos devices are generally always good machines
<samueldr>
AFAIUI the hw team at google just makes what they want to use for those :)
<colemickens>
It's even sadder, the one I gave away runs UEFI+Win10 haha
<colemickens>
oh well, I was happy to save someone a purchase and extend some HW life :P
<samueldr>
I'm just waiting for those geeks to make a good ryzen-based premium chromebook next, hopefully
<samueldr>
(in addition to something nice and ARM, but that seems less likely to be a premium chromebook)
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<juliosueiras>
hi, I just receive the august pinephone today, does mobile-nixos pinephone braveheart in the device list is compatible with it?
<samueldr>
it should be
<samueldr>
it probably should lose the braveheart moniker from its codename
<juliosueiras>
nvm, the hash match even after change of revision
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
<juliosueiras>
going to try the blog method
<juliosueiras>
using NIXOS_SYSTEM.img method
<samueldr>
I have doubts that it'll change anything considering you should be getting change in the LED if the kernel booted
<samueldr>
note that I only have the braveheart on hand so it's kind of hard to confirm it works or not on other variants
<juliosueiras>
I don't mind ordering the serial cable, but the shipping cost and time it will take is going to be concern
<samueldr>
yeah
<samueldr>
my main assumption now is that somehow u-boot isn't pleased with something
<juliosueiras>
btw, is "beautiful" when shipping cost double
<juliosueiras>
for example , the pine phone
<juliosueiras>
cost 53 cad for customs tax
<samueldr>
that's not shipping, and is unfair characterize as such
<juliosueiras>
true
<samueldr>
though yeah it stings, but at the same time, it's your duty
<samueldr>
(heh, that pun was worth it)
<juliosueiras>
the 7$ serial cable + 33$ (for fastest) + customs tax
<samueldr>
you're unlikely to be hit with taxes at the customs for a 7$ item
<samueldr>
but whew, 33$ shipping :/
<samueldr>
do you have electronics hobby stores around you? you might be able to get everything for cheaper to make your own, maybe even help
<samueldr>
was that batch sent through what ended up being canada posts shipping again?
<juliosueiras>
not sure, since it was DHL who send me the email and messages
<samueldr>
at least CPC doesn't do bad things like UPS does; the people in brown add convenience fees that can end up being ~300% of what you actually pays in tax :(
<samueldr>
ah, then DHL
<samueldr>
DHL also adds some convenience fees
<samueldr>
and *that* is bull
<samueldr>
especially since they do it in a way where you are kind of forced to pay them even though it is illegal, you can self-declare in Canada
<samueldr>
I would assume DHL charged you ~10-15$ in convenience fees here
<samueldr>
when it's CPC, the nice thing is they are mandated by law to chareg a maximum of 5$ for that
<juliosueiras>
k, ordered the cable, cost me 54 CAD
<juliosueiras>
so 10 CAD -> 50 CAD
<juliosueiras>
.........
<juliosueiras>
since is either I ordered the cable , and find out the issue, or wait for someone else
<colemickens>
cool, just realized mine was "delivered yesterday in mailbox". <- it wasn't.
<samueldr>
there's at least one other person here on this channel getting one
<samueldr>
colemickens: :[
<colemickens>
last leg was.... you guessed it USPS!
knerten1 has joined #nixos-aarch64
<juliosueiras>
I assume that person is colemickens ?
<samueldr>
yes
<juliosueiras>
ah k, but yeah, I don't waiting for the cable, just finished packaging asciinema server last week to nixos module, and going to try localstack next
<juliosueiras>
so I can do that while waiting
<juliosueiras>
btw, asciinema server is ...... interesting (Clojure + Elixir + Nodejs)
knerten2 has quit [Ping timeout: 246 seconds]
<juliosueiras>
still red
<juliosueiras>
I guess I have to wait for colemickens or the cable
rajivr has joined #nixos-aarch64
* colemickens
looks at usps >_>
<juliosueiras>
I guess for now, I will just install nix to postmarketos
<juliosueiras>
in the mean while
<juliosueiras>
to play around
<samueldr>
yeah, always feel free to play with other distros
<juliosueiras>
nah, there is no looking back after using nixos
<samueldr>
oh, I know at one point you'll be on mobile nixos, thouhg I'm also saying that because right now it's definitely not close to being usable :)
<juliosueiras>
true, but at the same time, that is my plan to try to help out
<juliosueiras>
(at least on the packaging side)
<juliosueiras>
since is much more fun doing that
<juliosueiras>
lets be honest, most people who buy this type of phone at this stage is still for doing developing and tinkering
<colemickens>
oh if another distro works then more force just needs to be applied!
<samueldr>
it might take some time for me to *personally* work on that
<samueldr>
well, work on some of the features
<colemickens>
I'm dying to try out GloDroid.
<juliosueiras>
thanks
<samueldr>
colemickens: how come?
<samueldr>
colemickens: run it through robotnix!"
<samueldr>
or uh, build it through*
<colemickens>
samueldr: I could conceivably try to just use the Pinephone if I can boot into Android when I need to for certain apps but still stay in Linux most of the time.
<juliosueiras>
"The AOSP project requires at least 250GB free disk space as well as 16GB RAM." interesting
<samueldr>
juliosueiras: they're not kidding
<colemickens>
And then in theory pinephone proliferate and I need GloDroid less and less, but at least for me, that's a ways out
<samueldr>
colemickens: perfectly cromulent
<samueldr>
colemickens: though now I'm really dying to see it built through robotnix
<juliosueiras>
btw, the big project I'm working on is a full OpenStack Nix system
<juliosueiras>
(though is more of Docker(using Nix) with Nomad )
<colemickens>
I mean, what's not to love on this list of features...
zupo has joined #nixos-aarch64
<colemickens>
daniel runs it on pixel 3 xl! what! oh no, flashbacks of 2010-cole flashing nightly android roms
<samueldr>
hah
<samueldr>
in case you didn't know, daniel//rf[m] here
<samueldr>
if you want to basically run GrapheneOS, but built through Nix, AFAIUI it's the well-tested happy path
<colemickens>
this seems like a lot. my jaw is sort of on the floor.
<samueldr>
I had it running on a well-supported LineageOS device, once, but not tested really
<samueldr>
it failed on another one, but probably due to the dastardly lack of vendor blobs
<samueldr>
(and wasn't supported at the time)
<samueldr>
though it takes quite some time to build, iterating isn't the best
<samueldr>
oh, I don't remember which apk I tried, but IIRC you can also just dump apks to build into your rom if it fits your fancy... though that's not really useful if they don't have more features when installed as system
<samueldr>
oh, I think it was open camera, mostly as a test
<samueldr>
125.0 GiB [###### ] /lineageos
<samueldr>
output from ncdu
<samueldr>
(that's not handled through robotnix, just an ugly irreproducible build)
veleiro has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 265 seconds]
juliosueiras has quit [Remote host closed the connection]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
juliosueiras has quit [Remote host closed the connection]
alp_ has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
stiell has quit [Ping timeout: 258 seconds]
orivej has quit [Ping timeout: 240 seconds]
stiell has joined #nixos-aarch64
stiell has joined #nixos-aarch64
stiell has quit [Excess Flood]
stiell has joined #nixos-aarch64
stiell has quit [Excess Flood]
stiell has joined #nixos-aarch64
stiell has quit [Ping timeout: 264 seconds]
stiell has joined #nixos-aarch64
stiell has quit [Excess Flood]
stiell has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cript0nauta has quit [Remote host closed the connection]
wavirc22_ has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 260 seconds]
bennofs__ has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
bennofs_ has quit [Ping timeout: 256 seconds]
juliosueiras has quit [Remote host closed the connection]
cole-h has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<W1lkins>
Is it possible to use the raspberry pi camera with generic-extlinux-compatible? looking at the docs for it it mentions uboot but isn't that outdated?
<W1lkins>
right now I'm using generic-extlinux-compatible but but when i run vcgencmd get_camera it still says supported=0 detected=0
rajivr has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 258 seconds]
<clever>
W1lkins: to get supported=1, you must use start_x=1 in config.txt, which doesnt care which bootloader you use
<clever>
W1lkins: but to change detected, i think you need to fiddle with the cable, the non-x firmware can still detect a camera
<W1lkins>
this is the bottom of my /boot/config.txt
<W1lkins>
arm_64bit=1
<W1lkins>
# Boot in 64-bit mode.
<W1lkins>
kernel=u-boot-rpi.bin
<W1lkins>
gpu_mem=256
<W1lkins>
start_x=1
<clever>
df -h /boot/ ?
<clever>
does start_x.elf and fixup_x.dat exist on /boot/ ?
<W1lkins>
they do
<clever>
df -h /boot/ ?
<W1lkins>
do you want the single line output or the contents of boot?
<clever>
so thats not the config.txt the firmware reads
<clever>
you must edit the config.txt on the fat32 fs, not the one in /boot of an ext4 fs
<W1lkins>
did I miss some instructions during the setup
<W1lkins>
I don't seem to have that partition
<clever>
it cant boot without one
<clever>
ls -l /dev/disk/by-label/NIXOS_SD ?
<W1lkins>
NIXOS_SD -> ../../mmcblk0p2
<clever>
blkid /dev/mmcblk0p1
<W1lkins>
hmm, no output - exits with code 2
<W1lkins>
same for /dev/mmcblo0p2 though
<clever>
did you run it as root?
<W1lkins>
I mistyped the version as root, it's actually SEC_TYPE="msdos" LABEL_FATBOOT="FIRMWARE" LABEL="FIRMWARE" UUID="2178-694E" TYPE="vfat" PARTUUID="2178694e-01"
<clever>
then you do have a fat partition
<clever>
is it mounted?
<W1lkins>
doesn't look like it `mount | grep -i mmcblk` only returns the p2
<clever>
then mount it manually, and edit the right config.txt
<clever>
i think it goes on /firmware/
<W1lkins>
rebooting
<W1lkins>
okay both supported and detected=1 now, many thanks
<clever>
weird, i heard that detection worked without support
<W1lkins>
if I set this /firmware up to be created as part of my nixos config is there a way I can manage the start_x through nix?
<W1lkins>
I see boot.loader.raspberryPi.firmwareConfig in the config options
<W1lkins>
but the docs claim that will update /boot/config.txt, but mine would be /firmware/config.txt
<clever>
boot.loader.raspberryPi assumes that your mounting the fat32 to /boot and not using u-boot
<clever>
there are at least 3 conflicting bootloaders for the pi
<clever>
i am the author of one of the, heh
<clever>
but mine uses the open source firmware, so its "better"
alp has quit [Ping timeout: 272 seconds]
<clever>
(but lacks many features, including camera, and pi4 support)
<W1lkins>
:-) awesome - many thanks for helping me get it working
<danielrf[m]>
the "extended installation manual" looks to have enough information to get nixos running on that device
<samueldr>
i.MX6 IIRC
<samueldr>
it should be trivial enough
<samueldr>
but armv7l
<samueldr>
likely the RM2 is armv7l too
<samueldr>
though there are chances it's i.MX8, which would be aarch64
<danielrf[m]>
I'd love to have an basic eink laptop that can just ssh and run vim in direct sunlight
<danielrf[m]>
I think the RM2 is i.MX7
<samueldr>
was it not prohibitively expensive to get basically a toy, I would have tried to
<samueldr>
yeah, it's unconfirmed still
<danielrf[m]>
I had the RM1 earlier this year briefly but returned it when I saw the FCC submissions for the RM2
<danielrf[m]>
i'll probably preorder the RM2 and see if I can't make this work
<samueldr>
AFAIUI it's basically a standard boot flow, unverified
quinn has joined #nixos-aarch64
<sphalerite>
oh yeah… I have the rm1 but want to keep the stock OS working…
<sphalerite>
and am also afraid to try the SD slot hack
<Mic92>
samueldr: do you know which image I need for rock64? I tried nixos-sd-image-*-aarch64-linux.img, however it seems not to have the idbloader.img described in the wiki and it does not boot
<samueldr>
Mic92: the generic images ship with (only) the raspberry pi u-boot
<samueldr>
that is because their u-boot is more annoying to setup than the other
<samueldr>
you will alaways need to get the u-boot on the storage medium in some way if you don't have it somewhere else (e.g. SPI flash)
<samueldr>
(the raspberry pi needs an actual partition, which is not something that's really trivial to do after the fact)
<Mic92>
I verified that I connected uart console correctly with an older rock64 nix image that I used before uboot became part of nixpkgs
<samueldr>
Mic92: it's on the main partition now
<samueldr>
in the /boot/ folder
<Mic92>
at least the raspberry pi has a better out-of-the-box experience :(
<samueldr>
Mic92: while not nix-flavoured much, how would you feel if there was a tool (CLI/TUI/GUI/whatever) that would take the image and prep the bootloader for you?
<samueldr>
(it could be done through nix, but it has some drawbacks of copying big files around in the store)
<clever>
samueldr: it could be a nix expr that compiles a script, you then ./result /dev/sda, and it will impurely dd the img to the card, then impurely mutate it
<clever>
so it would automate all of the impure steps, and act directly on the card to save copies
<Mic92>
What clever suggest is probably easier to maintainer
<Mic92>
*maintain
<samueldr>
yeah, that's one of the approach I had in mind
Darkmatter66_ has quit [Ping timeout: 240 seconds]
<Mic92>
you just need the write abstraction for aarch64
<samueldr>
those build images, they don't re-use an image
<samueldr>
so if you don't have an aarch64 build machine you're SOL, right?
<samueldr>
(no, qemu binfmt is not a solution)
Darkmatter66 has joined #nixos-aarch64
<samueldr>
(it sometimes fails in weird ways)
<Mic92>
samueldr: mhm, what could work so is just: `nix-store -r $(nix-instantiate --system 'aarch64-linux' --eval --expr 'with import <nixpkgs> {}; "${ubootRock64}"' | sed 's/"//g')`
<clever>
Mic92: pretty sure you want { system = "..."; } not --system
<clever>
Mic92: --system will break things horribly when IFD gets into play or you try to actually build
<samueldr>
we can use pkgsCross for u-boot
<Mic92>
I can not verify that the rock64 bootloader is still working
<samueldr>
so a user can supply their own new shiny u-boot too
<clever>
Mic92: also, what you typed is basically just nix-build
<clever>
[clever@amd-nixos:~]$ nix-build '<nixpkgs>' -A ubootRock64 --argstr system aarch64-linux
<clever>
copying path '/nix/store/nqzm1gmyb7ip17cvilym872mygrks2rx-uboot-rock64-rk3328_defconfig-2020.07' from 'http://nas.localnet:8081'...
<Mic92>
fair enough
<Mic92>
ok. Now got a bootloader at least
<Mic92>
Why don't we enable openssh on aarch64?
<samueldr>
same reasoning as the installation image
<samueldr>
it's not "aarch64", it's the installation image profile
<Mic92>
but this is not a pc with mouse etc
<samueldr>
same could be said about a server
<samueldr>
default credentials are problematic
<Mic92>
not in my local network
<samueldr>
if you have a solution that doesn't rely on default credentials, please contribute
<clever>
raspbian gets around some of this by letting you drop magic files in /boot/ and they get copied all over the place on startup
<clever>
nixos-aws has user-data, which is just a configuration.nix string
<Mic92>
it should enable openssh even if no keys are installed
<clever>
and now flakes are a thing...
<Mic92>
it is easy to copy over passwd/ssh keys to the image, but not enabling openssh
<clever>
Mic92: i believe the installation profile allows ssh to root, even with a blank root pw
<clever>
ssh is enabled, but configured to not run on boot
<clever>
so you can run `passwd ; systemctl start sshd`
<Mic92>
clever: I am aware of this, but this makes it basically useless if you have no input devices
<Mic92>
this is just a poor default
<samueldr>
sure, then fix them, sorry if it's brash
<samueldr>
the trouble though is we're not making a spcialized aarch64 build, the aarch64 build is built on top of what's the usual setup
<samueldr>
tbf, the setup is not ideal either on non-sbc use
<Mic92>
Yeah, I could imagine to even add ssh keys via cmdline
<samueldr>
and technically, it's also unfair to say that the generic image is for use "without keyboard and mouse" as it is unfair to say the x86_64 iso is to install "with keyboard and mouse" :)
<samueldr>
my pinebook and my pinebook pro have keyboards!
<samueldr>
usb+hdmi hopefully works on the SBC end-users install to
<samueldr>
but yes, I do understand that a good subset of SBC end-users are used to interacting with them either through serial only, or through ssh only
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I just had a think, too bad we can't support depthcharge on the generic image at all
<samueldr>
first it'd have to be GPT
<samueldr>
and then the bootloader doesn't allow generations
<sphalerite>
is GPT not possible?
<clever>
the firmware for some boards lacks gpt support
<samueldr>
it makes things harder because of writing at offsets
<samueldr>
and impossible for amlogic
<samueldr>
since amlogic wants to use LBA1
<samueldr>
LBA1 is where the GPT lives
<clever>
altough....
<samueldr>
LBA0 is where the MBR lives
<clever>
gpt has a backup header at the end of the disk
<clever>
what if you operated purely on backup?
<samueldr>
from memory it wasn't asolution
zupo has joined #nixos-aarch64
<samueldr>
and also fails due to writing to a bigger medium
<samueldr>
you fit a 2.2GiB image on the 4GiB SD
<clever>
yeah
<samueldr>
the backup GPT is not at the end!
<sphalerite>
you try repartitioning your boot medium? boom no more boot for you
<clever>
sphalerite: that too, *doh*
<samueldr>
at the very least allwinner (possibly rockchip) would work
<clever>
hybrid gpt/mbr would also have that issue
<samueldr>
clever: yes, since hybrid is just GPT where the PMBR has partitions defined
<samueldr>
move the primary gpt table* and use the primary gpt header
<samueldr>
but amlogic ruins it
<clever>
pi seems to be about the only good one, it expects files, not magic offsets
<Mic92>
I think what I will add to the installer is to start the sshd if a ssh key exists
<clever>
Mic92: but it would still allow root with no pw
<Mic92>
in which case no empty password is allowed
<clever>
and you cant alter the sshd_config without a nixos-rebuild
<Mic92>
just have two sshd configurations
<clever>
and that will complicate the sshd.nix module
<samueldr>
clever: imo it's not a good solution either since it leaves the firmwarey bits on the main storage
<Mic92>
maybe sshd allows configuration via command line
<samueldr>
the only good solution is to keep all firmwarey bits on another storage
<Mic92>
or just remove the login with an empty password
<samueldr>
either rpmb for fixed eMMC, or preferrably an SPI flash chip or similar
<clever>
samueldr: the pi4 can almost do that, with its spi flash
<Mic92>
sshd takes options on the command line
<clever>
i did have an issue open about putting start4.elf onto external spi flash
<clever>
so you could make a pcb with spi flash and an rtc, and add uefi support
<clever>
but then other people began complaining about sd write cycle stuff in the github issue, and the thread got locked
<samueldr>
any boards that have SPI flash are +10 in my book
<samueldr>
IIRC all pine SBCs do
<clever>
until i can figure out the pi4 ddr4 controller, taking advantage of that SPI will be very difficult
<clever>
the current options are:
<clever>
* decompile, edit, recompile the firmware
<clever>
* patch the binary directly
<clever>
* RE it to death, and write a proper replacement
<clever>
ive been talking to a guy via email that is trying to do the binary patching, because bootcode.bin wont work if the SPI chip is the wrong size
<Mic92>
actually sshd does not allow root login with empty password
<Mic92>
so we can just enable it if an ssh key is present
<samueldr>
Mic92: or just enable it... since it wouldn't accept connections otherwise?
<Mic92>
yes
<samueldr>
just asked, and as far as it's known to an integrator of amlogic boards, LBA 01 only for amlogic...
<samueldr>
... but they also look at the boot* partitions on eMMC
<samueldr>
so if you have an eMMC (not SD) it's possible to install u-boot out of the way
<clever>
samueldr: it may help to investigate the address of the boot rom on those chips, dump it, and decompile
<clever>
when i did that for the pi4, i discovered that it had undocumented GPT support
<samueldr>
sure, but eh, it's not something I really know how to do right now
<samueldr>
and am rather busy with not doing that :)
<samueldr>
I believe it's how it's known for allwinner
<clever>
pop the .bin into ghidra, and set the load address to be the same as where you dumped it from
<clever>
ghidra is already in nixpkgs
<samueldr>
yeah
<samueldr>
but
<clever>
if youve done it right, c code pops back out
<samueldr>
how do I get the .bin?
<samueldr>
IIRC amlogic tries to be secure
<clever>
you could possibly dd it from /dev/mem
<clever>
if you know the address and its not protected
alp has quit [Ping timeout: 272 seconds]
juliosueiras has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
fooker has quit [Quit: WeeChat 2.8]
fooker has joined #nixos-aarch64
fooker has quit [Client Quit]
fooker has joined #nixos-aarch64
pbb has quit [Remote host closed the connection]
pbb has joined #nixos-aarch64
<samueldr>
:/ looks like on the PBP the 5.9 kernel will need more love to boot from the gfx-enabled u-boot
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
qyliss has quit [*.net *.split]
qyliss has joined #nixos-aarch64
<thefloweringash>
Mic92: looks like you got the answer, but I just wanted to quickly add that you can make a short-enough gpt with sfdisk by saying "first-lba: 64"
<samueldr>
why is it that seemingly no one installs the firmware to the SPI flash?
<samueldr>
in theory that makes it possible to boot bog standard UEFI that way
<samueldr>
in practice there may be caveats on some boards depending on implementation details, but it works for me on the allwinner-based pine a64-lts
<thefloweringash>
my excuse is documentation. dumping u-boot to this offset of a microSD card is documented everywhere. I didn't even know there was uefi for pine64
<samueldr>
u-boot has just enough uefi to boot
<samueldr>
I'll use my rk3399 board (roc-rk3399-pc) to prepare an good example for the wiki
<thefloweringash>
what do you tell nixos to use this?
<samueldr>
NixOS doesn't need to know
<samueldr>
I'm just now thinking that we'll need a bit of work on the u-boot derivation for this