f_ changed the topic of ##raspberrypi-internals to: The inner workings of the Raspberry Pi (Low level VPU/Hardware) -- for general queries about RPi please visit #raspberrypi -- open firmware: https://librerpi.github.io/ -- VC4 VPU Programmers Manual: https://github.com/hermanhermitage/videocoreiv/wiki -- don't ask to ask, just ask (and wait!) -- this channel is logged: https://libera.irclog.whitequark.org/~h~raspberrypi-internals
dolphinana_ has quit [Ping timeout: 252 seconds]
jcea has quit [Ping timeout: 245 seconds]
<f_> clever: Pushing nowè
<f_> *now!
<f_> Shiny new website will appear in a moment.
<f_> There it is.
<f_> Could perhaps add some highlighting.
<f_> (in <pre>
<f_> )
<f_> Also optimised some images so that the website loads quicker.
<f_> (not sure why I didn't do that before.
dolphinana_ has joined ##raspberrypi-internals
<dolphinana_> Hey f_. I see that you pushed some changes to librerpi.github.io. It looks nice, good job! :)
ckx has quit [Ping timeout: 260 seconds]
ckx has joined ##raspberrypi-internals
ckx has joined ##raspberrypi-internals
ckx has quit [Changing host]
angerisagift has quit [Ping timeout: 258 seconds]
angerisagift has joined ##raspberrypi-internals
dolphinana has joined ##raspberrypi-internals
dolphinana_ has quit [Ping timeout: 240 seconds]
<f_> dolphinana: thanks!
<dolphinana> You're welcome f_ :)
<dolphinana> Though I noticed that the URLs in video links are replaced with www.youtube.com. What's up with that? Why switch from Invidious?
<clever> Can't load the video on this Invidious instance. YouTube is currently trying to block Invidious instances. Click here for more info about the issue.
<clever> dolphinana: the instance i was using before is down
<f_> ¯\_(ツ)_/¯
<f_> I honestly don't care. I play videos with mpv anyway.
<dolphinana> Hmm...
<dolphinana> I see..
<f_> and privacy-concerned people can just replace www.youtube.com with whatever instance they want to use
<dolphinana> I almost never play YT videos with mpv. I almost forget that it's possible :P
<dolphinana> Anyway, can't load that video on invidious.snoopyta.org either. I get the same error :/
<f_> try yewtu.be
<clever> one solution, just commit mp4's to the docs repo
<clever> <video> them
<clever> who needs anything fancy?
<dolphinana> Maybe you can consider putting Invidious redirector: https://redirect.invidious.io/ or...
<f_> could be better since these videos are short..
<dolphinana> yeah, mp4's in the repo would be a great idea!
<f_> but then..
<dolphinana> or you could consider uploading these videos on peertube :P
<dolphinana> *a peertube instance I meant
<clever> dolphinana: did you see this one?
<dolphinana> Yooo
<dolphinana> bad apple on librerpi :D
<dolphinana> I tried to compile that module but I failed :P
<clever> the arm core isnt even enabled
<clever> ah yeah, you mentioned that
<clever> what error did it give?
<dolphinana> so it runs entirely on the vc4?
<clever> yep
<dolphinana> I don't remember what errors I got
<clever> try turning it on again, and see what happens
<dolphinana> My main lk-overlay directory is filled with printf debugs and stuff :D I should copy that directory and then git reset that copy (I don't like using git branches :P)
<clever> there is also worktrees
<clever> first, youll need a branch, because you cant checkout a branch in 2 places, `git checkout -b foo` i think?
<clever> then `git worktree add ../lk-overlay-master master`
<clever> both directories will share the .git, but have different branches checked out
<dolphinana> I'll try that
<clever> i should also setup a bad-apple project, and point CI at it
<clever> then you can build it without editing files
<dolphinana> I tried that worktree method and now some submodules are missing :/
<clever> you probably need to init them in the copy
<clever> `git submodule init ; git submodule update` i think it was
<clever> build-stage1-bad-apple/lk.elf section `.rodata' will not fit in region `ram'
<clever> region `ram' overflowed by 12452 bytes
<clever> hmmm, need to shave 12kb off the binary...
<clever> if i omit bad-apple, its 99kb in size...
<dolphinana> it seems like it redownloaded the submodules
<clever> ah, i think linker gc was to blame on my end
<clever> [nix-shell:~/apps/rpi/lk-overlay]$ scp build-stage1-bad-apple/lk.bin root@system76:/mnt/bootcode.bin
<dolphinana> so, how should I compile the bad apple module? Should I have it in stage2?
<f_> You can do quite a lot on the VC4.
<clever> dolphinana: i believe it works in both vc4-stage1 and vc4-stage2
<dolphinana> Yeah, I could tell that after seeing the videos of librerpi and playing around with librerpi :P
<clever> if in stage1, youll want to remove the stage1 app
<clever> if in stage2, remove the arm module
<clever> thats also why i'm preparing dedicated project files
<dolphinana> I never got video output to work with stage1
<clever> it needs to include the vec module to get ntsc video
<clever> CONFIG_GFX turns that on
<dolphinana> I should go eat. See ya :)
<clever> i seem to be having baud rate issues.....
<f_> clever: IIRC I did add PAL support right?
<clever> f_: partially, havent tested it 100%
<f_> which would make sense if we were all using CRTs..but makes no sense now because most, if not all modern TVs support both PAL and NTSC
<clever> Nov 01 14:35:57 router tftpd[4050088]: tftpd: trying to get file: bootcode.bin
<clever> Nov 01 14:35:58 router tftpd[4050106]: tftpd: serving file from /tftproot
<clever> to speed up testing, i switched to my pi3, which can netboot
<clever> so i just upload to the tftp server, and reset
<clever> no more card-swapping
<clever> [nix-shell:~/apps/rpi/lk-overlay]$ scp build-stage1-bad-apple/lk.bin root@router:/tftproot/bootcode.bin
<clever> now it works, lol
<clever> vec rate: 0.000000, plla: 500000000, pllc: 500000000
<clever> theres my problem
<f_> vec issues again?
<clever> i changed the pll frequency setup
<clever> so it cant divide 500 cleanly to 108
<f_> I see.
<clever> before, the PLL clock was hard-coded into platform.c
<clever> and its difficult to find one frequency that makes everything happy
<clever> but now its a makefile variable
<clever> so i can just set `PLLA_FREQ_MHZ := 432` in the project file
<clever> ref: 432000000, target: 108000000, divisor(f): 4.000000, divisor(fixed): 0x4000
<clever> vec rate: 108.000000, plla: 500000000, pllc: 500000000
<clever> debug print is a lie, but it now gets 108mhz
<clever> vec rate: 108.000000, plla: 432000000, pllc: 500000000
<clever> debug print is no longer a cake
<f_> speaking of debug prints
<clever> [nix-shell:~/apps/rpi/lk-overlay]$ vc4-elf-objdump -t build-stage1-bad-apple/app/bad-apple/bad-apple.c.o
<clever> SYMBOL TABLE:
<clever> 00000000 g O usb_hooks 0000000c _hooks_bad_apple
<clever> [nix-shell:~/apps/rpi/lk-overlay]$ vc4-elf-objdump -t build-stage1-bad-apple/app/bad-apple.mod.o
<clever> 00000000 g O usb_hooks 0000000c _hooks_bad_apple
<clever> but its then missing from the main lk.elf
<clever> the linker ate it
<clever> oops
<clever> that usb stick had raspi-os on it
<clever> its booting the wrong thing, lol
<f_> oops
<clever> where did those other usb sticks go....
<clever> f_: *facepalm*, on the end of the usb hub, whose other end is under the pi i'm testing!
<clever> yep, stage1-bad-apple works
<f_> haha
<clever> 12.585176 [DWC2:tuh_mount_cb:42]: Device attached, address = 1
<clever> when i boot stage1-bad-apple, it now prints this line, because it detected a usb hub
<clever> 53.413574 [DWC2:tuh_mount_cb:42]: Device attached, address = 2
<f_> DWC2!
<clever> if i plug in a usb drive, this pops up
<clever> mbr partition table dump:
<clever> 1: status 0x80, type 0x83, start 0x13000, len 0x765000
<clever> 53.611961 [badapple:bad_apple_main:391]: starting
<clever> 54.074198 [badapple:play_video_once:147]: 6572 frames found
<f_> after writing synopsys DRAM init on amlogic, I love synopsys now
<clever> and it begins playing video
<clever> f_: i still dont know who made the dram controller on the vc4, care to take a look and see if its familiar?
<f_> register names look different, on first sight
<clever> yeah, that was likely, if using diff headers
<f_> not really likely
<clever> more about the bit fields, and layout of the registers
<f_> Amlogic dram register names compared to Rockchip dram register names are very similar
<clever> linux refers to some rpi registers by a different name, vs the official broadcom headers
<clever> dolphinana: if you do a pull, and try `make PROJECT=stage1-bad-apple` does it work?
<f_> hmm doesn't look much similar compared to my code
<f_> which I still have to clean up, document, and port to a newer SoC
<clever> ah, so no closer to knowing who made this beast
<dolphinana> Oh, hi clever, I can try pulling
<dolphinana> building it...
<f_> clever: many arm SoCs use synopsys/DWC dram
<dolphinana> generating the bin because I deleted the previously generated bin file.
<dolphinana> ooh, 136 MB bin file :P gotta use a different SD card (I was about to use the 128 MB SD card but I guess I'll be sticking with 1GB instead)
<clever> dolphinana: the code also requires that the .bin and .wav live on usb
<dolphinana> oh
<clever> it was more of a usb stress test project, at first
<dolphinana> so I need a USB flash drive?
<clever> yeah
<clever> bootcode.bin on sd, bad-apple.bin and bad-apple.wav on usb
<dolphinana> ahh
<dolphinana> okay
<clever> usb drive is formatted ext4
<dolphinana> hold on, let me look for the USB drive :P
<dolphinana> omg... my drawer is a mess xD
<clever> as is mine
<clever> it took half an hour to find a usb stick, lol
<clever> it was plugged into a usb hub, behind the monitor, with the other end laying right next to the pi i was testing, lol
<dolphinana> Ooh, I found multiple USB sticks in a glasses case
<f_> :P
<dolphinana> Do files have to be in the first partition?
<clever> i believe they can be on any partition
<clever> the usb code tries to just blindly mount everything as ext2/4
<clever> and then tries to open bad-apple.bin and bad-apple.wav
<dolphinana> I'll just try putting it on the second partition which is formated as ext4
<clever> if the files cant be found, umount and try the next partition!
<f_> clever: so theoretically I could replace bad-apple with a rickroll?
<dolphinana> Okay, I think I got the SD card and the USB drive ready :P
<dolphinana> f_, yes!
<clever> f_: yeah, but the current code has a fixed resolution and 1 bit per pixel
<dolphinana> I'm not clever but I felt like answering your question
<f_> so I'd need to adapt the code, but it's possible!
<clever> f_: either scale the input first, or change this res here
<clever> f_: this code will use ffmpeg to convert the video to a pile of png files, then open each, and convert it into 1 bit per pixel raw video
<clever> * ffmpeg -i 【東方】Bad\ Apple\!\!\ PV【影絵】\ \[FtutLA63Cp8\].webm 'frame%04d.png'
<dolphinana> It's running!!! :D
<clever> and thats how you generate the png's
<clever> i think you can tell ffmpeg to scale the image as it generates
<clever> dolphinana: and you should have audio as well!
<f_> or just change the height/width!
<clever> f_: throwing a header at the front of the .bin would help there
<dolphinana> Well, I don't hear anything :/
<clever> *checks*
<f_> faulty audio composite cables?
<f_> easiest thing to check
<clever> dolphinana: i forgot to include pi1 in this switch-case block
<clever> each model has the audio on a different pair of pins
<clever> for the original 26pin pi1, the audio is on 40 and 45
<clever> dolphinana: if you run otp_pretty_print over the uart, what type does it list?
<dolphinana> I can try
<dolphinana> just wait...
<clever> according to my notes, pi1/pi2 are all 40/45
<clever> and types 1 and 3, are the original pi1
<f_> rpi1 is awesome
<f_> It has full schematics.
<clever> yep
<clever> they tried to delete them :P
<clever> but git never forgets
<f_> git never forgets
<clever> then they just removed schematics from git :P
<dolphinana> woah, rpi1 has full schematics and they tried to delete them :O
<f_> yup
<clever> schematics/datasheets are no longer in the documentation repo
<dolphinana> why?
<f_> ¯\_(ツ)_/¯
<dolphinana> well, it's kind of guessable
<f_> broadcom stuff I think
<dolphinana> but still...
<clever> somebody bought a sample batch of bcm2835's from broadcom
<clever> then made a knock-off rpi board, and violated the rpi firmware license, by running it on a non-rpi product
<f_> lol
<clever> broadcom has never sold outside large companies since
<dolphinana> run librerpi on the knock-off board then :P problem solved :P
<f_> since then rpi only publish partial schematics..
<clever> dolphinana: ive mentioned before, making a board with the "wrong" crystal or putting the SD slot on the "wrong" pins, is the perfect solution here
<clever> it will no longer be compatible with the rpi firmware
<clever> so you cant violate the license
<dolphinana> ahh, nice :P
<clever> and the open firmware can fix that with a simple edit
<f_> but then again, rpi isn't OSHW.
<clever> and without a source of SoC's, you cant make those boards
<clever> with this tweak, pi1 should now have audio
<dolphinana> ok, ran otp_pretty_print and got an output:
<clever> Raspberry-Pi-Rev-1.0-Model-AB-Schematics.pdf is the schematic filename...
<clever> searching thru `git log --patch` ....
<clever> commit 6b0c2173dc3dd2fe0449bf598d91fd6aa7d4fd73
<clever> boom, full schematics!
<f_> haha
<clever> dolphinana: oh, wow, youve got the old style revision codes!
<clever> just revision e!
<dolphinana> well, I have a working shell that runs on old librerpi version
<dolphinana> umm
<dolphinana> do I have to run it on newer version?
<dolphinana> wait
<dolphinana> oh
<clever> no, this is a hardware thing
<dolphinana> yeah, I realized
<clever> i'll need to add extra code to handle this case...
<f_> commit where they tried to remove RPi1 schematics
<f_> >Update schematics
* f_ afk
<dolphinana> "Update schematics" :D hahaha ;P
<clever> dolphinana: they have since removed all schematics/datasheets from that repo
<dolphinana> very good description ^^
<clever> if you want docs, you must go to either datasheets.raspberrypi.com or pip.raspberrypi.com
<clever> datasheets.raspberrypi.com is just some javascript over an aws s3 bucket
<f_> dolphinana: indeed ^^
<clever> pip.raspberrypi.com is a custom ui, for browsing many things, including docs hidden behind NDA
<f_> ahh lol
<clever> both lack history
<dolphinana> woah, docs hidden behind NDA?
<clever> yeah
<dolphinana> why do they have it there?
<clever> sometimes its features in beta testing
<clever> and it goes public after the testing is done
<clever> but due to the secrecy of nda, its hard to know what else they are hiding :P
<clever> i would assume the pi5 docs where also hidden under the nda section, until the pi5 announcement occured
<clever> ive heard that some tech/game demos also have a short 3 day NDA, so they can fully inform the news crew, and not let any one news outlet have an unfair advantage
<clever> no snap news article based on half a presentation
<clever> dolphinana: ive also pushed another change for the pi1
<dolphinana> yeah, I see it
<dolphinana> Let's try it :P
<dolphinana> wait, where will audio output? The 3.5mm audio jack?
<clever> yeah
<dolphinana> I heard nothing, but I'm not completely sure if I did the thing right
<clever> what does it log to the console?
<clever> rate: 48000
<clever> bytes/sec: 192000
<clever> bytes per 2 samples: 4
<clever> this is a section of the .wav debug logs, showing that its parsing the audio
<dolphinana> oh, I think I forgot to build it
<clever> ah, thatll do it
<dolphinana> so I probably accidentally copied the old build :o
<clever> && helps with that
<clever> [nix-shell:~/apps/rpi/lk-overlay]$ make PROJECT=stage1-bad-apple && scp build-stage1-bad-apple/lk.bin root@router:/tftproot/bootcode.bin
<clever> this will build, and then copy, in one shot
<clever> and if the build fails, it wont copy
<f_> that's exactly how && works
<clever> yep, thats why i use it
<dolphinana> wow, good to know :)
<dolphinana> I always use && when I want to execute commands in "sequence"
<dolphinana> but I didn't know that it for instance wouldn't execute another command if the first one failed
<clever> it relies on the exit code of the commands
<clever> so the 1st command has to return a code of 0
<dolphinana> The audio is working
<clever> nice
<dolphinana> Well, this is amazing. This might be the coolest thing on librerpi :D
<clever> -rwxr-xr-x 1 clever users 111K Nov 1 16:41 build-stage1-bad-apple/lk.bin
<clever> and the entire program, fits within 111kb of code!
<clever> its also hotplug driven
<clever> when the video finishes playing, unplug, and re-plug the usb
<clever> and it should play again
<dolphinana> ah, I didn't know I could do that
<clever> 247.258305 [badapple:play_video_once:147]: 6572 frames found
<clever> oops
<clever> Fatal VPU Exception: Misaligned
<clever> seems i broke that at some point
<dolphinana> We are hanging here ...
<dolphinana> it crashed when I unplugged and replugged the USB
ckx has quit [Ping timeout: 255 seconds]
<clever> same when i replugged
<clever> at the top, you can see it detected the usb drive, mounted it, and found the files
ckx has joined ##raspberrypi-internals
ckx has quit [Changing host]
ckx has joined ##raspberrypi-internals
<clever> and the "bad apple vidoe" thread was in the "run" state when it crashed
<clever> and the PC register in that dump, is within hvs_dlist_add
<clever> so its a bug due to trying to display the sprite twice
<dolphinana> This error looks very similar to the one I get
<clever> testing a fix...
<clever> the slow part, is that i have to wait for the full video to play
<clever> and it doesnt deal with removing an in-use usb drive
<dolphinana> oof XP
<clever> now it fails in mutex_acquire_timeout
<clever> 169 // schedule dlist update on next vsync
<clever> 170 mutex_acquire(&channels[channel].lock);
<clever> this one
<clever> added more prints, and now i repeat
<clever> *facepalm*
<clever> the sprite i'm adding, is on the stack
<clever> so when the thread dies, it gets corrupted
<dolphinana> how's it going?
<clever> waiting for the video to play
dolphinana_ has joined ##raspberrypi-internals
<clever> dolphinana: works! pushing....
<clever> pushed
<dolphinana_> I'll try
<clever> in theory, you could have multiple usb sticks, each with a different video
<clever> and when playback is done, swap it out
dolphinana has quit [Ping timeout: 260 seconds]
<dolphinana_> Did you just fix it by adding a line of code?
<dolphinana_> > list_delete(&bad_apple_layer.node);
<clever> yep
<clever> bad_apple_layer is held on the stack, and was part on a linked list
<clever> when the thread dies, it gets overwritten with junk
<clever> then when it tries to add another element to the linked list, *boom*
<dolphinana_> It's somehow slower now and the audio is "cracking" even more
<dolphinana_> oh, now it's somehow at normal speed but the audio is still kind of "cracky"
<clever> sounds like an issue with IO performance
<clever> it has zero read-ahead and buffering
<clever> it will report thread cpu usage% at the end of playback
<clever> ive also had trouble getting the audio cleaned up, and then got distracted and never finished that player
<clever> play time: 42011 uSec
<clever> what number are you getting from these lines? is it printing others?
<dolphinana_> Hey, unplugging and replugging will play the video again now. Good!
<clever> nice!
<dolphinana_> I'll check that report when the video has finished
<clever> (bad apple audio):
<clever> Total run time: 11790876, 2.46%
<clever> (auto_host):
<clever> Total run time: 4402458, 0.92%
<clever> one slightly tricky part, for higher accuacy, the percentage is time since boot
<clever> so if the thread used 30 seconds of cpu, but the uptime is 1 hour, thats 0.8% cpu usage
<clever> even if the thread was only alive for 60 seconds, which should have been 50%
<clever> 257.110004 [badapple:bad_apple_main:403]: audio file 42065722 bytes
<clever> 477.810601 [badapple:bad_apple_audio:299]: audio EOF
<clever> with these 2 lines, you get timestamps of when it was playing
<clever> so it spent 220.7 seconds playing video
<clever> > (11790876 / 1000000) / 220.7
<clever> 0.05342490258269144
<clever> which then leads to 5% for the audio thread
<clever> (bad apple video):
<clever> Total run time: 10076009, 2.10%
<clever> and 4% for video thread
<clever> but, the auto_host thread, is where half the usb stuff runs, and it didnt restart with the video
<clever> Total run time: 2897742, 1.12%
<clever> Total run time: 4402458, 0.92%
<clever> it gained 1.5 seconds of runtime, over playing the video, not much
<dolphinana_> https://bin.vitali64.duckdns.org/6542bbbe (ignore the error message about ttyUSB0 lol)
<f_> Hey! Abusing my pastebin!!! -j
<dolphinana_> Yeah, we abuse your pastebin >:D
<dolphinana_> hehehe ;P
<clever> dolphinana_: looks fairly fine, i dont think its a cpu usage issue
<f_> I should probably maintain that pastebin software again
<f_> Add some new features and whatnot..
<clever> f_: 2 main things i notice are missing, after making a paste, you get a partial link, and no line numbers
<clever> bbl
<f_> sure
jcea has joined ##raspberrypi-internals
dolphinana has joined ##raspberrypi-internals
dolphinana_ has quit [Ping timeout: 240 seconds]
juri_ has quit [Ping timeout: 264 seconds]
juri_ has joined ##raspberrypi-internals
jcea has quit [Quit: jcea]
jcea has joined ##raspberrypi-internals
juri__ has joined ##raspberrypi-internals
juri_ has quit [Ping timeout: 255 seconds]
juri__ is now known as juri_