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