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
jcea has joined ##raspberrypi-internals
<bonda_000> rewriting some of the vc4 headers in cmsis-compliant style. should finish A2W (A2Wfully big) tomorrow
<clever> cmsis-compliant style?
<bonda_000> via typedef so peripheral register access is PERIPH->REG
<bonda_000> ideally shouldn't need to write any assembly if we have a compiler and proper headers
<bonda_000> good night I'm gonna go get some sleep now
bonda_000 has quit [Quit: Leaving]
<clever> ah, structs at each peripheral
jcea has quit [Ping timeout: 268 seconds]
jcea has joined ##raspberrypi-internals
wael has quit [*.net *.split]
clever has quit [*.net *.split]
clever has joined ##raspberrypi-internals
wael has joined ##raspberrypi-internals
Stromeko has quit [Ping timeout: 255 seconds]
Stromeko has joined ##raspberrypi-internals
user_user has joined ##raspberrypi-internals
jcea has quit [Ping timeout: 268 seconds]
user_user has quit [Ping timeout: 255 seconds]
bonda_000 has joined ##raspberrypi-internals
f_ has joined ##raspberrypi-internals
<dolphinana> Hi, I haven't actually said this here until now, but today I'll actually be giving a talk called "Raspberry Pi's liberation progress" at LibrePlanet!
<jn> nice!
user_user has joined ##raspberrypi-internals
<f_> dolphinana: Nice! :D
<f_> Have fun!
<dolphinana> thank you f_! ^^
user_user has quit [Ping timeout: 256 seconds]
f_ has quit [Read error: Connection reset by peer]
f_ has joined ##raspberrypi-internals
<clever> dolphinana: ah nice!
<dolphinana> hi clever! ^^
<clever> i also have a pre-made disk image you could test out
<dolphinana> I could test it out
<clever> dolphinana: https://hydra.angeldsis.com/build/114966 boot.tar contains the stage1/stage2/linux, that are known to work
<clever> the design, is that you mount ext4 to /mnt, then fat to /mnt/boot/firmware
<clever> then just unpack the tar in /mnt/
<dolphinana> I'll test it out later once I'll be using my RPi take take some photos for the slideshow (doing some last hours preparation)
<clever> then fill in a rootfs of your own choice, and as long as the initrd is within the size limit, it will work
<clever> 2 more things coming up...
<clever> dolphinana: here is a record of me using boot.tar and debootstrap to install debian
<clever> librepi-firmware.deb is just boot.tar, repacked into a .deb file, so dpkg can keep track of things
<clever> i did have a complete nixos image on my hydra server, but it looks like the garbage collector ate it
<clever> dolphinana: https://hydra.angeldsis.com/machines my build cluster is winding up, trying to reproduce that old image...
<dolphinana> mhm...
<dolphinana> I'm a little unsure if I have time to test the pre-made disk image at the moment, but when I do, I'll tell you.
<clever> i was thinking more as a pre-made finished product, to skip all of the debug, or as an example of what it can look like when done
<dolphinana> yeah, I understand
<dolphinana> right now I'm working on slideshow...
dolphinana_ has joined ##raspberrypi-internals
dolphinana has quit [Ping timeout: 246 seconds]
dolphinana_ has quit [Read error: Connection reset by peer]
dolphinana_ has joined ##raspberrypi-internals
bonda_000 has quit [Remote host closed the connection]
bonda_000 has joined ##raspberrypi-internals
f_ has quit [Remote host closed the connection]
f_ has joined ##raspberrypi-internals
<clever> dolphinana_: ah, and hydra seems to be finishing the build!
<clever> if all went according to plan, you can just uncompress that disk image, write it to an SD card, and it should boot into nixos on a pi2
<dolphinana_> hi
<dolphinana_> sorry for not being active, I'm very busy right now
<clever> sure
<bonda_000> :clever have you found where the USB/Ethernet section is in the bootcode? Trying to figure out what the core clock frequency is
<bonda_000> bootrom*
<clever> bonda_000: it would be faster to work backwards, label the clock registers, and then check for xrefs
<clever> CM_VPUDIV and CM_VPUCTL
<clever> labeling those, i can see a function at offset 5b8
<clever> the function at offset 470, its checking the OTP, to see if you have a 19.2mhz or 54mhz crystal
<bonda_000> return (*(uint *)(unaff_gp + 0x10) >> 1 & 1) == 0;
<bonda_000> this?
<clever> yeah, thats the one
<clever> i labeled it `crystal_is_fast()`
<clever> just looking at the numbers i'm seeing, it looks like 500mhz
<bonda_000> return false; after I set gp=0x60008000
<bonda_000> it's dangerous though whatever is at 60008000 is not in the bootrom
<clever> because thats a variable
<bonda_000> but in the sram
<clever> did you tag that region of memory as +w?
<clever> in the memory pane
<bonda_000> what's +w
<bonda_000> no I haven't but isn't sram flashed at factory?
<clever> no
<clever> sram is ram
<bonda_000> or it loses data when power goes off
<clever> its r/w
<clever> thats where variables are stored
<clever> yes
<clever> you need to check the W box for the sram
<clever> this is what i get after tagging it all
<bonda_000> so sram on my device apparently starts at 60008000 and is C000 bytes long?
<clever> i think its 0x8000 long
<clever> at a quick glance, i think this code is setting up PLLC for 1ghz, and then CM_VPU to be 1ghz/2
<clever> which is the stock clock speed for the VPU
<bonda_000> "bootmode" did you name it yourself
<bonda_000> ?
<bonda_000> at the very end
<clever> yes
<clever> other code sets that, based on values from the OTP
<bonda_000> so my dumpbootrom also dumped my OTP?
<clever> nope
<clever> the OTP can only be read with special functions
<bonda_000> well it wrote that to RAM and now it computes to return false
<clever> thats more that you dumped the state of the ram, not the OTP itself
<clever> so it could have been changed by other things, and doesnt hold all of the OTP
<bonda_000> yeah that's definitely dangerous to do then
<bonda_000> plus this elf is "hand_made" so not everything I do with start_x.elf can be safely applied here
<clever> the other problem, is if you tag a region of memory as read-only, then ghidra will make assumptions, based on the fact that it can never change
<clever> but if it can change, those assumptions will be wrong
<clever> i can see ~4 solutions to your baud rate issue
<clever> 1: just write to CM_VPU{DIV,CTL} and set it back to 19.2mhz
<clever> 2: re-compute the baud rate divisor for 500mhz
<clever> 3: just use the PL011
<clever> 4: measure the "wrong" baud rate with a scope/la (or math it out), and then just set minicom to that "wrong" rate
<clever> its running ~26x faster, so that would simply be 3000000 baud
<clever> 1/3 are more bullet proof and will just work, no matter how it boots
<clever> 2/4 will only work if your booting via usb
<dolphinana_> I'll soon be giving my LibrePlanet talk
<bonda_000> just tried 500Mhz still garbage gonna try 400 and 250
<clever> bonda_000: how did you try 500mhz?
<bonda_000> I just changed my code it was assuming we booted with system clock running off of a 19.2 crystal
<bonda_000> 19.2Mhz
<bonda_000> hermanhermitage/dumpbootenv
<clever> bonda_000: and what did you change within that?
<bonda_000> all the way up top equ(SYSTEM_CLOCK, 250000000)
<clever> the SYSTEM_CLOCK ?
<clever> *checks math*
<bonda_000> yeah
<clever> so that would result in a baud divisor of around 541
<clever> i would expect that to work
<clever> youll need to measure the actual baud rate with a scope or LA, and see what it is
<clever> and then adjust from there
<bonda_000> or read the CM register value
<clever> but you cant print that without a working uart
<clever> so you need to fix the uart first
<bonda_000> right but I can do the maththere
<bonda_000> oscilloscope sounds easier though
<bonda_000> so with SYSTEM_CLOCK=250000000 the frequency on the scope of the TXD pin is 21.74Khz
<clever> thats too slow
<bonda_000> 21.55Khz
<clever> you want the frequency (the shortest period between 2 edges, not the same edge) to be 115.2khz
<bonda_000> I get it
<bonda_000> just trying to substitute it into the formula to get the system clock right now
<bonda_000> its running at 47178819
<bonda_000> 47178819hz
<bonda_000> the system clock
<bonda_000> 47.178MHz
<bonda_000> after the ethernet boot
<bonda_000> not very accurate
<bonda_000> one sec
<clever> if you update SYSTEM_CLOCK and measure the clock again, what does it say?
<bonda_000> 50080800Hz
<bonda_000> 50.080MHz the most accurate I can measure
<bonda_000> let me try with this value
<clever> its probably just 50mhz then
<bonda_000> still reading garbage with 50MHz
<bonda_000> 23.1Khz on the scope
<clever> are you measuring between a rising and falling edge?
<bonda_000> from rising edge to rising edge
<bonda_000> that's when I put 250 000 000 into hermanhermitage/dumpbootenv.s file
<clever> that will give the wrong rate
<clever> you want to measure from different edges
<bonda_000> ?
<clever> rising to falling, or falling to rising, and it must be the shortest one
<clever> thats just how uart works
<bonda_000> baud rate = frequence
<bonda_000> frequency
<bonda_000> f = 1/T
<bonda_000> T is a period of a full cycle
<clever> 115200 baud, means you will have 115200 edges per second
<clever> your measuring the time it takes to produce 2 edges, which gives the wrong answer
<bonda_000> ok then 100Mhz
<clever> can you post a photo of the scope readings?
<bonda_000> yep got it
<bonda_000> 100Mhz it now writes good values
<bonda_000> after usb/ethernet boot RPi3B year 2015 rev1.2 runs at 100Mhz
<clever> ah bingo
<clever> now that you said its off by a factor of 5, i checked the decompile again
<clever> this does a /5 to the clock
<clever> thats why i was off
<bonda_000> CORE0R is the divider?
<clever> there are several divisors at play
<clever> first is the main PLLC divisor, so `output/divisor==19.2mhz`
<clever> that PLLC then goes into 4 taps, core0 thru core2, and periperal, each divides it differently
<clever> then the VPU clock in the core-muxes group divides it once more
<bonda_000> yeah I've seen the undocumented Pi page on the clock system
<bonda_000> didn't analyze it thoroughly but saw they are all derived from the crystal
<bonda_000> all that matters is that you dont feed hardware frequency above the maximum rating
<bonda_000> like I was running ARM timer at 400Mhz and the datahsheet said its designed to work at 250Mhz
<bonda_000> I just rewrote your sdram code for my vpu.h header
<bonda_000> it's what runs in lk right? sdram.c?
<clever> yeah
<bonda_000> here
<bonda_000> let me upload
<bonda_000> I mean I will probably have to rewrite it again with bit fields defined but doing that when none of that is documented what those bit fields mean isn't much of a difference
<clever> you probably want a seperate bootloader and kernel, because this first stage is limited to 128kb of code
<bonda_000> good point
<clever> you could also use either the closed bootcode.bin or the lk-overlay vc4-stage1 bootcode.bin
<bonda_000> what's closed bootcode.bin?
<bonda_000> it start the ARM
<bonda_000> I dont want to enable ARM
<bonda_000> starts*
<clever> bootcode.bin cant start the arm
<clever> its not capable of it
<clever> all it does is bring the ram online, and load start.elf
<clever> start.elf runs on the VPU
<clever> so you can then shove all of minix into start.elf
<bonda_000> oh I thought it started the ARM
<bonda_000> damn
<clever> its start.elf's job to start the arm
<bonda_000> but it's gonna apply fixup to my custom elf
<bonda_000> that's what I also don't want to happen right?
<clever> but if you delete fixup.dat it cant
<bonda_000> is it going to pull start_x.elf from tftp as well?
<clever> only if you set start_x=1 in config.txt
<clever> > or the lk-overlay vc4-stage1 bootcode.bin
<clever> that one is fully open source, so you can just modify the source to do whatever you want
<bonda_000> well there's just quite few unknowns in what state the system is after each loading stage
<bonda_000> what I'm trying to do is eliminate these unknowns to be able to write the hardware layer
<bonda_000> for the OS
<bonda_000> like the clocks, the PLLS
<bonda_000> so bootcode.bin can be 128KB at most?
<clever> yeah
<clever> and your stack and .bss must also fit within that limit
<bonda_000> by the way. the interrupt handling
<bonda_000> do I pass the address of the vector table to the interrupt controller?
<clever> yes
<bonda_000> IC0 irq table for core0 and IC1 irq table for core1?
<clever> yep
<bonda_000> I think in my systems they are going to share one irq table
<bonda_000> system*
<bonda_000> because all the handling goes to the kernel anyway
<bonda_000> like it is in yours!
<bonda_000> the only thing that's different is probably the clock
<bonda_000> for both cores
<bonda_000> I don't want both cores run off the same Compare value and get interrupted simultaneously?
<clever> they have seperate interrupt mask config
<bonda_000> oh so pretty much half the interrupts are routed to core0 and the other half to core1/
<bonda_000> ?
<clever> you can route them however you want to route them
<bonda_000> so if two cores are using the ST as the clock
<bonda_000> and we want to switch tasks every 1ms
<clever> thats why there are 4 compare channels
<clever> ST_C0 thru ST_C3
<bonda_000> yeah but they should have the same deltas
<bonda_000> no?
<bonda_000> core0 and core1
<clever> they can if you want them to
jcea has joined ##raspberrypi-internals
<dolphinana_> hii
<dolphinana_> done with the talk
<clever> getting my pi2 going again
<clever> first, i'm imaging an old uSD card, so i can preserve the OS
<dolphinana_> clever, thanks for watching my talk ^^
<dolphinana_> I had some difficulty doing the talk, but I hope it's fine.
<clever> your welcome
<clever> yeah, i dont do well with public speaking either
<clever> pv says 56mins to image this SD card
f_ has quit [Ping timeout: 260 seconds]
<clever> gonna go watch some tv upstairs while that images, then i can begin poking at pi2 stuff
<dolphinana_> oki, see you later clever
bonda_000 has quit [Ping timeout: 240 seconds]
f_ has joined ##raspberrypi-internals
<clever> [root@system76:~]# mount -v /dev/mmcblk0p1 /mnt/
<clever> dolphinana_: so first, i mount my fat partition on the laptop (it has an SD slot)
<dolphinana_> mhm
<clever> [nix-shell:~/apps/rpi/lk-overlay]$ make PROJECT=vc4-stage1 && scp build-vc4-stage1/lk.bin root@system76:/mnt/bootcode.bin
<clever> then i build and copy the bin over
<clever> now i have to figure out where my uart adapter went to...
<clever> 0.478619 [VPU:PLATFORM:platform_init]:
<clever> uart 0 base 0x7e201
<clever> dolphinana_: and then i get logs up to here, and it dies...
<dolphinana_> I see
<dolphinana_> right now I'm quite tired so I won't be doing much right now
<clever> because i have uncommited changes, setting the baud to 9600, oops
<clever> and now i get the expected logs
<clever> now that ive confirmed the basics, let me try the disk image i linked earlier
<clever> [root@system76:~]# cat nixos-sd-image-20.09pre-git-armv7l-linux.img.zst | unzstd > /dev/mmcblk0
<clever> [ 0.000000] INITRD: 0x00000000+0x0074e000 is not a memory region - disabling initrd
<clever> ah dang, same problem you had!
<clever> [ 13.803317] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<clever> going to watch a bit more tv, then take a stab at that
<clever> 2.367010 [LDR:read_file]: initrd: reading 7656797 bytes to 0x4000000 ~64mb...
<clever> [ 0.000000] INITRD: 0x00000000+0x0074e000 is not a memory region - disabling initrd
<clever> something seems corrupted there, i'll have to investigate more
<dolphinana_> oooh, seems like things are going on o.o
<dolphinana_> btw, someone asked me this question regarding librerpi: Was there any guiding principle of writing code (Keep It Simple Silly (KISS) or Don't Repeat Yourself (DRY) principle or pragmatism?
<clever> mostly just whatever feels right
<dolphinana_> I see
<clever> and trying to make reusable functions when possible
<dolphinana_> I'll forward this to the person who asked this question
<clever> for example, this is something that feels wrong, i need to generalize it, for any yuv420 image, and move it to hvs.c
<clever> i just forgot about it, for ..... 2 years
<clever> but you can see how well commented it is
<dolphinana_> I see
<dolphinana_> clever, they were also wondering: "Does the project have an end goal or will you work and maintain it until the hardware operates?"
<clever> dolphinana_: the goal is to basically just support every model of pi and help the users do whatever they want with the hw/firmware
<clever> but some models like the pi5 look like a dead-end, the boot chain is well signed, no messing with that
<dolphinana_> thanks for the answer clever ^^
<clever> and the pi4 has a huge hurdle, figuring out lpddr4 init
<clever> so that just leaves the pi0-pi3, which are already getting old
<dolphinana_> I was thinking about talking about Pi4 and 5, but I didn't really find time for that plus I don't have any experiences with these models
<clever> dolphinana_: https://i.imgur.com/NYRkHHw.png this is similar to one of the slides in your presentation
<clever> during boot, you can take a single path down this graph
<clever> and at each stage, you have several choices on which version of the stage you use
<clever> plus limitations on what the previous stage supports reading from
<dolphinana_> I recognize this picture
<clever> https://i.imgur.com/Pzs52Bx.png the original pi4 firmware looked like this
<clever> i can replace both stage1 and stage2, but replacing a stage turns it into a dead-end
<clever> without lpddr4 drivers, a custom stage1 cant bring dram online, so its limited to 128kb of ram
<clever> without revised arm drivers, a custom stage2 cant bring the arm online, so no linux
<clever> the color signals if the source is available or not
<clever> later in its life, the pi4 firmware switched to https://i.imgur.com/uH0tG3O.png
<clever> they basically sliced the stage1 in half, the new stage1 only does dram init, and the stage 1.5 deals with booting from sd/usb/tftp/nvme/https
<clever> pi5 basically then just deleted stage3 from that graph entirely
<clever> 1.5 is now the final VPU stage
<clever> deleted stage2*
<clever> bbl, french fries and one more episode, then i'll get some codin done!
<dolphinana_> sure
<dolphinana_> enjoy your meal and that episode
bonda_000 has joined ##raspberrypi-internals
<clever> and back
<clever> first, let me rid up network boot...
<dolphinana_> sure
<dolphinana_> I'd like to do network boot one day, but now I'm tired...
<clever> [clever@amd-nixos:~/apps/rpi/firmware/boot]$ scp bootcode.bin root@system76:/mnt/
<clever> [root@system76:/mnt]# sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin
<clever> dolphinana_: cheating a bit here, using the closed stage1 to netboot, and then putting the open firmware on the tftp server
<clever> in theory, i can stop cheating once i add usb NIC drivers and a network stack to LK
<dolphinana_> mhm, I see
<dolphinana_> so the non-free bootcode.bin can boot LK?
<clever> yep, thats what the graph i linked earlier said
<dolphinana_> oh I see!
<clever> the red bootcode.bin has arrows leading to all possible stage2's
<clever> so it can load any of them
<clever> ive only tested the open stage2 on the open stage1
<clever> but in theory, it may half work for loading a closed start.elf
<clever> but that feels like going backwards, so i havent tested it
bonda_000 has quit [Remote host closed the connection]
bonda_000 has joined ##raspberrypi-internals
dolphinana__ has joined ##raspberrypi-internals
<dolphinana__> what is msd.elf?
<clever> dolphinana_: a closed binary meant for the CM1/CM3, it turns the pi into a usb mass-storage device
<clever> so you can access the emmc that is soldered to the board
<clever> but nothing stops you from running it on the zeros as well
dolphinana_ has quit [Ping timeout: 252 seconds]
<clever> [root@router:~]# journalctl -f -t tftpd -n20
<clever> May 04 15:44:13 router tftpd[3231183]: tftpd: trying to get file: 1077df95/start.elf
<clever> May 04 15:44:13 router tftpd[3231183]: tftpd: serving file from /tftproot
<clever> dolphinana__: so i now get this when i turn on the pi2
<clever> lrwxrwxrwx 1 root root 53 Nov 7 02:23 1077df95 -> /nix/store/phgfaz46lbz8318k2flckajilxw4b6y6-rpi_image
<clever> that happens to be a symlink to an old image for booting a build machine
<clever> [root@router:/tftproot]# ln -sv open-firmware 1077df95
<clever> '1077df95' -> 'open-firmware'
<clever> [nix-shell:~/apps/rpi/lk-overlay]$ make PROJECT=vc4-stage2 && scp build-vc4-stage2/lk.elf root@router:/tftproot/open-firmware/start.elf
<clever> the symlink assigns that serial# to run the open firmware, and then i build&upload
<clever> ah, this is an old disk image, where the kernel was still called zImage
<clever> but my new lk.elf expects zImage-v7
<clever> and on closer inspection, i think this was an rpi-open-firmware based image
<clever> so the kernel is on fat still
<clever> cant fix this over the network, i'll need to eject the uSD and move the files about
<clever> [ 104.347597] Freeing unused kernel memory: 2048K
<clever> [ 104.638114] Run /init as init process
<clever> <<< NixOS Stage 1 >>>
<clever> dolphinana__: wooo!
<clever> stage 2 init script (/mnt-root//nix/store/zd8szli5dliy4c93kih9cmsbnb25phdb-nixos-system-pi3-23.11pre-git/init) not found
<clever> An error occurred in stage 1 of the boot process, which must mount the
<clever> and fail
<clever> dolphinana__: https://gist.github.com/cleverca22/a6779ad43b78c054fd4c7bf63d188a31 if you want to see what it looks like
<dolphinana__> yo, nice clever!
<dolphinana__> (I was away eating)
<clever> oh, thats why its not booting
<clever> uncommited changes, forcibly changing cmdline.txt
<clever> <<< NixOS Stage 2 >>>
<clever> its bootin!!
<clever> [ *** ] (1 of 2) A start job is running for�…conf update (27min 32s / no limit)
<clever> dolphinana__: the clock is messed up, it already thinks 20 minutes have passed
<clever> its not even been 3
<dolphinana__> ooooh... weird...
<clever> and its stuck in a loop, sshd isnt starting within the default timeout
<clever> so it keeps murdering it and restarting
<clever> i kinda want to boot it anyways, and see what ntp can do, lol
<dolphinana__> mhm
<dolphinana__> good luck clever ^^
<clever> yep
f_ has quit [Ping timeout: 260 seconds]
<clever> [ 0.000000] arch_timer: cp15 timer(s) running at 1.00MHz (virt).
<clever> dolphinana__: aha, this thinks the clock is running at 1mhz, which is an option, but considering how fast things are ticking, its probably 19.2mhz
<clever> so its running 19.2 times too fast
<dolphinana__> uh oh...
<clever> dolphinana__: thats easy enough, just change this number
<clever> perfect, systemd is now booting with zero issues
<clever> what did i set the pw to? lol
<clever> "initialPassword": "password",
<clever> "name": "root",
<clever> l33t hax0r mode, lol
<dolphinana__> hahaha
<dolphinana__> what a password ;P
<clever> systemd-timesyncd is running and seems happy
<clever> so 19.2 was the answer this time
<clever> will need to investigate why it differs, but it booted
<clever> it even accepted my public key!?
<clever> dolphinana__: uhh, oops, i left a backdoor in the default image, lol
<clever> if you can call that a backdoor
<dolphinana__> your public key for?
<clever> my ssh public key
<dolphinana__> ah, I see
<clever> it let me into the pi2, without any fuss
<clever> the same image i told you to try using yesterday
<dolphinana__> uh oh... o.o
<clever> yeah
<bonda_000> decided I'll go for minix 1
<bonda_000> that one is without virtual memory
<bonda_000> circa 1996
<clever> dolphinana__: now that the basics are working, i can focus on new things, like hdmi or isp, and trying to get the new disk image to build, without the pubkey this time!
<bonda_000> nevermind 1987
<dolphinana__> clever, nice!
<dolphinana__> wait, what does isp stand for?
<clever> image sensor pipeline?
<clever> its part of the camera stuff bonda_000 wants working
<bonda_000> tbh
<dolphinana__> ah, I see
<bonda_000> I want to not ruin my raspberry and other associated hardware
<clever> dolphinana__: https://i.imgur.com/FCmQ6ra.png the ISP hw accelerates everything in this diagram
<dolphinana__> ah, okay
<bonda_000> with the way things are I've been doing too many hard resets. and ideally this Pi should live to the moment I actually get to program with the isp block
<bonda_000> porting a small os so I dont have to pull some cord every time I need/want to change the program is like a necessity at this moment
<clever> or just solder some wires to the RUN header
<bonda_000> don't want to ruin anything that's my only computer
<bonda_000> Already reversed polarity 2 weeks ago and fried an MSP432
<bonda_000> I know there are these small solder dots at the back side of the board
<bonda_000> oh wait
<bonda_000> yeah what is this
<bonda_000> the RUN thing?
<clever> yes
<bonda_000> I see it next to the USB
<bonda_000> if I short these it powers off?
<clever> it will hard reset it, without turning the power off
<bonda_000> shorting those two?
<clever> yeah
<bonda_000> and if I keep them shorted then?
<clever> i soldered a 0.1" header pins onto, and then plugged in a reset switch from an old PC case
<clever> if you keep it shorted, it stays in reset
<bonda_000> u still here clever?
<clever> bonda_000: sorta, but busy now
<bonda_000> do you think it's a sound idea to put a compressed OS into a bootcode together with init sequence. it would init the hardware then decompress the OS and run from there
<clever> bootcode.bin is limited to 128kb
<bonda_000> thats like smaller than the floppy disk?
<clever> yes
<bonda_000> once you are done
<bonda_000> can you explain what is the arithmetic that you are doing
<bonda_000> in interrupt.S
<bonda_000> int offset = 0x10 + ((intno >> 3) << 2);
<bonda_000> uint32_t slot = 0xF << ((intno & 7) << 2);
<bonda_000> why do we need this?
<clever> bonda_000: IC1_MASK0 is essentially an uint32_t[8]
<clever> `intno >> 3` is the same as `intno/8`, so there are 8 interrupts per register
<clever> and then `<<2` is the same as `*4`, so offset is now the number of bytes to index into the array
<clever> and because its a 32bit register for 8 irq's, thats 4 bits per irq
<clever> i'm guessing that 4bit value is an irq priority, but i havent confirmed it
<bonda_000> yeah I see there are 8 mask registers in each Interrupt Controller
<bonda_000> seems to have 8 entries with 3 bits per entry
<bonda_000> so thats 64 interrupts in total
<bonda_000> 0x10 is an offset to the MASK0
<bonda_000> so offset is pretty much figuring out what MASKn register the interrupt number belongs to
<clever> yep
<clever> i do similar for gpio altmode
<bonda_000> and then
<bonda_000> uint32_t slot = 0xF << ((intno & 7) << 2);
<bonda_000> take the lowest 3 bits of an interrupt number and multiply by 4? and shift 15 by that multiplication result?
<bonda_000> that's gonna be more than 32
<clever> intno has a max of 7, 7<<2 is 28
<clever> so that becomes 0xf << 28
<clever> which sets bits 28/29/30/31
<bonda_000> assert(vector < 64);
<bonda_000> set_interrupt(vector, true, 0);
<bonda_000> that looks like a max of 64
<clever> or rather, `intno&7` has a max of 7
<bonda_000> 63*
<bonda_000> oh
<bonda_000> so all that does is that interrupt is masked, i.e. won't interrupt the core
<bonda_000> so
<bonda_000> if bootcode runs from L2 cache
<bonda_000> which has alias '8'
<bonda_000> and L2 cache is 128KB in size
<bonda_000> what addresses is it mapped to?
<bonda_000> so in that mode I can access addresses from 80000000 to 80020000?
<bonda_000> and If I try anything above 80020000 I will get an exception?
<bonda_000> it's weird because in ARM I had 1GB of ram, from 0x0 to 3FFFFFFF, and cache there, 64KB in size both instructions and data, could hold any address, and was more of like a table of recently look-upped memory for quicker access
<bonda_000> I don't particularly understand what it means to "load" L2 cache with bootcode
<bonda_000> or it's just, once you enable L2 cache, any reads/writes with alias '8' become legitimate? or only in the 80000000 - 8002000 range?
<clever> bonda_000: any r/w to the whole 1gig range at the 8 alias can be cached in the L2 cache
<clever> the boot rom will use vector writes to zero out 128kb, starting at 0x8000_0000
<clever> and because the write does a whole cache line, the L2 cache just accepts it
<clever> if you try to write outside that 128kb range, the cache will need to evict something to dram
<clever> and oh, the dram isnt online, something goes horribly wrong :P
<clever> if you try to read outside that 128kb range, cache miss, go to read dram, oh, its offline, something goes horribly wrong :P
<bonda_000> so at the bring up cache is aware it's empty
<bonda_000> ?
<clever> out of reset, the L2 cache is entirely empty
<clever> and the boot rom will initialize a 128kb chunk of the cache to all zeros
<clever> so you can then use it as normal ram, for the most part
<bonda_000> so its like four physical devices mapped onto one physical memory range at different stages
<clever> yeah
<bonda_000> bootrom, sram, l2 cache, then sdram
<clever> at offset 4c8 in the pi3 rom, is init_l2cache()
<clever> it first writes a 0 into an `uint32_t[8*16]` in the vector registers
<clever> 512 bytes
<clever> it then loops 256 times, writing 512 bytes to the 0 alias
<clever> for a total of 128kb
<bonda_000> i see it
<bonda_000> it doesnt show me any C code as it doesn't undestand vector instruction
<clever> yep
<bonda_000> maybe make these into separate functions?
<clever> vector opcodes rarely come up
<bonda_000> I read in your interrupts code
<bonda_000> / it will then push pc and sr onto the new stack
<bonda_000> / when an exception or interrupt occurs, the cpu will make sp into an alias pointing to r28
<bonda_000> / it will then push pc and sr onto the new stack
<clever> yeah, thats the supervisor vs user stacks
<clever> its a security thing
<bonda_000> that's an equivalent of ARM srsdb sp!, #MODE?
<bonda_000> although VPU does it for you?
<clever> somewhat, yeah
<clever> bbl
<bonda_000> from the manual
<bonda_000> On an interrupt, the interrupt mode is entered (r25 is mapped to r28), then pc and then sr are pushed onto the stack.
<bonda_000> (hermanhermitage)
<bonda_000> pushed on the stack automatically? in ARM they often say this but what they actually mean you have to do it manually
dolphinana__ has quit [Quit: Leaving]