f_ changed the topic of ##raspberrypi-internals to: The inner workings of the Raspberry Pi (Low level VPU/HW) -- for general queries please visit #raspberrypi -- open firmware: https://librerpi.github.io/ -- VC4 VPU Programmers Manual: https://github.com/hermanhermitage/videocoreiv/wiki -- chat logs: https://libera.irclog.whitequark.org/~h~raspberrypi-internals -- bridged to matrix and discord
CarlFK1 has quit [Quit: Leaving.]
CarlFK1 has joined ##raspberrypi-internals
CarlFK1 has quit [Read error: Connection reset by peer]
CarlFK1 has joined ##raspberrypi-internals
CarlFK1 has quit [Quit: Leaving.]
CarlFK1 has joined ##raspberrypi-internals
CarlFK1 has quit [Quit: Leaving.]
CarlFK has joined ##raspberrypi-internals
jcea has quit [Ping timeout: 272 seconds]
<CarlFK> clever: woo. I see stuff: 1.322518 [EMMC:init_card]: Identification complete, changing clock to 50MHz for data mode ...
<clever> CarlFK: yep, that would be the SD routines coming online, so it can mount fat and load the kernel/dtb
<CarlFK> 1.360240 [LDR:find_and_mount]: Mounting boot partitiion ...
<CarlFK> [MBRDISK:disk_initialize]: Mounting FAT partition 0 of type 0xc
<CarlFK> 1.371993 [LDR:find_and_mount]: Boot partition mounted!
<CarlFK> panic(): "attempted to read zImage, but it does not exist"@loader.cc:157
<clever> CarlFK: yep, the open firmware expects the kernel to be called zImage, rather then the wonky naming scheme RPF uses
<CarlFK> ack. I left my sd card dongle at home.
<clever> CarlFK: which model of pi are you using?
<CarlFK> 3b+
<clever> that one can boot from a usb drive, and lk-overlay supports usb
<clever> so you can use any usb stick, instead of the SD card
<CarlFK> 9.796101 [EMMC:init_card]: ERROR: Failed to query card voltage!
<CarlFK> panic(): "failed to reinitialize the eMMC controller"@drivers/sdhost_impl.cc:624
<clever> CarlFK: was this with the rpi-open-firmware build or the lk-overlay build?
<CarlFK> this: ~/rpi-open-firmware$ scp result/bootcode.bin
<clever> yeah, that one lacks usb support
<clever> you need to switch to lk-overlay
<clever> one minute
<clever> [clever@amd-nixos:~/apps/rpi/lk-overlay]$ nix-build -A vc4.vc4.stage1 -o stage1
<clever> [clever@amd-nixos:~/apps/rpi/lk-overlay]$ nix-build -A vc4.vc4.stage2 -o stage2
<clever> CarlFK: clone down https://github.com/librerpi/lk-overlay (with submodules) and then build both stage1 and stage2
<clever> copy stage1/lk.bin to bootcode.bin on the fat32 partition
<clever> and copy stage2/lk.elf to /boot/lk.elf on the ext4 partition
<CarlFK> [nix-shell:~/lk-overlay]$ time make PROJECT=rpi3-bootcode
<CarlFK> go!
<clever> CarlFK: for booting linux, you want vc4-stage1 and vc4-stage2, rather then rpi3-bootcode
<clever> and stage2 needs some other stuff, nix automates all of it
<CarlFK> Will what I did build that eventually?
<CarlFK> im doing 3 other boring admin things and need to get them done even though this is way more interesting
<clever> rpi3-bootcode is just a demo app, that includes a shell over the serial port and nothing more
<clever> so it wont be able to boot linux
<clever> vc4-stage1 is a proper bootloader, that will load a 2nd stage from ext4, over sd or usb
<CarlFK> vc4-stage1 go.
<CarlFK> clever: time make PROJECT=vc4-stage1 done. where is it?
<clever> CarlFK: build-vc4-stage1 i believe
<clever> you should see it at the end in `ls -ltrh`
<CarlFK> generating image: build-vc4-stage1/lk.bin
<CarlFK> got it
<clever> yep, copy that onto the fat32 paritition, and rename it to bootcode.bin
<CarlFK> booting... seems to be in a loop. likely because there isn't anything else useful on the usb drive
<CarlFK> 30.975486 [EMMC:restart_controller]: hcfg 0xA, cdiv 0x7D0, edm 0x10800, hsts 0x40
<CarlFK> 31.004172 [EMMC:restart_controller]: Restarting the eMMC controller ...
<clever> CarlFK: what partitions are on the usb drive?
<CarlFK> just a fat32
<CarlFK> and no kernel
<clever> you need an ext4 partition as well, on the 2nd slot of the MBR
<CarlFK> actually, there isn't even a partition .. sda is all fat32
<CarlFK> so neat, that works. if that is neet. it was handy.
<clever> ah, lk-overlay cant handle that
<clever> but its neat that the rpi rom can
<CarlFK> woot. time to grab a burrito from burrito house. bb in 10 min.
<clever> gotta head to bed now, we can chat more tomorrow!
<CarlFK> sure thing. sleep well!
Stromeko has quit [Quit: Going… gone.]
Stromeko has joined ##raspberrypi-internals
CarlFK has quit [Ping timeout: 252 seconds]
CarlFK has joined ##raspberrypi-internals
<clever> CarlFK: morning
jcea has joined ##raspberrypi-internals
<CarlFK> clever: morning to you too
<clever> *waves*
<clever> CarlFK: this is a sample script, that generates a disk image, with the proper partition tables, and FS's, with the firmware pre-filled
<clever> `nix build .?submodules=1#disk_image` is enough to have nix build everything for you
<clever> [clever@amd-nixos:~/apps/rpi/lk-overlay]$ fdisk -l result/disk-image.img
<clever> Device Boot Start End Sectors Size Id Type
<clever> result/disk-image.img1 2048 67583 65536 32M c W95 FAT32 (LBA)
<clever> result/disk-image.img2 67584 131071 63488 31M 83 Linux
<clever> and boom, a disk image that should boot stage2
<CarlFK> [nix-shell:~/lk-overlay]$ nix build .?submodules=1#disk_image
<CarlFK> error: experimental Nix feature 'nix-command' is disabled; add '--extra-experimental-features nix-command' to enable it
<CarlFK> add that where?
<clever> [root@amd-nixos:~]# grep flakes /etc/nix/nix.conf
<clever> experimental-features = nix-command flakes
<clever> CarlFK: adding this like to that file makes it permanent, then you never have to think about it
<CarlFK> added... now
<CarlFK> error: flake 'git+file:///home/videoteam/lk-overlay?submodules=1' does not provide attribute 'packages.x86_64-linux.disk_image', 'legacyPackages.x86_64-linux.disk_image' or 'disk_image'
<clever> *doh*
<clever> i added that, and then didnt push, lol
<CarlFK> I've never done such a thing [smug face]
<clever> try a `git pull` and then re build
<CarlFK> its doing stuff
jcea has quit [Ping timeout: 246 seconds]
<clever> CarlFK: ah, ive got some floating point math in there, to benchmark code, and it works fine on vc4/vpu
<clever> but on arm, it cant run, because arm manages the FPU differently
<clever> i fixed it months ago, but never pushed!
<clever> pushed
<CarlFK> push all the things!
<CarlFK> push more!
<clever> ah, pointer size in that case
<clever> gcc complains when i try to %x a pointer, so i cast it to uint32 to make it happy
<clever> but on aarch64, a pointer is 64bit!
<clever> CarlFK: pushed!
<clever> https://hydra.angeldsis.com/jobset/things/littlekernel-overlay#tabs-jobs i should also keep an better eye on CI, its been failing since 2024-06-26
<clever> CarlFK: CI now passes
<CarlFK> error: a 'x86_64-linux' with features {kvm} is required to build '/nix/store/hbrrj96q6pmf70qv02d8finbqqnikq20-disk-image.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, nixos-test, uid-range}
<clever> CarlFK: does /dev/kvm exist?
<CarlFK> ls: cannot access '/dev/kvm': No such file or directory
<clever> intel or amd?
<CarlFK> model name : AMD Athlon(tm) 64 Processor 3500+
<CarlFK> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl cpuid extd_apicid pni cx16 lahf_lm svm extapic cr8_legacy 3dnowprefetch vmmcall
<clever> modprobe kvm-amd
<CarlFK> [nix-shell:~/lk-overlay]$ sudo modprobe kvm-amd
<CarlFK> modprobe: ERROR: could not insert 'kvm_amd': Operation not supported
<clever> check dmesg?
<CarlFK> [222346.165070] kvm: support for 'kvm_amd' disabled by bios
<clever> bingo
<clever> but kvm is optional
<clever> if you want, i can add an override
<CarlFK> please do. I
<CarlFK> the box is 10 min away. and im not sure about monitor/keyboard. so bios setup.. not easy.
<clever> kk
<clever> nix-repl> packages.x86_64-linux.disk_image.requiredSystemFeatures
<clever> [ "kvm" ]
<clever> this is the bit i need to clear...
<clever> looks like i need to whack it with overrideDerivation
<clever> CarlFK: pushed!
<clever> if kvm is missing, then qemu will just use TCG, which is slower but still gets the job done
<clever> its only a 64mb disk image, so its not going to kill anything
<CarlFK> [nix-shell:~/lk-overlay]$ nix build .?submodules=1#disk_image
<CarlFK> no error, but also no anything?
<clever> CarlFK: `nix build` is silent on sucess, check `ls -ltrh` and you should see a recently modified symlink
<CarlFK> got it. result -> /nix/store/xbyrdr35wkwvx4rf4dlh22j08paaqfla-disk-image
<clever> CarlFK: and then `ls -l result/` and youll see a disk image
CompanionCube has quit [Quit: ZNC - http://znc.in]
CompanionCube has joined ##raspberrypi-internals
<CarlFK> result -> /nix/store/xbyrdr35wkwvx4rf4dlh22j08paaqfla-disk-image
<CarlFK> Ill get to booting later - don't have pi stuff handy here.
<clever> CarlFK: ive also been working on something here to help with that kind of problem, a pico-w with uart/jtag/reset pins connected up on an rpi
<clever> so you can remotely debug the pi
HerculeP has joined ##raspberrypi-internals
Herc has quit [Ping timeout: 252 seconds]
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##raspberrypi-internals
<CarlFK> I was looking into jtag hat to debug a pi ... whada ya got?
HerculeP is now known as Herc
<clever> CarlFK: normally, i rig the gpio of one rpi to the jtag(on the gpio) of a second pi
<clever> but that then means i have 2 pi's tied up for a single debugging task
<clever> my plan, is to use a pico-w for the same task
<CarlFK> pico-w - connect to that over usb?
<clever> over wifi
<clever> if i was doing usb, it could just be a pico
jcea has joined ##raspberrypi-internals
jcea has quit [Ping timeout: 246 seconds]