<makefu>
seems to be similar to the sha256 thing, kernel build fails with: Error: modDirVersion 4.4.17 specified in the Nix expression is wrong, it should be: 4.4.77
<samueldr>
I `/error` and then go up until a gcc error
<samueldr>
since it was highly parallelized
<samueldr>
(since you built on the community machine, it was trivial to get your log using nix log :3)
<makefu>
ha!
<samueldr>
can't look at it more deeply, but that's where it fails, at least
<makefu>
okay thanks!
<makefu>
i will try building with upstream _latest first, then i will have a look at this
<makefu>
maybe i can just disable the PWM part
<samueldr>
sometimes with OEM kernels it's possible to find patches fixing some issues, e.g. android-device kernels often fail to build on more recent gcc than the expected 4.x
<samueldr>
though here it doesn't look like it
<samueldr>
you may want to pick the ubuntu image, zcat /proc/config.gz and use it as a configuration starting point?
<samueldr>
to at least attest the kernel should build
<makefu>
yeah that is a good idea
orivej has quit [Ping timeout: 268 seconds]
<samueldr>
(also check the uname since it might be an older version, though it won't tell the revision :/)
<makefu>
embedded development is a mess haha
<samueldr>
it doesn't have to be like that :/
<makefu>
true, but it seems to be the normal case with chinese sbc manufacturers
<makefu>
even though raspi is the *best* supported device it still has quirks to work around and often times the upstream kernel does not do all the stuff. most of the support is simply coming from the community
<samueldr>
the raspberry pi isn't better supported really
<samueldr>
they have their own kernel fork, which is the only supported kernel
<samueldr>
they posture as open source, but IMHO they're not that great
<samueldr>
considering the boot chain still has blobs, and they don't tend to mainline much
<samueldr>
the only redeeming factor here, and it really helps, is the huge install base
clr_ has joined #nixos-aarch64
clr__ has joined #nixos-aarch64
hark has quit [Ping timeout: 246 seconds]
<makefu>
samueldr: that is exactly what i mean. i am wondering why there isn't one supplier who really puts an effort into making at least one of their chips completely supported by the upstream kernel and uboot without any weird hacks and blobs everywhere
<samueldr>
yeah
<makefu>
the camera drm stuff is madness
<samueldr>
and even then, do not stop at u-boot, even though it consumes time and effort, have both u-boot and coreboot+tianocore (or simply tianocore)
<samueldr>
monocultures aren't great
<makefu>
absolutely correct
<samueldr>
I really hope that the fact coreboot has rk3399 stuff in due to chrome devices means getting it working on another RK3399 device is easier
<makefu>
the sdcard build completed ( 2 hours ago ) thanks to the community builder
<makefu>
this builder is godsent
<gchristensen>
=) <3
<clever>
samueldr: damn, i didnt know they added that chip
<clever>
samueldr: last i heard, it was just because they wanted to properly set the debayer filters and whatnot, to make the camera work right
<clever>
so once you do get linux running on the arm, my v3d drivers can get you 3d accel
<samueldr>
while I appreciate the concerns about the codecs
<clever>
but you wont have anything to render it to!, lol
<samueldr>
I find the answer "the only reason" a bit presumptuous
<clever>
i believe the serial# and all other config, are in write-once fuses
<samueldr>
yes
<clever>
so you can change the bit one way, but not the other
<clever>
so you could just set every bit in the serial#
<samueldr>
scroll to the end of the thread
<clever>
that would destroy the unique tracking#
<samueldr>
though, I'm not sure what you said applies; keyword: not sure
<samueldr>
I think there's ways to make fuses unwritable in that sense
<samueldr>
otherwise intel bootguard would be trivial to bypass
<clever>
i'm guessing intel bootguard is normal flash memory, guarded by signed firmware that restricts when and how you edit it
<clever>
but the rpi boot chain isnt signed, and i suspect that at the hardware level, its just plain write-once fuses
<samueldr>
it's reported that the key is burned to fuses to the intel CPUs
<clever>
so custom firmware can just burn any fuse
<samueldr>
that'd be a bit scary imho
<clever>
the most you could do is set the serial# to either 0000000 or ffffffff, depending on the type of fuse
<clever>
and they likely wont tell a codec for that
<clever>
s/tell/sell/
<samueldr>
sure, though I'd like to get a definitive answer about that, only to satiate my curiosity
<samueldr>
how are those fuses made read-only, if they are
<clever>
hardware level
<clever>
the name points to the history, fuses
<clever>
run too much power thru it, on purpose, and you blow the fuse
<samueldr>
yes
<samueldr>
that I understand
<clever>
run less, and you can detect if its blown or not
<samueldr>
but that's 0/1 yeah
<samueldr>
so how can you prevent flipping them all
<clever>
once you blow the fuse, you cant un-blow it
<clever>
as an example, you can change a 1->0
<clever>
but you can never change a 0->1
<samueldr>
yes, I understand how fuses work in that sense, but I don't see how it'd make sense in e.g. bootguard, to have them be on fuses if the fuses can still be flipped
<clever>
so if you program the fuses to 1010, only half are blown
<clever>
and the other 2 bits can still be written
<gchristensen>
I think you have to have a certain connection to the system to set the fuses
<clever>
i suspect the intel bootguard isnt fuses, but rather, flash memory
<clever>
confusingly, embeded chips like AVR still call it fuses, but its now done using flash memory
<clever>
the logic within an avr for example, has a special "fuse" that disables reading back the program data
<clever>
and it will only clear that after you run a chip-erase command
<samueldr>
>> About one in every four fuses is reserved for locking, repairing, and redundancy check purposes
<clever>
`The field programmable fuses are essentially another nonvolatile storage medium.`
<clever>
they call them fuses, but they are just flash memory
<samueldr>
reading on it looks like it's not it
<clever>
just a specialized form of flash memory, with smaller erase blocks and such
<clever>
in the AVR for example, the cell responsible for preventing firmware readback, has a special metalized layer over it, to shield the cell when you try to poke at a decaped chip
<samueldr>
here it definitely doesn't look like flash
<clever>
but, with careful angles and masking, you can still wipe it
<samueldr>
looks like the way intel's implementation handle it is through a "black box" where software is ran before writing, checking whether a locked fuse is set or not
<clever>
oh, and another thing about the rpi
<clever>
i think the boot rom, is 512 bytes of write-once memory
<clever>
maybe bigger, not sure
<clever>
when it boots up, the VC4 core will start running that boot rom
<clever>
which can then load bootcode.bin from: serial flash, parallel flash, usb mass storage, netboot over usb controller, an SD card, or acting as a usb slave with a DFU style download
<clever>
at this point, dram is still offline, so bootcode.bin must fit entirely in the L2 cache
<clever>
bootcode.bin is then responsible for turning on the dram, and loading start.elf
<clever>
2 bootcode.bin files are publicly available
<clever>
the main one, supports finding start.elf over: usb mass storage, usb ethernet, SD cards
<clever>
the secondary one, just turns the rpi itself into a mass-storage device, to share the internal SD card
<clever>
no bootcode.bin files are available that support the serial or parallel flash's
<clever>
start.elf is then responsible for loading the linux kernel into ram, and bringing the ARM core's online
<clever>
usb mass storage and usb ethernet are disabled by default, and enabled by a write-once fuse
<clever>
the userland libraries and linux-kernel side drivers are fully open now, ive read the source for them before
<clever>
the video pipeline is also very near
<clever>
neat*
<clever>
you have multiple modules, like a demuxer, video decode, video render
<clever>
and each has input and output ports of various types
<clever>
and then you just link them up right, feed it a raw mp4 stream, and boom, you got a video player
<clever>
if 2 modules are both in the start.elf side, it will ship packets around with shared memory, and you dont have to even think about handling the uncompressed 1080p frames
<clever>
but you can also implement modules in userland, and have it route data to/from that
<clever>
there are also modules for camera capture, video encode, and muxing
<clever>
so you could probably whip up a fully hardware encode/decode supported video phone in about 2 days
<clever>
samueldr: oh, and something else, do you know about the difference between teletext (EU) and closed captioning (NA)?
<samueldr>
not in details, only that they're different beasts for different use cases
<clever>
yeah, closed captioning is ~2 lines of text at most
<clever>
teletext is capable of full-screen text, with i think 255? channels of it, on a single "real channel"
<clever>
ive heard of things like phoning up a service, which tells you to flip to page 123 of the teletext, then you use the phone to reply, and the tv to view the service
<clever>
so, if you wrote the right drivers in xorg, you could have a hardware accelerated compositing window manager, and windows would drag far smoother
<clever>
i think the wayland stuff is already doing that?
<samueldr>
I'm soooo out of the loop for graphical stuff with the raspberry pi
<clever>
but it wont have any rotation or effect support, that needs the v3d core
<samueldr>
mainline has a vc4 kms driver, dunno how it meshes with all that
<clever>
samueldr: around 2014, the rpi foundation open-sourced the linux drivers for an android device, that used a variant of the vc4 chipset
<clever>
the variant lacked the VC4 cpu core, so it was just the 3d pipeline, and nothing else
<clever>
which meant, the 3d pipeline had to be implemented on the arm side, in linux
<clever>
and they started a contest to port that to the rpi
<clever>
i'm the nut-job that wanted to re-implement it from the specs :P
<clever>
and i got far enough to get full 2d texture rendering, with alpha channel support
<clever>
i also had no clue how libGL worked, so i made my own libGL, that matched the functions in the header files, lol
<clever>
it "worked" for the one app i was testing in at the time
<clever>
samueldr: basically, the rpi chip is ~6 cpu cores, over 192 shader cores, hardware video encode/decode modules, ntsc/pal modules, DSI and CSI ports, and a usb 2.0 controller, all jammed into a single chip
<clever>
4 of the cores are arm, with all the virtual memory stuff you would expect
<clever>
2 of the cores are VC4, and lack virtual memory, they run a threadx based OS, which is stored in start.elf
<clever>
all 6 cores share the same ram
<clever>
the chip also has 2 DSI and 2 CSI ports, so it can run 2 lcd's and 2 cameras, potentially
<clever>
samueldr: i suspect that the vc4 kms driver you mentioned above, is just talking to the firmware in start.elf, and asking that firmware to do the switching
<clever>
and lacks actual support for the chip itself
<clever>
samueldr: related, is another case of software not actually supporting the thing it claims to support
<clever>
samueldr: grub, technically has zero support for nvme
<clever>
samueldr: it relies on the uefi firware, to provide nvme drivers
<samueldr>
does grub claim it supports nvme?
<samueldr>
here relying on UEFI for this I think is fine
<samueldr>
I mean, the firmware probably has to handle it anyway
<samueldr>
and yeah, I guess sometimes it won't
<clever>
my desktop doesnt have nvme in the firmware
<samueldr>
e.g. NVME over a PCIe card
<samueldr>
:D
<samueldr>
I was about to re-tell your story
<clever>
so i cant put the boot stub onto a sata card, and then /boot/ on the nvme
<clever>
i must put the entire /boot/ on the sata drive
<clever>
but the rootfs can be nvme, since the driver is in the initrd
<samueldr>
can't remember if you ended up trying to make a driver for it or not
<samueldr>
though with UEFI it looks "sane enough" depending
<clever>
grub does have the string "nvme" in its source code, but its purely code to convert nvme0n1p2 into a partition#
<clever>
ive also poked around in #osdev a bit with some nvme questions, and at the hardware level, it has a pretty massive number of fifo's and irq's
<clever>
which allows you to setup per cpu core command/data buffers, and per-core irq's
<clever>
so when core0 asks for data, core0 gets the irq when its available, and core0's cache is still hot
<clever>
and every cpu core can talk to the nvme in parallel, without having to bother with mutexes
<samueldr>
I was thinking code from EDK2 might be reusable
<clever>
oh, i remember now what i was trying to cheat around, and why EDK2 wont work
<clever>
legacy booting, on nvme, with a pre-efi computer
<samueldr>
IIRC you can load drivers from storage, so you wouldn't have to modify the firmware necessarily
<clever>
shove stage 1.5 onto a sata disk, but leave /boot on the nvme
<samueldr>
yeah, without UEFI you're in for pain
<clever>
the only option there, is to put the entire /boot/ onto the sata disk
<samueldr>
I wonder though with something like clover, which IIRC is based somewhat on EDK2 or TianoCore whether it would have been possible
<clever>
and then only linux cares about nvme, and the initrd can cover it
<samueldr>
never took the time to explore MBR->UEFI
<clever>
something else ive wanted to fix on the nixos install docs, is the usage of mbr vs gpt
<clever>
at least for x86, there is never any reason to use MBR now
<samueldr>
clever: irks me some too, though this won't help with the duality of UEFI systems requiring an ESP
<samueldr>
and will require some verbosity about the biosboot partition
<clever>
if you want efi, make your /boot/ fat32
<clever>
if you want legacy, make a biosboot
<samueldr>
then you still need to provide different sizes
<clever>
if you dont have efi, /boot/ is optional
<clever>
if you want legacy and a /boot/, then you need a biosboot, and a /boot/
<clever>
so 2 partitions
<samueldr>
I'm thinking we need an installation *manual* with different scenarios and questions/answers, but the time to actually write it is sparse
<samueldr>
like make the installation section an appendix, which is built in a separate manual file (at least the HTML manual)
<clever>
have you seen `make menuconfig` in the kernel before?
<samueldr>
and *explain* those things instead of just making a quick list of commands to run
<samueldr>
clever: yeah
<clever>
i had an idea a few weeks ago
<clever>
i could use that program, with a custom menu, to ask you about how you want the install done
<samueldr>
no, not an installation menu based on that
<clever>
and then post-process the answers, into a script
<clever>
uefi? legacy? both?
<clever>
/boot/ partition?, what fs? (options forced based on previous answers)
<samueldr>
though, in a way, it'd make the UI building an answered question
<clever>
/ partition type? (can force the creation of /boot/)
<samueldr>
hmmm, I hate the idea, but I think it would work better than many other
<samueldr>
and there are other UIs than ncurse
<clever>
yeah, the same config file has an x11 ui and a gtk ui i think
<samueldr>
yeah
<samueldr>
I think the main issue would be there would be no "wizard", only a menu of options
<samueldr>
but still, an interesting idea
<clever>
i have made 2 different wizards already
<clever>
where did i put that example...
<clever>
samueldr: https://ext.earthtools.ca/docroot/ this was version 0, open an option up, and click the use button, what do you see in the bottom?
<samueldr>
yeah, I remember that, still doesn't handle the before-configuration.nix part
<clever>
that entire video, was recorded inside the nixos test framework, and if you set an env var, the QT app would click its own buttons at scheduled times
<samueldr>
heh, cheaty, getting the app to do the hard test work
<clever>
its even embeding an xterm in there, with the right flag, xterm can hijack an X11 element in another app, and embed itself seamlessly
<clever>
and based on the dropdowns, it generates the right config
<clever>
this is a fully navigatable tree view of the nixos options, that can display the descriptions
<clever>
tilpner: it generates a full configuration.nix file
<clever>
but one thing i was lacking at the time, was a way to parse the file, to allow further changes
<tilpner>
That's easier with JSOn
<clever>
hnix has since solved that
<tilpner>
I guess hnix works too
<clever>
i wanted to be able to load a config file that has weird things like if statements, and allow you to edit the parts the code can understand, without loosing the if's
tilpner has quit [Quit: WeeChat 2.3]
acarrico has quit [Ping timeout: 250 seconds]
<clever>
samueldr: oh, something i forgot to mention
<clever>
samueldr: the ethernet chip in the rpi board, doesnt know its own mac addr, on bootup
<samueldr>
like most cheap SBCs
<clever>
the mac is in the write-once fuses on the cpu, and the linux drivers are required to initialize it properly
<clever>
so that paranoid guy in the twitter thread, worried about the tracking# (serial#) is ignoring the mac
<samueldr>
worse for many SBCs
<clever>
and if you mess with the mac, the ethernet wont work right :P
<clever>
the wifi and bluetooth also have macs
<samueldr>
where they are randomly generated at boot and saved in storage from u-boot
<samueldr>
so if you were to duplicate the sd card, you'd have the same MAC