channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=1&d=22

Sunday, 22 January 2023

00:01:00 <ornx> yeah, it works for all the others, just ss doesn't like it - i'm going to try setting the type fields, since the legacy documentation says ss needs to be R/W at least
00:03:00 <moon-child> are you making ss different from the other somehow? Iirc I just had one data segment and one code segment and it worked fine
00:03:00 <moon-child> others*
00:05:00 <ornx> ah hah! i got it - yeah it needed to be set to writable
00:05:00 <ornx> and yeah it's a different segment than the code segment, so i've just got one code and one data
00:05:00 <mrvn> how does writing to the framebuffer work if the data segment isn't writable?
00:05:00 <ornx> i assumed it just ignored that bit
00:06:00 <mrvn> would be odd to ignore it for ds but not ss
00:06:00 <mrvn> (not that x86/x86_64 isn't odd a lot ...)
00:07:00 <moon-child> indeed
00:07:00 <ornx> https://files.catbox.moe/0s49lv.png it even specifically says the writable bit is ignored :|
00:08:00 <moon-child> 'when the descriptor is used during a memory reference' maybe it just means explicit segment override?
00:08:00 <moon-child> idk
00:09:00 <moon-child> oh it straight up says later ignore W
00:09:00 <moon-child> idk
00:45:00 <heat> ornx, you cannot change the GDT or set segment registers when in EFI boot services
00:45:00 <heat> you also can't change the IDT or page tables (manually)
00:51:00 <gog> i thought you could do that but only if you had some way of restoring EFI context for ISRs that it cared about?
00:51:00 <gog> maybe i misunderstood the doc
01:01:00 <heat> so what it says pretty much is (re enabling alternate translations): you can try to intercept ISRs and chain-call them as long as you change the translations to the boot ones and back
01:02:00 <heat> but at this point you're playing with fire. pretty much your boot services have all gone to shit and are invalid, your IDT is invalid, your GDT is invalid
01:04:00 <heat> "If a UEFI application uses its own page tables, GDT or IDT, the application must ensure that the firmware executes with each supplanted data structure"
01:05:00 <heat> worth noting that every time you're doing something exotic in EFI you're putting yourself at risk of you breaking something or the fw itself being broken
01:16:00 <ornx> ah, i should probably have mentioned that that i had exited EFI services before trying anything... my current goal is to set up interrupts, which EFI would definitely be using for e.g. its usb stack
01:17:00 <heat> ah ok
01:17:00 <heat> btw EFI does not in practice use interrupts for anything except timers :)
01:18:00 <ornx> huh, really? doesn't it interface with hardware that generates interrupts?
01:21:00 <heat> no, in practice EFI firmware just polls
01:22:00 <heat> although IIRC EFI 100% allows for interrupts
01:22:00 <heat> s/no, /yes, but /g
01:26:00 <ornx> i see! i had no idea you could do it like that lol
01:28:00 <gog> it's fine break things
01:28:00 <gog> computers work through magic anyway so if it doesn't work you just have to do it the same way but mean it
01:28:00 <gog> anyhow
01:28:00 <gog> nini
01:28:00 <heat> if whatever you're doing isn't working, try it with more meaning and a british accent
02:43:00 <epony> now all you need is some performance in the python Jan21 2332 <mrvn> one python per core and the GIL problem goes away.
10:22:00 <ddevault> re: EFI interrupts
10:22:00 <ddevault> not just in practice, but defined by the spec
10:23:00 <ddevault> https://l.sr.ht/b_vQ.png
10:34:00 <dinkelhacker> clever: It seems like I can't only configure the GICC on the rpi4 from EL1. Haven't found anything in the architecture spec. Do you know if that is a pi thing?
10:35:00 <dinkelhacker> s/only//
10:38:00 <clever> dinkelhacker: i'm fuzzy on the details, but i there might be some weirdness where the gic is routed thru the legacy irq controller
10:38:00 <clever> youll need to re-read the bcm2711 datasheets
10:38:00 <clever> https://datasheets.raspberrypi.com/
10:38:00 <bslsk05> ​datasheets.raspberrypi.com: Raspberry Pi Datasheets
10:38:00 <clever> https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf
10:39:00 <dinkelhacker> But generally it should be configurable from EL1? The distributor and the cpu interface?
10:40:00 <clever> yeah
10:40:00 <clever> i would expect so
10:40:00 <clever> ive not actually tried using gic myself, yet
10:41:00 <ddevault> gic works for me on pi4 from EL1 fwiw
10:41:00 <ddevault> at least once I figured out how the fuck to program it
10:41:00 <ddevault> https://git.sr.ht/~sircmpwn/helios/tree/master/item/arch/dev/%2Baarch64/gic.ha
10:41:00 <bslsk05> ​git.sr.ht: ~sircmpwn/helios: arch/dev/+aarch64/gic.ha - sourcehut git
10:42:00 <clever> .ha?
10:42:00 <ddevault> hare
10:42:00 <ddevault> just read it as if it were weird C
10:42:00 <clever> looks rusty
10:42:00 <ddevault> is very different from rust
10:42:00 <ddevault> https://harelang.org
10:42:00 <bslsk05> ​harelang.org: The Hare programming language
10:43:00 <dinkelhacker> weird... doesn't work for me..
10:45:00 <ddevault> best practice per the GIC spec which isn't addressed by my code, btw: you should write the unmasked value of IAR to EOI
10:46:00 <dinkelhacker> okay now that I look at it.. why does it work at all. I'm configuring the gic at EL3 through the va space of EL1 before I even turn on the mmu for EL1..
10:47:00 <ddevault> if your EL1 address space is (partially?) mapped in EL3 it would work even if the MMU is disabled in EL1
10:47:00 <ddevault> also something something cache
10:48:00 <kof123> i went to hare.org first :/
10:48:00 <ddevault> what, you think I'm made of money?
10:48:00 <dinkelhacker> I don't map anything at EL3. I just set up system registers and drop down to EL1
10:49:00 <kof123> :D its like a study of psychopaths page lol
10:50:00 <clever> the bcm2711 is also cursed, in that all pl011 uarts share a single gic interrupt
10:50:00 <clever> so you cant route each uart to a different process in a micro-kernel
10:51:00 <ddevault> clearly the solution is to have a meta-pl011 driver which brings in the one interrupt, polls for the source, then wakes up the appropriate pl011 driver /s
10:52:00 <clever> ddevault: which defeats the point of a micro-kernel being micro
10:52:00 <ddevault> see /s
10:52:00 <sham1> How very meta
10:52:00 <ddevault> do you have a serial driver in your kernel btw
10:53:00 <dinkelhacker> clever, yeah the pi really is a nightmare I guess. Speaking of it, do you know any other ARMv8 SBCs which ideally expose a JTAG and have TrustZone support?
10:53:00 <clever> dinkelhacker: ive not looked into other SBC's
10:53:00 <clever> dinkelhacker: most of my focus has been documenting the hidden parts of the rpi, and replacing the firmware, so you can better control the system
10:58:00 <clever> dinkelhacker: one example, the rpi is a great platform to stress-test if your handling ranges= and dma-ranges= properly
10:58:00 <clever> there is an undocumented mmu, between "arm physical" and the ram
10:58:00 <clever> 64 pages of 16mb each, total of 1gig
10:58:00 <clever> so i could program it to scramble the memory layout on every boot, but adjust DT so a well behaving driver doesnt care
10:59:00 <ddevault> oh nice
10:59:00 <ddevault> link?
11:00:00 <clever> ddevault: https://github.com/librerpi/rpi-open-firmware/blob/master/firmware/drivers/BCM2708ArmControl.cc#L161-L174 and also lines 207-215
11:00:00 <bslsk05> ​github.com: rpi-open-firmware/BCM2708ArmControl.cc at master · librerpi/rpi-open-firmware · GitHub
11:00:00 <clever> 207 maps 992mb, starting at 0, contiguous
11:00:00 <clever> 215 maps the peripherals, but ARM_PERIPH_BASE only has to be non-zero, and 16mb aligned
11:00:00 <ddevault> thanks, I'll make use of this to test my kernel's DT support
11:00:00 <clever> you can change the ARM_PERIPH_BASE to whatever you want
11:01:00 <ddevault> s/kernel/system/
11:01:00 <clever> the arm bootloader is built with the same hardware.h, so it respects the modified ARM_PERIPH_BASE
11:01:00 <clever> https://github.com/librerpi/rpi-open-firmware/blob/master/arm_chainloader/loader.cc#L266
11:01:00 <bslsk05> ​github.com: rpi-open-firmware/loader.cc at master · librerpi/rpi-open-firmware · GitHub
11:01:00 <clever> and this part of the bootloader then patches the DT
11:02:00 <clever> currently, it just allows moving the mmio window around
11:02:00 <clever> but with a bit more code, it could totally scramble ram
11:02:00 <clever> also, its currently limited to booting a 32bit arm kernel on the pi0-pi3 range
11:22:00 <dinkelhacker> device memory is always not cached, right?
11:24:00 <clever> dinkelhacker: you must configure that in the mmu, mmio should never be cached
11:24:00 <Mutabah> Usually it shouldn't be cached... but 1. that assumes correct memory controller config, 2. some device memory might benefit from some level of caching (write-through, or even write-combine)
11:24:00 <clever> yeah
11:25:00 <clever> the display list memory in the rpi is meant to be write-only
11:25:00 <clever> and will even return corrupted data if you read at the wrong time
11:25:00 <clever> but its also something you write to in bulk, once per vsync
11:25:00 <clever> so it would definitely benefit from the cache batching things up
11:26:00 <clever> but the mmio on the rpi, is also only on a 32bit bus
11:26:00 <clever> and various bugs occur, if you try doing 64bit read or write
11:26:00 <clever> it also malfunctions in fun ways if your access isnt 32bit aligned
11:27:00 <dinkelhacker> interessting so all mmio should be 32 bit reads and wirtes?
11:27:00 <clever> yeah
11:27:00 <clever> the sdhci controller has a couple 16bit registers, but those also malfunction under certain conditions
11:28:00 <clever> linux works around that, by caching the last 16bit write, and merging it with the next, to form a 32bit write
11:30:00 <clever> dinkelhacker: as an example, the internal 32bit bus on the mmio, just lacks bit0/bit1 of the address, but does have a 4bit mask, to enable each 8bit part of the bus
11:31:00 <clever> dinkelhacker: so an 8bit read, that is at aligned+1, (say 1 or 5 as addr), would send the rounded down addr (0 or 4), and a byte mask that enables flow on bits 8:15 of the data bus
11:32:00 <clever> addr bit0/1 are sometimes present though, i'm fuzzy on the exact details
11:32:00 <clever> one bug, arrises from the peripheral doing a match the full address, so an 8bit read of 1, is not a valid register (only 0, 4, 8 ... are)
11:32:00 <clever> so it puts a default 32bit value onto the bus
11:32:00 <clever> and the byte mask, then selects just an 8bit slice of that
11:34:00 <clever> the intended use of that default value, is to return a string like 'gpio' in all undefined registers
11:34:00 <clever> but as a result of that bug, you also get 'pio' in the mis-aligned bytes
11:34:00 <clever> i had to rewrite my hexdump routine to account for that
11:34:00 <clever> because it was doing 8bit reads
12:00:00 <mrvn> Mutabah: write combine will break MMIO on the RPi
12:04:00 <Mutabah> mrvn: MMIO sure... but in general, some bits of memory (e.g. VRAM) can be WC
12:05:00 <mrvn> dinkelhacker: when you cache MMIO regs then on every write you need to flush and on read you have to decide if you want the cached or current value. Some registers write one thing and read another. Some change after write so your cache goes out of sync and some getting the cached value is perfectly fine. Something you would have to specify on a register by register basis making your code much more complicated
12:05:00 <mrvn> and error prone. Better to just not cache any MMIO.
12:06:00 <mrvn> Mutabah: all physical memory should be cached and write combine. It's a HUGE speedup.
12:06:00 <Mutabah> Yep.
12:06:00 <mrvn> And by huge I mean that before caches the RPi runs on less than 10% speed.
12:07:00 <dinkelhacker> clever: now i am really confused. After reboot the gic is mapped to its physicall address 0xff841000 BUT ALSO to every +0x1000000000 so it is also mapped to 0x10ff841000 0x20ff841000 0x30ff841000.. the hell is going on?
12:08:00 <mrvn> 0x10_0000_0000?
12:08:00 <dinkelhacker> yes
12:09:00 <mrvn> is that outside the physical address range?
12:09:00 <dinkelhacker> yes
12:09:00 <mrvn> so the bit has no address line. the hardware doesn't see that bit.
12:11:00 <mrvn> A nice cpu would fault when the unused upper bits of a physical address aren't zero.
12:11:00 <dinkelhacker> Oh... lol that's actually a nice trick (dirty hack) to use the same address to access the device no matter if the mmu is enabled or not^^
12:11:00 <moon-child> a _nice_ cpu would let me put whatever i want in the unused upper bits
12:11:00 <moon-child> :)
12:12:00 <mrvn> moon-child: or that. AVL bits are always nice.
12:13:00 <mrvn> with the MMU enabled does the cpu even use the unused upper bits of the physical address from the page table? Or are they specified as AVL?
12:13:00 <clever> dinkelhacker: page 5 of the pdf i linked earlier, i can see some aliases at things like 0x4_0000_0000, but the 0x10_0000_0000 bit isnt defined, definitely looks like you went off the end of the addr space
12:14:00 <clever> unused addr bus bits, are also the cause of an xbox exploit
12:15:00 <dinkelhacker> have to take a look again at that link once I get home
12:18:00 <kof123> one man's exploit is another man's bootloader :D
12:18:00 <mrvn> it's a bit of freedom
12:18:00 <clever> kof123: exactly
12:29:00 <mrvn> "I have a very specific filing system." "What is that? Gravity?"
12:29:00 <clever> mrvn: and i can find everything, until somebody cleans the table
12:30:00 <clever> i lost my keys last week, because somebody moved then by 3 feet
12:30:00 <mrvn> I know everything and can find everything, until someone asks for it
12:30:00 <mrvn> Quantum-omnipotent
12:30:00 <mrvn> etc
12:56:00 <mrvn> going back a few minutes: When you access 0x10ff841000 in the kernel on aarch64 shouldn't that hit the hypervisor page tables and fault?
12:57:00 <clever> mrvn: but if the hypervisor tables arent enabled?
12:58:00 <mrvn> Does that even work? It would be insane for the hypervisor not to protect itself at least.
12:59:00 <clever> i mean if you have no hypervisor
12:59:00 <mrvn> then obviously it doesn't fault into the non-existant hypervisor :)
12:59:00 <clever> exactly
13:00:00 <mrvn> But say you do have a hypervisor could you run it without page tables?
13:00:00 <clever> you could, but the hypervisor wont be protected
13:01:00 <clever> you drop from EL2(hypervisor) to EL1(kernel) with eret, and there is basically no difference from the no-hypervisor case, and the hypervisor case
13:01:00 <clever> the differences happen before you eret, configuring what gets trapped, and turning on the nested paging tables
13:01:00 <mrvn> I could imagine that if the hypervisor doesn't enable the MMU then EL1 would be MMU-less or something.
13:02:00 <clever> the hypervisor nested tables, also impact what the guest thinks is physical, when the guest hasnt enabled its own mmu
13:04:00 * mrvn wants XEN/kvm support in the hypervisor. To be able to reserve cores and run different kernels on them.
13:05:00 <clever> the kvm api is fairly nice and simple, and i can see how you might implement it on custom kernels
13:06:00 <zid`> basically irrelevent but I wanted to mention it anyway, playstation's memory map is just to have everything mapped twice, once with caching on and once with it off
13:06:00 <zid`> you're welcome
13:07:00 <clever> ah, same as the rpi internals
13:07:00 <mrvn> zid`: MIPS does that 4 times. the 2 top bits are cache attibutes
13:07:00 <clever> yep, thats identical to the rpi
13:07:00 <mrvn> a quite common hardware hack.
13:11:00 <kof123> psx is mips :D its only like 1 or 2 M of physical RAM, maybe a dev system had more
13:12:00 <kof123> i mean, i dont know if that varies between mips versions etc.
13:12:00 <mrvn> kof123: surely not M and it can't be more than 1G since it only has 30 address bits.
13:12:00 <mrvn> Not sure how that changes with MIPS64.
13:15:00 <kof123> MegaOctetBytes
13:15:00 <kof123> i just mean its not going to fill up the address space by doing that
13:16:00 <clever> i just remembered, the rp2040 does something fairly neat/funky with mmio
13:16:00 <clever> ~2 bits of the addr, set the write mode, normal write, set bit, clear bit, or flip bit
13:17:00 <clever> so you can do atomic changes to any mmio register in the entire system
13:18:00 <mrvn> other systems have to provide 4 registers for that, i.e. use low bits of the address
13:18:00 <clever> rp2040 has the bits more at the middle, i think you use +4096 to seek over to the next variant
13:19:00 <clever> that makes it simpler to just slap a struct over every peripheral, and not have to pad it out with 4x the fields
13:19:00 <clever> and the atomic macros, just set/clear some addr bits
13:32:00 <heat> kernel operating system
13:40:00 <zid`> https://twitter.com/FroyoTam/status/1617124984077582339
13:40:00 <bslsk05> ​twitter: <FroyoTam> these are my simple requirements when finding Win9x-era PCs: ␤ ␤ - can it run the FPS game, Cyberdillo, at normal speed (anything above a pentium MMX is too fast for it) ␤ - can it run Viper GTS (MIDI playback + sound card) ␤ - does it come in these cases: https://pbs.twimg.com/media/FnEumZqaYAEt6gj.jpg
13:40:00 <zid`> heat wants the left one bad
13:41:00 <sham1> The right case is amazing
13:41:00 <mrvn> That's why you run bitcoin miners in the background to slow down the system enough the game plays at normal speeds.
13:42:00 <heat> yessss lonix best operating
13:42:00 <mrvn> How is th penguin more expensive? It runs linux, should be cheaper without windows license.
13:42:00 <heat> penguin
13:43:00 <zid`> what is it like, £60?
13:43:00 <mrvn> 8.800 Japanese Yen equals
13:43:00 <mrvn> 62,45 Euro
13:43:00 <mrvn> 54,83 Pound sterling
13:47:00 <mrvn> what does "rbit r4, r4" do?
14:20:00 <froggey> Ribbit?
14:48:00 <sortie> ribbit
15:06:00 <GeDaMo> https://www.tomshardware.com/news/cooler-master-jumps-the-shark-with-pre-built-pcs-in-shoe-shark-cases
15:06:00 <bslsk05> ​www.tomshardware.com: Cooler Master's Shark-Shaped PC is Set to Make Waves | Tom's Hardware
15:06:00 <zid`> that's a rad demo piece
15:39:00 <zid`> https://pbs.twimg.com/media/FnARcN-XEAABdiY.jpg
15:44:00 <sham1> That's one very grumpy cat
15:45:00 <zid`> Clever cat who is aware of the state of reality.
15:45:00 <sham1> Although that's understandable, I'd also be grumpy if I was held up like that
16:06:00 <Jari--_> hi
17:16:00 <sham1> hi
19:52:00 <dinkelhacker> Man I still don't get why on earth I can't control the gic from el1... as soon as I move the init code to el3 everythign works and I can also clear pending irqs from el1.
19:58:00 <heat> ddevault, sorry, I was wrong, that e_lfanew is in fact 32-bits wide
19:59:00 <heat> so .word was correct after all :/
19:59:00 <zid`> imagine being heat
19:59:00 <heat> i personally would never
19:59:00 <zid`> I thought the problem was that .word was 16bit on some platforms though
19:59:00 <zid`> so it still broken, if it's supposed to be 32, just not.. in the way you said
20:01:00 <heat> i have no idea why but I thought it was supposed to be a 16-word
20:01:00 <heat> 16-bit*
20:01:00 <heat> so I fixed it, ddevault "fixed it"
20:01:00 <mrvn> heat: because there is DWORD (32 bit) and QWORD (64 bit)
20:01:00 <heat> and now it's a dword
20:01:00 <zid`> #ifdef WORD_IS_DWORD_SIZED_IDK
20:01:00 <heat> so I fucked ddevault
20:01:00 <heat> no lube
20:04:00 <gog> hi
20:04:00 <heat> gog
20:04:00 <zid`> goob
20:08:00 <gog> zib
20:08:00 <gog> calor
20:08:00 <heat> hola gog
20:09:00 <heat> por favor ayuda me
20:09:00 <heat> yo tengo problemas en mi efi stub
20:16:00 <zid`> Imagina ser el mejor país de Iberia.
20:16:00 <gog> heat:
20:16:00 <gog> what's wrong with your efi
20:16:00 <heat> idk it doesn't want to load my PE
20:17:00 <gog> why not
20:17:00 <heat> it doesn't say
20:17:00 <gog> can i see code
20:17:00 <zid`> usually his efi talks to him
20:17:00 <heat> gog, yes
20:17:00 <mrvn> gog: are you blind?
20:18:00 <gog> yes
20:18:00 <mrvn> then you probably can't see code.
20:18:00 <gog> dang
20:18:00 <mrvn> you can feel it
20:19:00 <zid`> efi: "This PE sukcs"
20:19:00 <kof123> i see dead code
20:20:00 <mrvn> kof123: see dead code, delete dead code. Monkey see, monkey delete.
20:21:00 <kof123> more of a compost guy
20:21:00 <heat> gog, https://github.com/heatd/Onyx/blob/efistub/kernel/arch/x86_64/boot.S#L66
20:21:00 <bslsk05> ​github.com: Onyx/boot.S at efistub · heatd/Onyx · GitHub
20:23:00 <gog> this is beyond me i'm afraid
20:23:00 <heat> sadge
20:23:00 <gog> sorry sweetie
20:25:00 <heat> i live in spain but the s is silent and so is the pain because i live in portugal and not spain
20:25:00 <gog> bring back al andalus
20:25:00 <heat> noooooooooo
20:26:00 <heat> bring back the kingdom of asturias
20:26:00 <heat> me and the lads defending christendom for 300 years on some mountains
20:33:00 <zid`> grenada best iberian country
20:33:00 <zid`> granada
20:33:00 <zid`> grenade.
20:36:00 <heat> uk best iberian country
20:36:00 <zid`> ..second best
20:36:00 <zid`> we already covered what tbe best one was
20:37:00 <heat> ah right, the algarve
20:37:00 <zid`> granada > uk > spain > navarra > portugal
20:37:00 <heat> come for the sun stay for the losing your children and starting a decade-long manhunt part
20:37:00 <zid`> wait what's the other one called
20:38:00 <heat> isn't france technically in iberia too
20:38:00 <zid`> andorra
20:39:00 <zid`> 1839 worst day of my life
20:39:00 <geist> so, rust.
20:40:00 <geist> i have started to look at rust again.
20:40:00 <heat> well, a year-long day sounds pretty terrible to me
20:40:00 <heat> geist, noooooooooooooo
20:42:00 <gog> rust?
20:42:00 <zid`> It's like if you took C and then made it crash at runtime
20:42:00 <gog> ohhh rust
20:42:00 <gog> sorry i don't program
20:43:00 <heat> geist has taken the new occupation of staring at literal rust the whole day
20:43:00 <geist> well i do still have an occupation!
20:44:00 <heat> senior oxidation engineer
20:44:00 <zid`> I am a lead looker
20:45:00 <zid`> I do a lot of Cing
20:45:00 <gog> better than being a keyboard toucher
20:45:00 <zid`> eww perverts
20:45:00 <mrvn> zid`: lead is poison, be carefull
20:45:00 <zid`> I'll stick to being a knob twiddler
20:45:00 <dinkelhacker> clever: Don't know if you will read this but now I found out. The GICD_IGROUPRn register is secure access only. I've I would have used the stock armstub8-gic.bin all irqs would have been already set to group 1. But since I've changed it at some point so my kernel can boot in EL3 I have to do the grouping myself in secure world. But when I eret'ed to EL1 I was already in secure world so the grouping
20:45:00 <dinkelhacker> wouldn't work. Once I just used the original arm stubs to let them setup the groups it just worked.
20:45:00 <mrvn> when you look into the lead, the lead looks back at you
20:46:00 <clever> dinkelhacker: ahh
20:46:00 <clever> dinkelhacker: so the issue, is that the armstub was pre-configuring the gic, to allow el1 to do certain things, and then you bypassed it?
20:47:00 <dinkelhacker> Yep!
20:47:00 <clever> that similar to my own issues, where i bypassed the armstub (and official firmware), and then everything broke
20:47:00 <clever> and something i will need to keep in mind, when i get pi4 working
20:47:00 <dinkelhacker> The armstub groups all irqs to group1. Basically everything else I did could be done from EL1 in non secure world.
20:47:00 <clever> or i'll run into your problem exactly
20:48:00 <clever> is group1 special?
20:48:00 <geist> yeah, i saw your post a while back and was hoping it wasn't group0/group1 nonsense
20:48:00 <geist> it's a bit hazy to me, but group 0 and group 1 effectively mean secure/non secure
20:48:00 <clever> ah
20:49:00 <clever> so it defaults to all irq's being secure only?
20:49:00 <clever> and then ns el1 cant claim them?
20:49:00 <geist> (and it forget which one is which)
20:49:00 <geist> something like that
20:49:00 <clever> and its up to el3 to release control and allow access
20:49:00 <dinkelhacker> From the manual "In the context of a GIC that implements the GIC Security Extensions connected to a processor that implements the
20:49:00 <dinkelhacker> ARM Security Extensions, Group 0 interrupts are Secure interrupts, and Group 1 interrupts are Non-secure
20:49:00 <geist> and then yuo can set what happens to each group, and it's some sort of common pattern to fix one of the groups to mean 'route this to EL3 when non secure EL1 is running' etc,
20:49:00 <dinkelhacker> interrupts.y
20:50:00 <geist> ah yeah, i remember it being backwards from what you'd expect. ie, you'd kinda think group 0 would be the 'default'
20:50:00 <clever> similarly, flushign the L2 cache is secure-only by default, and that caused all kinds of crazy memory corruption for me
20:50:00 <zid`> EL3>EL1 stuff is already backwards, so they're going for consistency by being always backwards
20:51:00 <dinkelhacker> So yeah you have to be in secure world to do the grouping of your irq's.. I mean you don't habe to be at EL3 could also be at secure EL1.
20:52:00 <clever> this also circles back to the problem about all PL011's sharing an irq on the bcm2711
20:52:00 <geist> well, i disagree with it being backwards. higher number for higher run modes makes total sense to me
20:52:00 <clever> you cant route just one uart to a group0
20:52:00 <dinkelhacker> And that is probably why the armstubs just by default set all irqs to Group 1 so you just can write a kernel that operates in non-secure EL1
20:52:00 <geist> also allows you to add higher numbers, which is more likely to happen over time than something 'less' than user space
20:52:00 <clever> so you have to route every irq to group0, then decide in software
20:52:00 <zid`> pfft imagine not needing bizzare made up negative rings
20:53:00 <clever> dinkelhacker: i think the armstub also runs linux in non-secure el2, and linux can then either drop to el1, or stay in el2 (depending on kvm support)
20:53:00 <clever> or it might drop to el1, but leave a stub in el2 for future use
20:54:00 <clever> depending on thar armv8 flag i keep forgetting the name of
20:55:00 <dinkelhacker> clever: Right! And that was the first thing I changed in the armstubs because when I started I was like "why is it doing that? Maybe I want to do something in EL3?... Let me change that." ... well jokes on me for thinking I knew better
20:56:00 <clever> the arm stubs changing, are also what broke little-kernel at one point
20:56:00 <clever> when geist originally ported LK to the rpi, the stub ran kernel.img in EL1 mode, because there is no gic on the pi3, and hypervisor doesnt work
20:56:00 <clever> but afterwards, somebody complained, and RPF changed the stub to run kernel.img in EL2 anyways, even without a gic
20:57:00 <clever> LK then sets up the EL1 mmu, and then turns on the mmu for the current (EL2!) mode, and *fault*
20:58:00 <dinkelhacker> Well there are many ways to shoot onself in the foot I guess^^
21:00:00 <geist> yeah this is the origin of a lot of my distaste for rpi. it's so nonstandard. rpi4 is like 80% standard, so it's getting there
21:00:00 <geist> but now unobtanium, so..
21:00:00 <zid`> rpi6 is just an x86
21:01:00 <zid`> You start with mips ppc or arm, then end up on x86, just ask consoles
21:01:00 <clever> while i cant fix all of the non-standard stuff, i can at least document it, and write code to fill in the gaps, that is actually viewable
21:02:00 <dinkelhacker> clever: how come you're so dedicated to documenting the pi?
21:03:00 <clever> dinkelhacker: it started with the pi4 release, having spi flash onboard for bootcode.bin
21:03:00 <clever> which in theory, means you could slap open firmware + uboot onto the spi
21:03:00 <clever> and boom, its now a standard uboot based SBC and boots like any other uboot SBC
21:04:00 <clever> but the pi4 differs too much from the pi0-pi3 lineup, and i have yet to get the pi4 booting with fully open firmware
21:05:00 <clever> but i have taken the original https://github.com/christinaa/rpi-open-firmware, and taken it from "it works, but there is no way to reproduce it", to being able to build a bootable disk image with 1 command
21:05:00 <bslsk05> ​christinaa/rpi-open-firmware - Open source VPU side bootloader for Raspberry Pi. (113 forks/1087 stargazers/NOASSERTION)
21:05:00 <clever> mainly, it works on pi2/pi3
21:06:00 <dinkelhacker> wow that's impressive!
21:06:00 <clever> the main thing that was missing, was the kernel .config, and the dts files
21:07:00 <clever> i also extended it, from just loading a single .dtb, to deteting the model and loading the correct dtb
21:09:00 <clever> dinkelhacker: and then i began to run into issues, with rpi-open-firmware not being very modular, and the entire thing had to fit within 128kb, and it was a bit fragile and would break for no obvious reason
21:09:00 <clever> dinkelhacker: so i ported little-kernel over, and its highly modular framework made things run great
21:19:00 <dinkelhacker> Sounds like tedious work. Is it possible to debug it with JTAG at all?
21:20:00 <clever> the VPU jtag is undocumented, and nobody outside of broadcom/rpf has gotten it to work
21:20:00 <clever> the arm jtag is officially documented, and ive RE'd the enable flags, to use it without the official firmware
21:21:00 <geist> dinkelhacker: i think rpi is clever's great whale
21:21:00 <geist> it probably took their arm in years past
21:22:00 <clever> geist: last i checked, i still have all of my limbs, but one of my arms was possesed a few years back and punched me, lol
21:22:00 <geist> that was raspberry pi!
21:22:00 <clever> i slept on it wrong, and must have pinched a nerve
21:22:00 <geist> oh that too
21:22:00 <clever> woke up, with everything from the elbow down paralised
21:22:00 <clever> i was lifting the limp arm with just the shoulder, looking at it
21:22:00 <clever> when the whole thing just flopped over, and punched it in the face
21:23:00 <geist> that's what i call a sticky situation!
21:23:00 <clever> after a few minutes, the arm resumed working normally
21:23:00 <geist> yeah i'm a side sleeper, that has happened more than once
21:24:00 <clever> always sleep on my side, its only happened once
21:29:00 <dinkelhacker> xD
21:29:00 <dinkelhacker> speaking of sleep - I have to get some. Good night!
21:30:00 <clever> goodnight
21:56:00 <Clockface> on regular UEFI boot, do most of them still leave the lower 640k availible for random stuff?
21:57:00 <Clockface> or will i have to assume that the firmware might have some random crap in there
21:59:00 <gog> i'm a side sleeper and i managed to yank on my new face piercing really hard by acciden the other night
21:59:00 <gog> it's ok i think but owie
22:06:00 <Clockface> ow
23:02:00 <geist> Clockface: yeah dunno. iirc the memory allocate routines in EFI have a mode where you can ask for a block of ram > a certain address, so you can avoid using it if that's what you're worried about
23:02:00 <geist> but presumably UEFI treats unused sections of <640k as unused, since it is Truth at that point in time
23:37:00 <Clockface> alright, thank you