klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
goliath has quit [Quit: SIGSEGV]
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
<mcrod> hi
<zid> heat I wrote A MACRO today :(
<mcrod> i wrote nothing today because writing code on a mac is just unbearable
<zid> mac has vim and gcc though
<mcrod> or any laptop really
<mcrod> no no, I just hate laptops
<mcrod> my PC is out of commission for another few weeks
<zid> buy it a keyboard
<zid> and a monitor
<zid> and you have a PC again
<mcrod> yes
<mcrod> I need a USB-C adapter for my mouse though
hwpplayer1 has quit [Remote host closed the connection]
housemate has joined #osdev
<heat> zid, are you a GNU PROGRAMMER now
<zid> define _(x) {sizeof(x)-1, x}
<zid> do u like it
<zid> it pascalifies strings
<zid> so I could remove a strlen from my code
<heat> BASED
<zid> heat I need faster rams
<zid> mine is too slow for AoC
raphaelsc has quit [Remote host closed the connection]
hwpplayer1 has joined #osdev
zid has quit [Ping timeout: 246 seconds]
antranigv has quit [Ping timeout: 252 seconds]
antranigv has joined #osdev
<heat> faster rams or more cache?
zid has joined #osdev
<zid> just remembered I forgot to re-enable turbo
<zid> I bet AoC is way faster at 4.8GHz rather than 3.8GHz
<zid> 179us!
<heat> lol why did you disable it
<zid> was debugging a crash, but I think it was a hyper-v bug
<zid> was getting machine checks
<zid> so I tried lowering my clocks and increasing my volts and stuff
<heat> oh damn that's some straight up single core MEGA TURBO SPEED you left on the table
<zid> then left it that way afterwards because I was only reading light novels in summer
<zid> first day of winter is a good day to turn them back up
<zid> WINTER MODE ENGAGE
<heat> gotta go warm
<heat> the new intel cpus double as a heater
<zid> My 5800x is a real pain in the arse to overclock compared to my sandy :(
<zid> it has a million tunables and I don't understand what any of them are because they've been like, abstracted over
<zid> what's "Precision Boost Overdrive All Cxx Core Offset Multiplier 7" or whatever
<heat> maybe they uhhh dont really matter
<zid> rather than just setting my voltage offset and max core multiplier
hwpplayer1 has quit [Remote host closed the connection]
<heat> i wouldn't be surprised if overclocking hasn't been all that effective for MEGA HYPER TURBO BOOST cpus
<zid> I don't want PRECISION BOOST OVERDRIVE, I want a voltage setpoint for idle, a voltage setpoint for full turbo, and a max multi
<zid> yea it does almost nothing
<zid> They just turbo until power limit or 90C then stop
<heat> sounds aight?
<mcrod> I would like to get a new CPU, because I think this one is actually busted somehow
<zid> I want my 1650 back
<mcrod> but I'm not spending $800 on a 9800X3D
Arthuria has quit [Ping timeout: 246 seconds]
<zid> at least it has like an 'auto' setup tool
<zid> that just keeps raising the clocks and voltages until it gets too hot and crashes
<heat> ok mcrod send me this cpu
<heat> with no cum on it, preferentially
<heat> i know you're sick and twisted and might do that
<mcrod> yes, i cum thermal paste
fedaykin has quit [Quit: leaving]
<heat> hot.
<heat> actually
<heat> cold.
<zid> and this is a good excuse for me to add a bunch of cardboard shims to all my fans to get them to shut up
<zid> now that they're spinning and being annoying
<zid> £8 fan + cardboard >>>> £25 noctua
fedaykin has joined #osdev
craigo has joined #osdev
jedesa has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
\Test_User has joined #osdev
craigo has quit [Remote host closed the connection]
housemate has joined #osdev
housemate has quit [Ping timeout: 265 seconds]
jedesa has quit [Remote host closed the connection]
jedesa has joined #osdev
craigo has joined #osdev
netbsduser has joined #osdev
\Test_User has quit [Ping timeout: 252 seconds]
\Test_User has joined #osdev
tjf has quit [Quit: l8r]
tjf has joined #osdev
housemate has joined #osdev
housemate has quit [Max SendQ exceeded]
housemate has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
housemate has joined #osdev
heat has quit [Ping timeout: 248 seconds]
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
housemate has joined #osdev
_ngn has quit [Remote host closed the connection]
_ngn has joined #osdev
ThinkT510 has quit [Ping timeout: 244 seconds]
housemate_ has joined #osdev
housemate has quit [Ping timeout: 265 seconds]
housemate_ has quit [Remote host closed the connection]
rrq has joined #osdev
agent314 has joined #osdev
Arthuria has joined #osdev
<rrq> about switching to aarch32 for a cortex-a53; is that done separately for each thread? if so, does each thread have their own system registers, or are some system registers shared? I'm looking for documentation about it
Arthuria has quit [Ping timeout: 276 seconds]
hwpplayer1 has joined #osdev
<Ermine> isn't overclocking about pouring liquid nitrogen onto your tech until it shows some mind blowing clock rates?
cloudowind has quit [Ping timeout: 244 seconds]
<clever> rrq: aarch32 mode, is just using the lower 32bits of most of the 64bit registers
<clever> typically, the kernel runs in aarch64, and uses eret to return to a 32bit userland
<clever> within the saved registers, is the previous mode (user vs kernel) and the bit width
<rrq> each core thread switched separately?
<clever> so when creating a thread/process, you just make up a fake "previous mode" that has the right values, and "return" to it
<clever> yeah, each core can be in any mode
<rrq> is there doc on which system registers are shared vs per-thread?
<clever> i believe nearly everything is per-core
<clever> except one of the timer values? and peripheral stuff
<clever> per-thread, is up to your kernel, what it swaps out when changing threads
<rrq> ok. this is boot sequence before kernel.. I want to boot "linux armhf" (i.e. aarch32)
<clever> i think you can use eret to drop from 64bit kernel to 32bit kernel
<rrq> so I suppose all threads need to switch and then only one is used to boot the kernel
<rrq> while the other sits in some spinlock(?)
<clever> yeah, all threads will need to be in 32bit mode when entering the kernel
<clever> on platforms like the rpi, 3 of the cores sit in a WFE loop waiting for a PC to start at in a spin-table
<clever> on better platforms, they use PSCI to start the cores up via firmware in EL3
<clever> with PSCI, EL3 would always be in aarch64 mode, and when directed, it will eret down to EL2/EL1 in the desired bit width
<clever> and when directed, the cpu can be forced back to EL3 to re-park a core
<clever> and each core can do that seperately
<rrq> thanks. yes I have a pi3 box .. with cortex-a53 ..
<clever> for the rpi specifically, there is non-standard jank
<clever> a special control register that makes the cpu start in aarch32 mode, from the very first opcode
<clever> arm_64bit=1 and arm_64bit=0 in config.txt control that
<clever> then its just in 32bit mode from the start, and you can ignore all the armv8 stuff
<rrq> ah.. I'll see if I can find that; would be perfect for my use case :)
<rrq> "config.txt" ? ... that's still after some u-boot steps?
<klys> u-boot reads config.txt iirc
<klys> it's part of the mkimage output
<clever> klys: ive never seen that before
<clever> config.txt happens before u-boot, in the firmware on the VPU
<klys> it seems you have some stuff that can get at the vpu on pi3 or earlier iirc
<clever> for the pi0-pi3 models, bootcode.bin is unsigned, so you can just replace all the VPU blobs
<klys> other arches use u-boot, mebby not pi
<rrq> config.txt is mentioned in trusted-firmware-a source
<clever> rrq: link?
<clever> when using the official firmware, with stock raspi-os, there are ~5 stages to the boot
<rrq> docs/plat/rpi3.rst
<rrq> right; I have an "orangepi 3 LTS" though
<clever> ah, thats a totally different beast, and i dont know its internals
<klys> I have a pi4b 2gb and riscv nezha board and sipeed k210 riscv
<clever> the config.txt things in rpi3.rst, are to get the firmware to co-operate with ATF
<clever> for the pi0-pi3 family, the 5 stages are:
<clever> stage 0, the boot rom, it typically loads bootcode.bin from a fat fs on an SD card
<clever> but the pi3 also supports loading it from fat on usb, or tftp
<rrq> ok; platform is an allwinner/sun50i_h6
<clever> stage 1, bootcode.bin, it gets loaded to 0x8000_0000 and then it jumps to 0x8000_0200, and this blob brings the dram controller online before loading start.elf from the same place
<clever> stage 2, start.elf, contains all of the runtime services, and the rest of the bootloader
cloudowind has joined #osdev
<bslsk05> ​github.com: tools/armstubs at master · raspberrypi/tools · GitHub
<clever> stage 2 includes pre-built copies of the armstub for each model
<clever> a copy of the armstub for the right model, gets dropped at arm physical 0 (the reset vector)
<clever> the linux kernel (stage 4), dtb, and initrd, get dumped somewhere in ram (varies, and can be configured)
<clever> and the armstub is patched, to know where the kernel/dtb are
<klys> clever have you hacked 4b yet just curious
<clever> and the dtb is patched to know where the initrd is
<rrq> clever: thanks I'll see if I can use that
<clever> then the arm is set loose on the stub, and things boot from there
<clever> klys: for the pi4, the difference is that stage1 typically lives on SPI flash, but a recovery.bin on SD has priority, for "unbricking", in both cases, it must be signed with an hmac-sha1 key
<clever> however, they made the mistake of stage2 (start4.elf) being unsigned, and the boot rom still being on the bus
<clever> so a custom start4.elf can dump the rom, then a bit of decompiling later, and i have the hmac-sha1 keys
<clever> so i can now sign custom stage1/recovery.bin files
<klys> so eh, stage1 is that bootcode.bin ?
<clever> yeah
<clever> on pi0-pi3, stage1 is called bootcode.bin, and primarily lives in /boot on the boot disk
<klys> and you have it for the apu in a disassembly?
<clever> on pi4, stage1 primarily lives in the SPI flash
<clever> but a recovery.bin on SD is also a valid stage1, and has priority, for when SPI is bricked
<clever> apu?
<klys> it runs on the apu at boot?
<klys> ergo the arch must match
<clever> the VPU, yeah
<klys> ok
<clever> stage1 must be valid VPU assembly
<klys> is it annotated assembly that you have uploaded or is it just somewhere on the back burner
<clever> ive ported little-kernel to the VPU
<bslsk05> ​github.com: lk-overlay/arch/vpu/start.S at master · librerpi/lk-overlay · GitHub
<clever> this code can be compiled down to 4 different targets, bootcode.bin, start.elf, recovery.bin, or start4.elf
<clever> and run on anything in the pi0-pi4 range
<klys> I would refer to the stock stage1
<klys> and its listings
<clever> ah, for that, you have ~3 options
<bslsk05> ​github.com: firmware/boot at master · raspberrypi/firmware · GitHub
<clever> the official binaries are here
<klys> yes they must be binaries
<clever> 1: the dumb way, just run `objdump -D` on it, using this toolchain https://github.com/itszor/vc4-toolchain
<bslsk05> ​itszor/vc4-toolchain - A port of the GNU toolchain to the Raspberry Pi's VideoCore4 processor. (19 forks/138 stargazers)
jedesa has quit [Read error: Connection reset by peer]
jedesa has joined #osdev
<clever> 2: there is a ghidra fork that supports the VPU, https://github.com/NationalSecurityAgency/ghidra/pull/1147
<bslsk05> ​github.com: Initial support of Broadcom VideoCore IV by paolovagnero · Pull Request #1147 · NationalSecurityAgency/ghidra · GitHub
<clever> 3: ive heard about IDA support as well
<clever> i'm not sure about sharing the full decompile from my ghidra, copyright and all that
<klys> okok those are options for those interested in stock stage1, not including you at this point?
<klys> you had done so at some stage, however
<clever> ive spent months digging thru the official firmware with ghidra, to figure out how the hardware works
<clever> to the point that i can look at a hex dump, and see function prologues
<clever> most functions start with 0x5a, why do i know this? lol
<klys> right so that's not shared then, ic.
<clever> https://i.imgur.com/MztTtUI.png for the pi0-pi3 family, you have 5 different paths you can follow when booting
<bslsk05> ​i.imgur.com <no title>
<clever> it always starts with the stock boot rom, because its ROM!
<clever> you then have 3 choices on, which stage1 to load
<klys> when the pi5 came out was it useful to compare notes with their stage1?
<clever> they locked that thing up damn tight :P
<clever> the official bootcode.bin, can only load firmware from fat32 on sd/usb, or tftp, but it can load 3 different stage2 variants
<clever> the lk-overlay bootcode.bin is highly modular, and the vc4-stage1 project can only load LK from ext4 on sd/usb/tftp
<clever> and the old rpi-open-firmware project, skips stage2, and goes directly to loading linux
<clever> i'm not sure how, but bootcode.bin is aware of where the rom loaded the .bin from, and it will try to load the .elf from the same place
<clever> however, if bootcode.bin loaded from SD, and everything is missing, it will fallback to usb modes
<klys> when you say pi5 loads firmware, is that encrypted and incompatible with anything you seen?
<clever> that allows a pi1 to boot from the network
<clever> its signed, but not encrypted
<clever> https://i.imgur.com/4m8YZIV.png this is how the old pi4 firmware worked, its key to understanding the pi5
<clever> bootcode.bin lived in SPI flash, it would bring dram online, then load start4.elf from the SD/usb/network/nvme
<clever> and because start4.elf wasnt signed, it was able to dump the rom, and crack the security wide open (if you can call hmac-sha1 security)
<clever> but then, they added https boot support!
<clever> and the SSL libraries didnt fit within the 128kb limit for stage1
<clever> https://i.imgur.com/njSA9eJ.png so they split stage1 in half!
cloudowind has quit [Ping timeout: 248 seconds]
<clever> the new stage1, only does dram init, and lacks all of the "bootloader" logic, it just loads a compressed bootmain.elf from SPI
<clever> ive been calling bootmain, stage 1.5
<ring0_starr> that diagram makes me kinda appreciate sunxi
<clever> since dram is online by that point, bootmain can be more bloated, and deals with sd/usb/nvme/tftp/https
<klys> you must have researched the dram logic a fair bit by now
<clever> rrq: under normal conditions, your only taking one path down that diagram, and only a few paths are officially supported
<clever> ring0_starr: oops, ^
ThinkT510 has joined #osdev
<clever> klys: ive had no luck in bringing the pi4 dram online
<clever> klys: thats why the LK recovery.bin is a dead-end on the graph, no dram, so its stuck in cache-as-ram mode
<clever> klys: now, for the pi5, they just deleted stage2 from the graph entirely
<clever> stage1 is still in SPI, it brings dram online as before, then loads a compressed stage 1.5 bootmain.elf from SPI
<clever> bootmain.elf is now the final VPU stage, it loads linux and handles all runtime services
<ring0_starr> and bootmain isn't u-boot?
<clever> ring0_starr: correct, bootmain is custom VPU firmware
<ring0_starr> uboot came before the rpi
<klys> I don't think pi models traditionally used u-boot, I said that once
<clever> the rpi just never needed uboot
<ring0_starr> this kind of upsets me
<clever> half the job of uboot, is to load the kernel/initrd from the storage, when you lack an OS
<ring0_starr> yeah but it replaces a lot of the crap you see with a mainline software distribution instead of some bespoke thing
<ring0_starr> before dram init and such
<clever> but the thing that runs before the arm, already has an entire os, with threads, interrupt handlers, and a 2d/3d stack
<ring0_starr> on sunxi that happens in the on-die bootcode
<clever> if your loading a binary with uboot in it, what purpose does uboot even have?
<ring0_starr> kernel parameters
<clever> the VPU firmware does that
<clever> cmdline.txt gets patched into the device-tree
<klys> well you have those kinds of things going on with arm, if you want a libre u-boot solution you go to riscv or openpower perhaps (or opensparc?)
<clever> klys: ive been able to replace all the blobs on the pi2/pi3, and boot linux to graphics without a single blob
<ring0_starr> i have a mango pi that i never booted yet
<ring0_starr> ;;
<ring0_starr> will have to take a look at some point in time...
<ring0_starr> ...all i have these days are time
<klys> clever is pi3 arm64 on the cpu?
<clever> yeah
<klys> do you have more letters in the arch indicating the feature set
<bslsk05> ​github.com: rpi-open-firmware/docs/arm-arch.txt at master · librerpi/rpi-open-firmware · GitHub
<clever> there is also a dump for some cache config registers in that file, along with the decoding of them
<klys> armv8-a+crc
<clever> i believe the pi3 and pi4 both lack the crypto accel opcodes
<clever> i dont know why that file says crypto-neon
<klys> is the chip in pi3 still being mass produced or available at cheap prices <- may be a relevant query
<clever> the die within the pi3, is also used on the pi-zero2w
<clever> for the pi3, its just a single die in the SoC package, with external dram
<clever> for the pi-zero2, the SoC and dram are wire-bonded together, inside a single package
<clever> and they did something nasty, all of the address/data pins are mis-wired
<clever> so your bits go thru the enimga machine on the way to the dram :P
<clever> enigma*
<clever> but on reads, they go backwards thru the same plug-board, and get unscrambled
<klys> oh can you get that chip on digi-key or mouser
<clever> nope
<clever> many years ago, somebody got a sample batch of bcm2835's directly from broadcom, and fab'd up some boards
<clever> they then promptly violated the license on the rpi firmware, and ran it on non-rpi hardware :P
<clever> and broadcom hasnt sold to outsiders since
<klys> ye I don't think it would be a good business to deal with broadcom or qualcomm
<klys> ever since the qfuse and today's knox stuff
<klys> it really is too bad that libre-soc is floundering since the lost their nlnet funding last year
<klys> I have compiled their whole project locally
<clever> for the pi0-pi4 family, there are about 64 rows of fuses, 32 bits per row
<clever> i believe the fuses start out all 0, and burning a fuse turns it into a 1
<bslsk05> ​github.com: rpi-open-firmware/docs/otp.txt at master · librerpi/rpi-open-firmware · GitHub
<clever> row 17, configured where the rom will look for stage1
<clever> rows 19-22 form a 16 byte per-device signing key, it gets XOR'd with a 20 byte constant in the rom, to create the actual hmac-sha1 key
<clever> 23-26 is a backup of the key, so it cant be corrupted
<clever> but rpi wasnt interested in per-device keys, so every SoC in a given model, has the same key burnt into it
<klys> I mean the fuses are on the die, it's like saying hello ma hello pop i invented planned obsolescence...
<clever> rows 28 and 29 contain the serial#, but 29 is inverted
<clever> row 30 has the hw revision, which tells the firmware what model its running on
<clever> 45/46 have the mpeg2 and vc1 license keys
<clever> the rest is fairly unused on the pi0-pi3, and the firmware doesnt care what is in them
<clever> with later revisions of the bcm2711 (pi4/pi400), they added RSA signatures to stage1
<klys> any modern arm device used for general purpose "mobile" computing signs their kernels with intricate fuse-related logic I gather
<clever> for that, there are 4 rsa2048 pubkeys in the boot rom, and when RSA checking is enabled, stage1 must be signed with a valid rsa key
<clever> the official stage1 binaries, check for that, and then enforce the custom secure-boot logic
<clever> a user-generated rsa2048 pubkey can be stored in external SPI flash
<clever> the sha256 of that pubkey, must then be burned into 8 OTP rows (row 47 to 54)
<clever> if the external key doesnt match the internal fuses, it will refuse to boot
<clever> once thats validated, it loads a boot.img and boot.sig from the fat32, and verifies it with the user-generated pubkey
<klys> the day will most assuredly come when it will be less than possible to boot a general purpose kernel due to fuse logic
<clever> then it treats boot.img as a fat32 disk image, and boots from that as usual (kernel, stage2, configs, initrd)
<clever> for the current devices, secure-boot is disabled when you purchase it, and unsigned keys can run just fine
<clever> and its up to the customer to program some extra keys and enable the signature checks
<klys> current devices including pi5?
<clever> yeah
<clever> for pi4, there is a slight security flaw, in that stage1 must be signed by a key broadcom/rpi controls
<clever> and the stage1 binary then enforces that the kernel is signed by a user-generated key
<clever> so if those master keys are leaked, or the govt forces broadcom to co-operate, things can be defeated
<clever> for the pi5, there is cross-signing involved, stage1 must be signed by both the master key, and the user-generated key!
housemate has joined #osdev
<clever> so not even broadcom can force a back-doored update into a device (in theory)
<clever> i dont have a rom dump, so i cant confirm things
housemate has quit [Remote host closed the connection]
<klys> have you looked at a pixel samsung huawei xiaomi etc. cpu die
<clever> nope
<klys> I imagine there are a load of devs at xda-developers who have
<klys> just a bit curious if you were interested in mobile dev
<klys> I use the UserLAnd app on my samsung devices to keep notes
<clever> i have dabbled in android dev before
<klys> however I have to follow some explicit instructions to disable the phantom process killer
<clever> both androd apps, and running android on the rpi
housemate has joined #osdev
<klys> google put some android device drivers under linux/drivers/
<clever> i had some rather crazy problems when i was debubging android on the old pi1
<clever> back then, all graphics went thru the mailbox framebuffer api
hwpplayer1 has quit [Ping timeout: 252 seconds]
<clever> when running android on the rpi1 with the rpi fork of linux, it has zero output, a solid black screen
<clever> if i paused the android gfx process, and dd'd to /dev/fb0, it worked fine
<clever> as soon as android did a page-flip, black!
<clever> internally, android was requesting a framebuffer with a virtual height that is double the physical height
<clever> and using the framebuffer panning controls, to page flip
<klys> sounds about right
<clever> the android fork of linux, that "fixes" things, also doubles the virtual height
<klys> so the whole screen was part of the border
<clever> so when android asks for a 2x framebuffer, the kernel changes it to 4x, and passes it on to the firmware
<clever> the firmware then says no, 4x is too big!
<clever> so android falls back to 1x and no page-flipping
<clever> then the kernel doubles it to 2x, lol
<clever> and things "work" but tear
<clever> hence, "fixing"
<clever> a year after tearing my hair out on that bug, i stumbled upon a forum thread, with the cause
<clever> RPI screwed up their framebuffer code
<clever> if you change ANY PARAMETER, it wipes the framebuffer
<clever> so, when android changes the y offset to page-flip, the firmware goes and clears the perfectly pre-configured framebuffer :P
GeDaMo has joined #osdev
<klys> so eh, it seems various r.pi generations have differing video outputs
<klys> like mine are microhdmi
<clever> pi1/pi2/pi3 are all full sized hdmi
<clever> the zeros are mini-hdmi
<clever> pi4/pi5/400/500 are micro-hdmi
<klys> is there lvds also?
<clever> nearly all models support DSI
<klys> there might be a little screen to plug into one of them for sale
<clever> brb
cloudowind has joined #osdev
<clever> klys: back
<klys> okok
<clever> for the bcm2835/2836/2837/2711 (pi0-pi4 soc's), there are 2 CSI and 2 DSI ports
<clever> 2 lane and 4 lane each
<klys> it's csi and dsi, please describe
<klys> oh looks good
<clever> for both of them, its a 500mhz differential clock, and then 2-4 lanes of differential DDR data
<klys> is the dsi port tested with respect to the above or were you just using hdmi?
<clever> thats just what the specs say, i dont have any hardware capable of testing it
<clever> for the pi0-pi3 family, the 2d core start with the HVS (something video scaler?)
<clever> it has 3 channels, and a chunk of display-list memory
<clever> for each channel, you configure a resolution, if its interlaced, and where it starts in the display-list memory
<clever> at that starting location, you list off every sprite to display on the screen
hwpplayer1 has joined #osdev
<clever> for an unscaled plain rgb image, it takes up 7 x 32bits of display-list memory, per sprite
<clever> plus a single 32bit value to terminate the list
<clever> every time the output FIFO on the HVS has room for 1 scanline of image data, it will parse the display-list, find all sprites covering the next scanline, fetch image data from dram, scale&composite it into the FIFO, and advance the state by 1 scanline
<clever> and with 3 channels, its time-sharing that computation over 3 display lists, keeping 3 FIFO's fed
<klys> recently I was breadboarding access to a 71256SA25TPG sram chip using dip switches, an astable 555 timer set for ~1sec, and leds
<clever> channel 0 can drive either DSI0 or DPI
<clever> channel 1 can drive HDMI or VEC(composite video)
<clever> channel 2 can drive DSI1 or SMI
<clever> you can never drive 2 things with a single channel
<clever> on the HVS side of the fifo, its very bursty and laggy, since it has to deal with dram latency and bus contention
<clever> the pixel valve (PV) side however, is running in lock-step with the pixel clock, reading the HVS FIFO, 1 value per pixel
<clever> the PV defines all of the video timing parameters, generates hsync/vsync, the blanking signals, and turns the flow of pixels on/off (hence pixel valve)
<klys> VEC composite is new on me, I have dealt with S-video and composite, just never with an HDMI connector.
<clever> internally, the VEC can operate in 1, 2 or 3 channel mode
<clever> 3 channel mode gives you RGB and YPbPr
<clever> 2 channel mode gives you s-video
<clever> and 1 channel mode is composite
<clever> but channels 2/3 arent wired up on any rpi board
<klys> so 3 channels is component video
<clever> and RPI has never provided example code on how to actually use the channels
<clever> so we are stuck in 1 channel mode
<klys> with the appropriate connector, I gather
<clever> for the pi1, the video was just on a dumb old RCA jack
<clever> for the pi2/pi3/pi4, its a TRRS headphone jack, left+right+video on the same connector
<clever> for the zeros and pi5, its a 1 pin 0.1" header that isnt populated
<bslsk05> ​github.com: rpi-open-firmware/docs/video-pipeline.md at master · librerpi/rpi-open-firmware · GitHub
<klys> yeah my pop has had a pi1 for a while, it seems he may no longer use it tho, kodi/xbmc user
<clever> pi4 also shuffled the 2d core up a bit, both to support 4k60, and to support dual hdmi, but it was still limited to 3 active outputs max
the_oz has quit [Remote host closed the connection]
the_oz has joined #osdev
<clever> pi5 is a major change, only the native hdmi on the bcm2712 is in use (if your only looking at the video side of things)
<clever> and the RP1 south-bridge deals with dpi/csi/dsi
<clever> and even composite
<klys> dpi is dots per inch still or I don't see where you said that
<clever> its also display parallel interface
hwpplayer1 has quit [Remote host closed the connection]
<bslsk05> ​elinux.org: RPi BCM2835 GPIOs - eLinux.org
<clever> gpio 0 is the raw pixel clock
<clever> gpio 1 is a "data valid", tells you if your in blanking or visible
<clever> gpio 2/3 are the vsync/hsync
<clever> and then gpio 4-27 are up to 24bits of raw parallel color
<clever> the imgur link, explains where the color lands, depending on what mode you pick
<clever> mode 7 gives you full 24bit color, using the entire gpio header
<klys> that seems like a right useful pin diagram should someone be doing the right thing tho
<clever> mode 2 gives you RGB565 packed into pins 4-19
<clever> mode 4 also gives 565, but with some unused pins between the colors
<clever> so you could then cross-reference to the elinux page, and find a use for the pins in the gaps
<klys> plugged into my pi4b's gpio header there should be a homebrew8088
<clever> SMI is another fun mode
<clever> it can do 8088 and m68k addressing styles
<klys> serial mouse interface?
<clever> its an external memory interface
<bslsk05> ​iosoft.blog: Raspberry Pi Secondary Memory Interface (SMI) – Lean2
jedesa has quit [Ping timeout: 264 seconds]
<clever> basically, the hardware will presnt a 6 bit address on 6 pins
<clever> then wiggle the r/w, and output-enable pins in a certain pattern (depending on the mode)
<clever> and then either read or write 18 bits of data, on another 18 pins
<clever> so, you could whack some SRAM onto the rpi, with 64 rows, of 18 bits each
<clever> and then use SMI to access it at high speed
<clever> or, you could take the good old HD44780 LCD driver
<clever> rig addr bit 0 to command/data, addr bit 1 to chip-select, and then blast it with a full frame under hw control
<clever> then slap a raw NAND chip on the same pins, use addr bit 2 as the NAND chip-select, and now you can talk to both at once
<clever> addr 0 and 1 are lcd, addr 4 is nand
<klys> I'll be off it's time to rest for now
<clever> same, its 5am!
jedesa has joined #osdev
jedesa has quit [Read error: Connection reset by peer]
jedesa has joined #osdev
jedesa has quit [Client Quit]
svm has joined #osdev
msv has quit [Ping timeout: 272 seconds]
svm is now known as msv
xenos1984 has quit [Ping timeout: 260 seconds]
craigo has quit [Quit: Leaving]
xenos1984 has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
<rrq> anyone still around? is there also separate MMU for the threads, or is that to be set up by 1 thread ?
hwpplayer1 has joined #osdev
<GeDaMo> The MMU is a hardware unit, there's one per core
<GeDaMo> Normally, processes each have their own address space, threads share an address space within a process
<GeDaMo> Actually, I say one MMU per core but I'm not sure :|
<ring0_starr> wouldn't it need to be one mmu per core
<GeDaMo> Does the address translation happen before or after the caches?
<ring0_starr> at the same time as the virtual index calculation, no?
<Affliction> I figure there'd be at least some per-thread resources. At very least the register that backs CR3, for instance. Precise details very likely differ with microarch
<GeDaMo> I mean, what's stored in the caches, virtual addresses or real addresses?
<ring0_starr> ive been looking for the answer to that question myself today, but all i get are college computer architecture course powerpoint slides, which have some lines and diagrams and nothing really of substance on their own
<ring0_starr> from what i can understand, most modern cpus use VIPT which hashes the vpn and then somehow uses the physical address as the "tag" ?? nothing i read goes into specifics of how
<Affliction> I don't have a real answer, but given that I have used aliased virtual pages without everything going wrong, the CPU seems to at least provide the illusion that it's physical memory that's cached
<ring0_starr> piecing together information from like 5 different websites the tag is the top N bits of the physical address, N being decided by the internals of the cache
<ring0_starr> not like we really can do anything with this information at the software level
goliath has joined #osdev
goliath has quit [Quit: SIGSEGV]
<geist> it's a single mmu per logical hardware thread yes
netbsduser has quit [Ping timeout: 252 seconds]
housemate has joined #osdev
netbsduser has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
Left_Turn has joined #osdev
Turn_Left has joined #osdev
xenos1984 has quit [Ping timeout: 272 seconds]
Left_Turn has quit [Ping timeout: 265 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
agent314 has quit [Ping timeout: 252 seconds]
heat has joined #osdev
<heat> hey i just met you
<heat> and this is craaaaaaaazy
<heat> but here's my number
<heat> so call me maybe
agent314 has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
MiningMarsh has quit [Ping timeout: 260 seconds]
MiningMarsh has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<mcrod> no
<nikolar> heat, you ok
<heat> yes why would i not be okay
<heat> i'm quite negatively surprised there are no carly rae jepsen fans here
<nikolar> Lol are you a fan of hers
<nikolar> Name 3 of her (orher) songs
<heat> i only like her 2011 songs
<heat> after 2011 i think she got paul mccartney'd and replaced with a worse clone of her
agent314 has quit [Quit: WeeChat 4.3.1]
<nikolar> Lol
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
sbalmos has quit [Quit: WeeChat 4.4.4]
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
d5k has quit [Ping timeout: 252 seconds]
sbalmos has joined #osdev
<heat> do you think the discord people know who carly rae jepsen is
<mcrod> yes
goliath has joined #osdev
<nikolar> Maybe they are too young
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 265 seconds]
hwpplayer1 has quit [Quit: I'll be back later]
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
<kof673> i know that song but don't know if you can do much with it. no time for love dr. jones > Hercules Fights a Bear 1983 you will note cassiopeia is redhead with blue eyes...other characters at this alchemy location include disney's the little mermaid lol green forest here lol
hwpplayer1 has joined #osdev
d5k has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
<the_oz> GREEN MAN come together with your hands: https://www.youtube.com/watch?v=T0_zzCLLRvE
<bslsk05> ​www.youtube.com: - YouTube
d5k has quit [Ping timeout: 260 seconds]
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
Leftas has quit [Quit: Ping timeout (120 seconds)]
sham1 has quit [Remote host closed the connection]
Turn_Left has quit [Ping timeout: 264 seconds]
sham1 has joined #osdev
Leftas has joined #osdev
Turn_Left has joined #osdev
fedaykin has quit [Quit: leaving]
fedaykin has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
hwpplayer1 has joined #osdev
karenw has joined #osdev
hwpplayer1 has quit [Read error: Connection reset by peer]
hwpplayer1 has joined #osdev
khrbtxyz has quit [Ping timeout: 272 seconds]
khrbtxyz has joined #osdev
housemate has joined #osdev
housemate has quit [Remote host closed the connection]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
karenw has quit [Ping timeout: 248 seconds]
theyneversleep has joined #osdev