<samueldr> hmm... might have to make the generation *actually* use make oldconfig rather than the menuconfig utility :/
<samueldr> though that means that using menuconfig will require normalization on newer kernels unless I figure out the actual subtlety that makes it see the non-cross compiler
cole-h has quit [Quit: Goodbye]
rajivr has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 260 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]
hpfr has quit [Ping timeout: 240 seconds]
yangm has quit [Ping timeout: 240 seconds]
Danct12[m] has quit [Ping timeout: 244 seconds]
blitzclone[m] has quit [Ping timeout: 244 seconds]
Ox4A6F has quit [Ping timeout: 244 seconds]
bbigras has quit [Ping timeout: 244 seconds]
Smith[m]1 has quit [Ping timeout: 244 seconds]
bqy has quit [Ping timeout: 244 seconds]
Ericson2314 has quit [Ping timeout: 244 seconds]
Dandellion has quit [Ping timeout: 244 seconds]
JJJollyjim has quit [Ping timeout: 240 seconds]
alexarice[m] has quit [Ping timeout: 244 seconds]
bennofs[m] has quit [Ping timeout: 244 seconds]
colemickens has quit [Ping timeout: 260 seconds]
smrtak[m] has quit [Ping timeout: 260 seconds]
kyren has quit [Ping timeout: 244 seconds]
cornu has quit [Ping timeout: 244 seconds]
colemickens has joined #nixos-aarch64
kyren has joined #nixos-aarch64
cornu has joined #nixos-aarch64
bqy has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
hpfr has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
blitzclone[m] has joined #nixos-aarch64
alexarice[m] has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
Dandellion has joined #nixos-aarch64
Smith[m]1 has joined #nixos-aarch64
smrtak[m] has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
<thefloweringash> follow up to my earlier question: it's a known bug that scopes aren't spliced (#68967)
<{^_^}> https://github.com/NixOS/nixpkgs/issues/68967 (by nspin, 1 year ago, open): Enhancing `lib.makeScope`
<thefloweringash> as for the "a -> b" operator, the one I don't understand is from the linked section of the manual on cross compilation. it's not nix source but trying to explain something.
bennofs[m] has quit [*.net *.split]
blitzclone[m] has quit [*.net *.split]
bbigras has quit [*.net *.split]
alunduil has quit [*.net *.split]
cstrahan has quit [*.net *.split]
angerman has quit [*.net *.split]
ky0ko has quit [*.net *.split]
kloenk has quit [*.net *.split]
greizgh_ has quit [*.net *.split]
angerman has joined #nixos-aarch64
greizgh has joined #nixos-aarch64
alunduil has joined #nixos-aarch64
kloenk has joined #nixos-aarch64
cstrahan has joined #nixos-aarch64
blitzclone[m] has joined #nixos-aarch64
ky0ko1 has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
patagonicus134 has joined #nixos-aarch64
patagonicus13 has quit [Ping timeout: 260 seconds]
patagonicus134 is now known as patagonicus13
knerten1 has joined #nixos-aarch64
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-aarch64
knerten has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
Dezgeg has quit [Ping timeout: 260 seconds]
Dezgeg has joined #nixos-aarch64
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 240 seconds]
<colemickens> dude wtf, apparently a bunch of Google-sourced Pixel3s can't be unlocked. https://issuetracker.google.com/issues/119628469
<colemickens> The one I had my eye on that is so cheap was bought from the Google Store, but it was a "US VZ" variant, so god only knows what I'll end up getting.
<samueldr> verizon variants can't be bootloader unlocked AFAIK
<samueldr> uh what, from RMAs, that's not good :|
<samueldr> maybe for pixel 2 too
<samueldr> that's just bad
<samueldr> poisoning the aftermarket well
<samueldr> though I see something that could be adding to the confusin
<samueldr> confusion*
<samueldr> I seem to recall craige having his toggle disabled at first boot and it needed to be updated first
<samueldr> though I read some people state they updated
alp has joined #nixos-aarch64
<samueldr> comment 138 has the most likely explanation https://issuetracker.google.com/issues/119628469#comment138
<Ke> now I get ERROR: Did not find a cmdline Flattened Device Tree while I changed "nothing"
<craige> There were a few hoops to be jumped through, downgrading to Android 9 was another.
<samueldr> that's odd, I don't remember that from nixcon
<samueldr> though yeah, your case was different
<samueldr> it was about a first-time setup
<craige> IIRC, Android 10 changed the partition layout.
<colemickens> actually reading comment 138 makes me so upset
<colemickens> assuming the person indeed does know what they're talking about
<samueldr> yeah
<samueldr> and it kind of makes sense considering what I know
<samueldr> it doesn't make sense to have a hardware difference for the VZW sku
<samueldr> so making it part of the initial internal setup is a "good" way to handle that
<samueldr> assuming your boot process is secure, this part is secure too
<samueldr> what seems to be missing is a way to "unvzwify" when they do RMA
<samueldr> because it sounds like, from the info gathered, that the IMEIs are being changed by the OEM (google)
<samueldr> I wonder if any other OEM has them bootloader-locked... though from what I've seen it seems it's only VZW
<samueldr> any other telco*
<clever> am i specializing things to the pi too far? lol
<clever> commit 57b578189b4b6c868dc17772e0655347a330e37e
<clever> Adding cryptodev-linux, and made openssl use it optionally.
<clever> I'm trying to get the CESA of the sheevaplug available to openssl.
<clever> but somebody else has already gone as far as i'm planning, 8 years ago, on a diff arm board...
<samueldr> as long as it provides standard interfaces in the OS, there's no ARM (heh) on doing that
<Ke> so how do people work to know, which memory addresses are safe to use in uboot
flo[m] has joined #nixos-aarch64
<Ke> google hit says my loadables might overlap in memory causing this
<Ke> super coolest uboots should probably handle this for me, but this has never been the case
<Ke> (should in normative sense)
<samueldr> the only time I've seen addresses overlapping, it was "trivial" to check by adding the starting address of either the kernel or the initramfs to its size
<samueldr> and then you'd see that it'd overlap with the other
<samueldr> whichever came first
alp has quit [Ping timeout: 272 seconds]
<Ke> we had an issue where kernel image was limited to 32M with no obvious reason, there was something there, but nothing visible with our skills
<samueldr> I don't have much experience about that though, luckily everything pretty much always worked for me
<Ke> well the lucky thing here is that u-boot code is readable, while horrible
<Ke> I can work these items out moderately easily
<Ke> bootm_argv[3] = env_get("fdt_addr_r");
<Ke> this is not specified, but I do not get error about it
justanotheruser has quit [Ping timeout: 244 seconds]
<Ke> snprintf(fdtfilefree, len, "%s%s%s%s%s%s",
<Ke> label->fdtdir, slash, f1, f2, f3, f4);
<Ke> is btw. how u-boot looks for the dtb based on the fdtdir
<Ke> maybe a bit spammy sorry
<Ke> thgouh my traditional limit is pasting more than 4 lines without pastebin is spam
<Ke> matrix bridge probably converted each character to one line on IRC though
<clever> samueldr: my rough understanding, is that if you add kernel support for any kind of crypto accel, and then you run opengl with `-engine afalg`, then it can take advantage of the crypto-accel in the kernel
<Ke> maybe I should send a patch to include these in the default env of my board
<clever> which can range from "better" software algos that know how to push the cpu to its limits, to hw crypto module drivers
<samueldr> Ke: matrix makes a funny link for pastes
<Ke> openssl?
<samueldr> and yeah, I know how u-boot looks for the FDT :)
<samueldr> the issue is how your board in u-boot defines its board name
<samueldr> which is sometimes hardcoded (e.g. sunxi boards were)
<samueldr> sometimes dynamic (iirc raspberry pi are dynamic)
<samueldr> and IIRC the way sunxi hardcodes it is different thant to how rockchip boards do
alp has joined #nixos-aarch64
<Ke> Skipping %s for failure retrieving fdt\n" would be the error I would get, if I did not have this
<Ke> I think bootm_argv[3] = env_get("fdt_addr_r");
<Ke> fails for me and this code path does not get done at all
<Ke> maybe I did manually set it earlier
<samueldr> I have zero experience with i.MX boards in u-boot, so never looked at their codepaths
<samueldr> it could be that fdt_addr_r has no defaults
<samueldr> or it could be that your u-boot loads an environment from a previous u-boot?
<samueldr> not sure how you'd check if it loaded an environment that was somehow saved to e.g. an SPI flash or something
<samueldr> that is something that can bring pain
orivej has joined #nixos-aarch64
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #nixos-aarch64
<Ke> I see in the succesful boot I did load fdt manually before booting
<Ke> I thought that's irrelevant, but maybe it's not
<Ke> fatload mmc 1:1 ${fdt_addr} nixos/9f5spcvsm9ch8b99bb8qs6dg86r864jf-linux-5.4.67-dtbs/marvell/armada-8040-mcbin.dtb
<Ke> but this is why I love u-boot, everything is so simple and understandable
<samueldr> it's all "simple" in the end
<samueldr> almost everything is broken out in commands
<samueldr> and internals end up calling commands
<Ke> well EFI has more code
<samueldr> though it's messy at places
orivej has quit [Ping timeout: 240 seconds]
<Ke> I'd love to know, what is the boot method that gets used by sysboot
<samueldr> it's all bootm in the end IIRC
<Ke> like I could just load the code manually and exec bootlikesys $addr $addr $addrs
<Ke> I think I tried bootm without success
<samueldr> booti*
<samueldr> bootm is the "older" way
<samueldr> (I had to look)
<samueldr> though sysboot, which ends up using pxe boot stuff, uses either bootm, booti or bootz depending on what is booting
<samueldr> though bootz shouldn't be a thing for an AArch64 board if I understant things right
<Ke> if it's forthe images that have naiive zlib compression, no
<Ke> these images are bare PEs
<Ke> file recognizes them
<samueldr> so looking at it, your board shouldn't be using the codepath you linked earlier with f1 through f4 for fdtfile; include/configs/mvebu_armada-8k.h defins fdtfile
<Ke> yes, I don't get that env
<Ke> I should check that mtd now, I think
<samueldr> check that mtd?
<Ke> the spi mass storage I have
<samueldr> env default -a
<samueldr> apparently is how you would reset your environment
<samueldr> that wouldn't be saved though
<Ke> well I have debian running now and it is my router, so will not reboot at this time
<samueldr> there may be an "eraseenv" environment variable that you can use to `run eraseenv` depending on the board
<Ke> but thanks
<samueldr> I was curious about how to do that
<samueldr> since I think it's soon going to bite pinebook pro users
<samueldr> u-boot mainline will start loading env from SPI
<samueldr> but it might have a bad env from the spoopy u-boot build from the default debian (for older devices)!
<Ke> well my opinion would be to just hardcode the env in the binary and not load, but won't argue with you there
<Ke> that's what I do on my pbp
<samueldr> I'm really split
<samueldr> I hate the fact that it might break things
<samueldr> but straying from mainline config brings headaches too
<samueldr> and saving the env would be useful in the next iteration of the menu interface I'm putting together
<samueldr> just like a good ol' bios, you could change the boot order
<Ke> can't you change that from nixos side
<Ke> if not, maybe update the config generator
<samueldr> I don't follow
<samueldr> oh
<samueldr> order as in eMMC, SD, USB
<samueldr> NVMe even
<samueldr> firmwarey stuff
cole-h has joined #nixos-aarch64
<samueldr> I really have that strong opinion that the operating system shouldn't mess with the firmware stuff that much
<samueldr> or at the very least, be an option to do so
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
alp has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
<Ke> samueldr: thanks, env reset did help
<Ke> and I was able to save it
<Ke> samueldr: also setting bootable flag is not needed
<Ke> maybe being efi system partition is considered to be equivalent
<Ke> now it just runs through the boot
<Ke> now I need just a couple of settings to make this work
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 240 seconds]
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
alp has quit [Ping timeout: 265 seconds]
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 240 seconds]
knerten2 has quit [Ping timeout: 240 seconds]
alp has joined #nixos-aarch64
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
knerten has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Read error: Connection reset by peer]
tilpner_ is now known as tilpner
V is now known as v
v is now known as V
evils has joined #nixos-aarch64
<samueldr> great to know about env reset, it'd be nice to figure out a well-rehearsed "why isn't my u-boot booting?" page with things to look out for
<Ke> still havin issues with ethernet not working and interfaces not having predictable names
<samueldr> that board seems to be a whole load of fun :/
<Ke> kind of funny that they just could not create single image that would contain fat fs in addition to bootloader and a single u-boot script to do the falshing
<samueldr> or have it handled by mainline linux's firmware loading
<Ke> as I may have mentioned, I believe my unit is slightly broken
<Ke> yeah I guess this could also be done from the OS, though the update may break networking
<Ke> but that's still easier, as reboot certainly does
<samueldr> I don't know how firmware updates are handled in Linux
<samueldr> I mean, firmware changing while the system is booted
<Ke> I assume it's always device specific
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
alp has quit [Ping timeout: 260 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
<Ke> btw. networking really works, if I init it in u-boot
<Ke> now just wondering, what would be most sane way to automate that in u-boot
<samueldr> if you're not against editing the env and using saveenv
<Ke> but I am now in a state, where I think I don't even have to reboot to debian
<samueldr> edit bootcmd
<samueldr> you could also have that be part of the *built* default env so it'd survive a reset by patching u-boot
<Ke> sure, but which commands
<Ke> eg. dhcp runs until perpetuity
<samueldr> I can't say *how* exactly, since there seems to be a couple ways to do that
<samueldr> "bootcmd"
<samueldr> that's the command that by default it tries
<Ke> there is no start networking command is there, that just does L2 handshakes
<Ke> but yes I have used bootcmd in the past
<samueldr> bootcmd tries the different "actual implementations"
<samueldr> like bootcmd_mmc1
<Ke> maybe setting ip and running ping would time out
<samueldr> though maybe I don't understand what the issue is on your side
<samueldr> since PXE/DHCP boot should only happen *after* the board tries the other "BOOT_TARGET_DEVICES" it #defined
<Ke> linux drivers suck and require initialization done by u-boot, I believe
<samueldr> yes
<samueldr> well, I understood that you'll need u-boot to init the network interfaces
<Ke> I just tried manually running dhcp in u-boot and it fixed issues on linux
<samueldr> so u-boot, once it's done initializing the board, "continues" boot by doing what's described in README.distro
<samueldr> oh
<Ke> maybe I'll try the ping thing
<samueldr> I see what you meant, you need to do *something* with networking in addition to initializing their firmwares, right?
<samueldr> only initializing their firmwares is not enough?
<Ke> that firmware update was a one time thing and did not make any difference I could observe
<samueldr> ah, I see
<Ke> since it was there, I gave it a go
<samueldr> I assumed it was firmware that needed to be uploaded to the devices for them to work
<samueldr> you know, instead of having them in ROM, upload to device RAM
<Ke> sure
<Ke> the bgamari person also had comments pointing to initializing networking in u-boot without specifics
<Ke> but it really was as naiive as just using dhcp, maybe any command that does L2 handshake will do
<Ke> to be able to be automated, it needs to be something that terminates on failure/timeout
<Ke> I guess I could just take a look at linux drivers and what they do wrong
heywoodlh has quit [Quit: ZNC 1.8.2 - https://znc.in]
heywoodlh has joined #nixos-aarch64
Darkmatter66_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
patagonicus138 has joined #nixos-aarch64
evax has quit [Quit: WeeChat 2.8]
patagonicus13 has quit [Ping timeout: 244 seconds]
patagonicus138 is now known as patagonicus13
justanotheruser has quit [Ping timeout: 272 seconds]
heywoodlh_ has joined #nixos-aarch64
heywoodlh has quit [Ping timeout: 240 seconds]
<samueldr> danielrf[m]: out of the blue, on marlin, is there an issue if we don't delete the default dm-verity certs from the kernel build?
<danielrf[m]> I don't think it should cause any issue (except for maybe allowing you to mount an image signed by the default cert, which was something I didn't want to do)
<danielrf[m]> in earlier versions of robotnix I didn't delete the default cert and booting worked fine IIRC
<samueldr> I'm revamping the kernel builder for better ergonomics, now that I have a good selection of all the different kind of issues
<samueldr> I guess I could rm that all the time anyway
<danielrf[m]> hmm, actually looking at it--I only deleted the default verity_*.x509 if I had a replacement verity_user.der.x509 to put in the root dir
<danielrf[m]> so I actually don't know if it will build without any verity certs in the root dir
<samueldr> rm -vf *.x509 # in Mobile NixOS
<samueldr> so I guess it will
<danielrf[m]> yup I guess so then
<danielrf[m]> my earlier comment was just for what I did in robotnix
<samueldr> yeah, I didn't specify Mobile NixOS lol
alp has quit [Ping timeout: 244 seconds]