wildtrees has quit [Quit: Leaving]
ris has quit [Ping timeout: 276 seconds]
clever_ has joined #nixos-aarch64
clever_ has quit [Changing host]
clever_ is now known as clever
<MichaelEden[m]> Ashy: thanks!
orivej has quit [Ping timeout: 240 seconds]
<Ashy> hmm, latest image and uboot still won't boot the rockpro64
<Ashy> i don't quite understand why ayufan's patches to uboot and the kernel still haven't been mainlined yet
<samueldr> I'd say the same for the pinebook (a64)
<samueldr> for the kernel*
<samueldr> at least u-boot seems fine
<Ashy> have you ever got any patches into mainline kernel?
<samueldr> haven't written anything yet
<Ashy> it's something i've had on my bucketlist for a while hehe
<samueldr> one day I figure I will, with the way things are going :)
<samueldr> though I did almost, but chickened out, and someone else did a better fix anyway
<samueldr> years ago, for the touchpad of my then-new laptop
<Ashy> last time i was playing with nixos on the rockpro64 (a few months back) i did actually get it running but only by starting with ayufan's ubuntu image and then dd'ing over the nixos root partition so it was still ayufan's uboot and kernel
THFKA4 has quit [Ping timeout: 246 seconds]
<samueldr> we do have a u-boot build now
<Ashy> it should be possible to write an sd-image.nix definition that does all that and builds a rockpro64 specific image right?
<samueldr> according to this page at least, hydra should be building a u-boot for it
<Ashy> yeah i just tried that on the sdcard though and didnt get any hdmi output
<samueldr> I believe that if you delete the FAT32 partition of a 19.09 or unstable sd-image, and then `dd` as described it should work
THFKA4 has joined #nixos-aarch64
<Ashy> oh, delete the first partition?
<samueldr> (deleting the partition is mostly so stuff isn't confused by the garbage that'll get written there)
<samueldr> "garbage"
<samueldr> rockchip firmware files... judge like you want :)
<Ashy> yeah blobs are blech... market slowly seems to be coming around to that though
<Ashy> so what exactly should i do with this uboot image?
<samueldr> sudo dd if=idbloader.img of=/dev/mmcblkX bs=512 seek=64
<samueldr> it sounds like :)
<samueldr> (I don't have rock* hardware)
<Ashy> yeah but delete the first mmc partition first?
<samueldr> well, rock*64, from pine
<Ashy> ah ok
<samueldr> you should delete the first partition, yeah
<samueldr> it should boot with it still
<samueldr> but some software may barf when seeing what seems like random garbage
<samueldr> I think that idbloader is bigger than the gap in front
<Ashy> mount it and use rm or fully delete it from the partition table?
<samueldr> only from the partition table
<samueldr> though, even if I don't have their hardware, I think I know enough about the boot chain to help
<Ashy> is there an example sd-image.nix somewhere that includes specifying a specific uboot configuration/fork and a specific kernel fork?
<samueldr> u-boot (for now) is handled out-of-band
<samueldr> e.g. dd on your device
<samueldr> not sure about a good example for the rockpro64 and configuring the kernel
<Ashy> hmm, yeah still no hdmi output after deleting the fat32 partition and dd'ing the uboot image again
<samueldr> lopsided98: you can also cc me on generic base nixos-on-arm stuff, if you want
<samueldr> they're likely to affect me somehow at some point :)
<Ashy> yeah that prebuilt uboot for the rockpro64 does not seem to want to boot
<Ashy> or possibly it is but hdmi isnt working
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
mishach has joined #nixos-aarch64
<mishach> greetings;
<mishach> If there is someone who can help, here is my problem. I am just looking for some pointers on how to proceed.
<mishach> I am trying to compile a hello world program that includes glib and pkgconfig as nativeBuildInputs
<mishach> when i entered nix-shell, PKG_CONFIG_PATH was not set, so i fixed that
<mishach> but when i try to compile hellow world program i run into this error
<mishach> it is identical to erro described here
<mishach> and my default.nix file
<mishach> Note, hellow world runs in standard environment
<mishach> it just in cross-compiled it throws an error
<mishach> any times or pointers would be greatly appretiated
<mishach> so my guess is
<mishach> derivation is incorrect, but how to debug it
<clever> mishach: if you add pkgconfig to the nativeBuildInputs, it will manage PKG_CONFIG_PATH for you
<clever> glib likely has to be in buildInputs
<mishach> ohh
<mishach> however, i added pkgconfig to nativeBuildInputs
<mishach> that just worked
<mishach> !!!!
<mishach> i just had to place library into
<mishach> buildInputs
<mishach> Thank You!
<mishach> so I am getting something wrong about nativeBuildInputs vs buildInputs dependencies
<mishach> so libraries that we will be used by the program when it is run on the host go to buildInputs
<clever> mishach: yes
<mishach> wow, that was a huge learning experience for me.
<mishach> Thank You!!
mishach has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
DigitalKiwi has quit [Quit: quite.]
DigitalKiwi has joined #nixos-aarch64
saboteur has joined #nixos-aarch64
saboteur has quit [Remote host closed the connection]
saboteurspk has joined #nixos-aarch64
saboteurspk has quit [Remote host closed the connection]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
SaboteurCZ has joined #nixos-aarch64
SaboteurCZ has left #nixos-aarch64 [#nixos-aarch64]
SaboteurCZ has joined #nixos-aarch64
SaboteurCZ has quit [Remote host closed the connection]
SaboteurCZ has joined #nixos-aarch64
<SaboteurCZ> Hi samueldr. Just wanted to ask what is the current state (or progress) of work on NixOS on PinePhone :)
SaboteurCZ has quit [Remote host closed the connection]
ris has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Read error: Connection reset by peer]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 276 seconds]
ryantrinkle has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
ryantrinkle has quit [Ping timeout: 276 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 245 seconds]
kunstruktur has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
jtojnar has quit [Read error: Connection reset by peer]
<lopsided98> 5.3 doesn't boot on my RockPro64...
<lopsided98> samueldr: I'm getting similar errors as your chromebook
<lopsided98> mmc1: mmc_select_hs400es failed, error -110
<samueldr> ooh
<samueldr> then you may be in a better position to bisect than I am
<samueldr> the chromebook I have simply doesn't go far back enough
<samueldr> I'd have to backport way too much changes to get it compiling under mainline for older than 5.0
<samueldr> lopsided98: is it pretty consistent?
<samueldr> do you know the model number of the eMMC?
<lopsided98> I have been unable to boot 5.3 at all, previously I was running 5.2.10 with ~50 of ayufan's patches (https://github.com/lopsided98/linux/commits/rock64-5.2.y)
<lopsided98> Those patches actually limit the speed to hs200 (https://github.com/lopsided98/linux/commit/e4abb4c92b7fb41b51116f9ca375c0bed0fdbe8e), but it still fails
<samueldr> it's not FORESEE though
<lopsided98> The error I posted above was from unpatched mainline
<samueldr> ah!
<samueldr> yeah
<samueldr> I figure limiting to hs200 is what made it work
<samueldr> I am doing the same, but in a much less clean way
<lopsided98> No, I tested 5.3 with that patch and it still fails
<samueldr> try this one
<samueldr> it's my much less clean way :)
<samueldr> hs400es just won't exist
<lopsided98> I'm not sure what the model is, I don't have physical access to it right now
<samueldr> if you have the dmesg output of a working boot, it should be in there somewhere
<lopsided98> Wait, it just booted when I went to test the patched kernel again
<samueldr> I have suspicions that mainline is doing something just out of tolerence for some cards
<samueldr> or that some some eMMCs are just out of tolerance
<lopsided98> Yeah, it has never been very reliable but it would usually work after 2 or 3 tries
<lopsided98> I can't find anything about the model number in dmesg
<samueldr> dmesg | grep -i mmc
<samueldr> it will not say "this is the model number"
<samueldr> but it should be in there
<samueldr> at least it was in my experience
<lopsided98> mmcblk2: mmc2:0001 DG4032 29.1 GiB
<samueldr> that's it
<samueldr> this *may* be WD
<samueldr> right
<samueldr> it's SanDisk
<samueldr> like mine
<samueldr> and like
<samueldr> (sandisk is a brand of WD now)
<samueldr> I say it's sandisk, found it listed here http://www.szhcheng.com/EMMC%20.pdf
<samueldr> so AFAICT it really looks like a big regression for sandisk and hs400es :/
<lopsided98> That seems right, this is where I bought it: https://ameridroid.com/products/emmc-5-1-module-blank?variant=7427627122722
<lopsided98> you can read sandisk in the image
<samueldr> the model number alone is pretty much confirmation :)
<samueldr> >> High quality storage from SanDisk
<samueldr> under key features
<samueldr> right, so another confirmation for my hunch
<samueldr> now, I think the next best thing is to gather the data I have and scream in the void^W^W^W send to the right mailing list about that subsystem
<lopsided98> I might try enabling dynamic debugging for the mmc subsystem, which should show all commands that are sent to the emmc and their responses
<samueldr> (not saying you shouldn't)
<samueldr> I tried
<samueldr> I didn't grok enough of it all
<samueldr> something around CMD30 IIRC
<samueldr> reaching timeout IIRC
<lopsided98> I was able to figure out this bug that way: https://bugzilla.kernel.org/show_bug.cgi?id=93201#c20
<samueldr> though even adding some sleeps to maybe help some stuff settle that didn't change anything (unsurprisingly)
<samueldr> though you're probably right that this will help figure out the right issue
<samueldr> I kinda side-stepped the issue for now, since I can get hs200 working most of the time
<samueldr> (it sometimes fails, like 1/10 or 1/20 times)
<lopsided98> Mine never works after a reboot, I have to fully power cycle it, usually a few times
<lopsided98> Even when it does work, it hangs for around a minute before the emmc is detected
ryantrinkle has joined #nixos-aarch64
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 268 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 276 seconds]
ryantrinkle has joined #nixos-aarch64
THFKA4 has quit [Quit: WeeChat 2.4]
ris has quit [Ping timeout: 265 seconds]