<matthewcroughan>
> Newer SoCs (tested on H2+, A64, H5, H6) can also load the SPL from sector 256 (128KB) of an SD card or eMMC, if no valid eGON/TOC0 signature is found at 8KB (BROM boot order). The U-Boot proper offset needs to be adjusted accordingly in this case. U-boot patch more details
<{^_^}>
error: syntax error, unexpected ',', at (string):471:26
<matthewcroughan>
samueldr: does the nixos-sd-image have slack sp;ace for u-boot?
<samueldr>
yes
<samueldr>
and anyway u-boot would work anyway
<samueldr>
it'd break the data found at that location
<samueldr>
but u-boot would work
<samueldr>
since you write the sd image, then write u-boot on top
<matthewcroughan>
uboot just gets stuck at "Trying to boot from MMC1"
<matthewcroughan>
but at least it's booting MY uboot!
<matthewcroughan>
samueldr: what do you think "if no valid eGON/TOC0 signature is found at 8KB (BROM boot order). The U-Boot proper offset needs to be adjusted accordingly in this case." means?
claudiii has quit [Read error: Connection reset by peer]
claudiii has joined #nixos-aarch64
jackdk has quit [Read error: Connection reset by peer]
<samueldr>
SoC first looks at sector 16 (16*512KiB == 8*1024KiB), if it doesn't find the magic numbers, it then checks at sector 256
jackdk has joined #nixos-aarch64
<samueldr>
the magic numbers are lterally the ascii characters "eGON" and "TOC0"
<matthewcroughan>
well I guess my uboot doesn't have the magic numbers
<samueldr>
no it does
<samueldr>
[19:13:02] <matthewcroughan> uboot just gets stuck at "Trying to boot from MMC1"
<samueldr>
I *believe* that's the u-boot SPL
<samueldr>
common/spl/spl.c
<samueldr>
printf("Trying to boot from %s\n", loader->name);
Acou_Bass has quit [Read error: Connection reset by peer]
<samueldr>
so at that point, as far as handing off to "a" firmware, the SoC succeeded
<matthewcroughan>
yeah, but it doesn't yet boot nixos :P
<samueldr>
it seems so
Acou_Bass has joined #nixos-aarch64
<samueldr>
you're skipping steps anyway, before booting NixOS, you need to have u-boot working
<matthewcroughan>
samueldr: why `count=1`?
<samueldr>
and I have no way to help more with that, except than hazardous guesses, I don't have the hardware
<matthewcroughan>
the bootloader is 631K
<samueldr>
matthewcroughan: if you wanted to check the the magic number from armbian's image
<samueldr>
you only need the first four bytes
<samueldr>
count=1 limits to 1024 bytes here
<samueldr>
oh right
<samueldr>
you had that "Trying to boot from MMC1" error
<samueldr>
that was when u-boot was flashed at the secondary location? (128KB in)?
<samueldr>
if so, that's normal
<samueldr>
the SPL jumps to a hardcoded value
<samueldr>
u-boot is assuming that it's being written at 8KB in (sector 16) by default
<matthewcroughan>
> Sparse files have different apparent file sizes (the maximum size to which they may expand) and actual file sizes (how much space is allocated for data on disk). To check the file's apparent size, just run:
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):471:196
<samueldr>
sure, but that doesn't make sense in the context
<matthewcroughan>
sure it does, there's a direct example with dd in that archwiki article
<matthewcroughan>
fallocate fake_file -l 10GiB, you'll get a file that claims to be 10GiB
<matthewcroughan>
IDK why it's like this.
<samueldr>
oh, seek instead of skip
<samueldr>
it should have been skip
<samueldr>
but still, your hexdump output should have shown the eGON or TOC0 signature I figure
Acou_Bass has joined #nixos-aarch64
<matthewcroughan>
samueldr: maybe I should grep for it
<matthewcroughan>
samueldr: u-boot from armbian's patches doesn't work either lol
<matthewcroughan>
interesting, huh?
orivej_ has quit [Ping timeout: 246 seconds]
<matthewcroughan>
samueldr: Mic92: final conclusion then, I've tried it with and without the arm trusted firmware, on both v2021.01 with the patches from patchwork, and v2020.07 with the armbian patches. None of them work, they all hang with `Trying to boot from MMC1`. Absolutely nothing more, nothing less.
<samueldr>
btw it's not really about _testing_ against flakes, but really more about code quality
<colemickens>
if I wanted to test this quickly to sanity check it, what do I do?
<colemickens>
I want to test a change on top of what you've got and then discuss it if it works out
<samueldr>
I'm not actually sure
<samueldr>
I tested using `env -i` to clear the env and nix path
<colemickens>
I never really built from mobile-nixos. I'd managed to pull the nixos module in per the docs I think. I guess I can see if that still builds after this change.
<samueldr>
my main concern (and the PR's original intent) was about removing the stray <nixpkgs> references still floating around
<samueldr>
yeah, any method you used previously
<samueldr>
as long as you know <nixpkgs> cannot work
<colemickens>
I just want to exercise evalConfig mostly right now
<colemickens>
maybe I can make it just eval a random device for me
<samueldr>
nix-instantiate --argstr device [...] -A build.default
<samueldr>
where e.g. pine64-pinephone, asus-z00t, etc
<samueldr>
release.nix also exercises it a bunch
<colemickens>
yeah, well my only idea was a bust so idk. The need for the nixos module just seems odd, but I get inf recursion if I try to remove it
<colemickens>
the extra _mobile-nixos thing, that is.
<samueldr>
ah
<samueldr>
yeah
<samueldr>
I had trouble removing that requirement
<samueldr>
BUT
<samueldr>
I also need it for external reference
<colemickens>
It almost looks like flakes too, but not really because it shouldn't be necessary to access self...
<samueldr>
I still want to support the use case of out-of-tree devices
<colemickens>
but also, I was wondering about that, yeah.
<samueldr>
I have a tablet which I know full well that it currently requires per-device specifics
<samueldr>
so I'm not adding that to mobile nixos
<colemickens>
Is there an advantage to building from mobile-nixos instead of including the module myself and reaching into the outputs?
<samueldr>
what do you mean?
<samueldr>
using nix-build to go throuhg default.nix or any of the examples?
<samueldr>
there shouldn't be any difference
<samueldr>
otherwise it's a bug
<samueldr>
it's all about producing a nice-to-use porcelain
chr0ma[m] has joined #nixos-aarch64
<colemickens>
hm
<samueldr>
did I get your question right?
<colemickens>
I think so.
<samueldr>
btw, share your concerns or issues
<samueldr>
I definitely can have forgotten about something
<colemickens>
nope, no issues. Just thinking about the UX of it all a bit.
<samueldr>
yeah, right now I'm doing a 1:1 change without changing the UX at all
<samueldr>
same commands work as they did
<samueldr>
but I'm also open to reviewing some of it
<samueldr>
e.g. I want to remove the environment variable thing (that I never used)
<samueldr>
and I wouldn't be against fresh ideas for how to use into your own configuration
<colemickens>
I think what you have for the module is fine, it feels very nixosy
<samueldr>
you mean for evaluating from an /etc/nixos/configuration.nix thing?