<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
<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
<moon-child>
others*
elastic_dog has quit [Ping timeout: 256 seconds]
<ornx>
ah hah! i got it - yeah it needed to be set to writable
<ornx>
and yeah it's a different segment than the code segment, so i've just got one code and one data
<mrvn>
how does writing to the framebuffer work if the data segment isn't writable?
elastic_dog has joined #osdev
<ornx>
i assumed it just ignored that bit
<mrvn>
would be odd to ignore it for ds but not ss
<moon-child>
'when the descriptor is used during a memory reference' maybe it just means explicit segment override?
<moon-child>
idk
<moon-child>
oh it straight up says later ignore W
<moon-child>
idk
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Vercas has quit [Quit: Ping timeout (120 seconds)]
nyah has quit [Quit: leaving]
Vercas has joined #osdev
small has joined #osdev
joe9 has joined #osdev
<heat>
ornx, you cannot change the GDT or set segment registers when in EFI boot services
<heat>
you also can't change the IDT or page tables (manually)
<gog>
i thought you could do that but only if you had some way of restoring EFI context for ISRs that it cared about?
<gog>
maybe i misunderstood the doc
<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
<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
<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"
<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
<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
<heat>
ah ok
<heat>
btw EFI does not in practice use interrupts for anything except timers :)
<ornx>
huh, really? doesn't it interface with hardware that generates interrupts?
<heat>
no, in practice EFI firmware just polls
<heat>
although IIRC EFI 100% allows for interrupts
<heat>
s/no, /yes, but /g
<ornx>
i see! i had no idea you could do it like that lol
<gog>
it's fine break things
<gog>
computers work through magic anyway so if it doesn't work you just have to do it the same way but mean it
<gog>
anyhow
<gog>
nini
gog has quit [Quit: byee]
<heat>
if whatever you're doing isn't working, try it with more meaning and a british accent
Burgundy has quit [Ping timeout: 256 seconds]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #osdev
DutchIngraham has quit [Quit: WeeChat 3.8]
dutch has joined #osdev
[itchyjunk] has quit [Ping timeout: 260 seconds]
_xor has quit [Quit: brb]
[itchyjunk] has joined #osdev
_xor has joined #osdev
epony has joined #osdev
<epony>
now all you need is some performance in the python Jan21 2332 <mrvn> one python per core and the GIL problem goes away.
<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?
<dinkelhacker>
s/only//
epony has joined #osdev
<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
<clever>
youll need to re-read the bcm2711 datasheets
<bslsk05>
harelang.org: The Hare programming language
danilogondolfo has joined #osdev
<dinkelhacker>
weird... doesn't work for me..
<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
<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..
<ddevault>
if your EL1 address space is (partially?) mapped in EL3 it would work even if the MMU is disabled in EL1
<ddevault>
also something something cache
<kof123>
i went to hare.org first :/
<ddevault>
what, you think I'm made of money?
<dinkelhacker>
I don't map anything at EL3. I just set up system registers and drop down to EL1
<kof123>
:D its like a study of psychopaths page lol
craigo has quit [Ping timeout: 255 seconds]
Vercas has quit [Quit: Ping timeout (120 seconds)]
<clever>
the bcm2711 is also cursed, in that all pl011 uarts share a single gic interrupt
<clever>
so you cant route each uart to a different process in a micro-kernel
Vercas has joined #osdev
<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
<clever>
ddevault: which defeats the point of a micro-kernel being micro
<ddevault>
see /s
<sham1>
How very meta
<ddevault>
do you have a serial driver in your kernel btw
<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?
<clever>
dinkelhacker: ive not looked into other SBC's
<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
<clever>
dinkelhacker: one example, the rpi is a great platform to stress-test if your handling ranges= and dma-ranges= properly
<clever>
there is an undocumented mmu, between "arm physical" and the ram
<clever>
64 pages of 16mb each, total of 1gig
<clever>
so i could program it to scramble the memory layout on every boot, but adjust DT so a well behaving driver doesnt care
<bslsk05>
github.com: rpi-open-firmware/loader.cc at master · librerpi/rpi-open-firmware · GitHub
<clever>
and this part of the bootloader then patches the DT
<clever>
currently, it just allows moving the mmio window around
<clever>
but with a bit more code, it could totally scramble ram
<clever>
also, its currently limited to booting a 32bit arm kernel on the pi0-pi3 range
sortie has quit [Ping timeout: 252 seconds]
sortie has joined #osdev
<dinkelhacker>
device memory is always not cached, right?
<clever>
dinkelhacker: you must configure that in the mmu, mmio should never be cached
<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)
<clever>
yeah
<clever>
the display list memory in the rpi is meant to be write-only
<clever>
and will even return corrupted data if you read at the wrong time
<clever>
but its also something you write to in bulk, once per vsync
<clever>
so it would definitely benefit from the cache batching things up
<clever>
but the mmio on the rpi, is also only on a 32bit bus
<clever>
and various bugs occur, if you try doing 64bit read or write
<clever>
it also malfunctions in fun ways if your access isnt 32bit aligned
<dinkelhacker>
interessting so all mmio should be 32 bit reads and wirtes?
<clever>
yeah
<clever>
the sdhci controller has a couple 16bit registers, but those also malfunction under certain conditions
<clever>
linux works around that, by caching the last 16bit write, and merging it with the next, to form a 32bit write
<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
<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
<clever>
addr bit0/1 are sometimes present though, i'm fuzzy on the exact details
<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)
<clever>
so it puts a default 32bit value onto the bus
<clever>
and the byte mask, then selects just an 8bit slice of that
<clever>
the intended use of that default value, is to return a string like 'gpio' in all undefined registers
<clever>
but as a result of that bug, you also get 'pio' in the mis-aligned bytes
<clever>
i had to rewrite my hexdump routine to account for that
<clever>
because it was doing 8bit reads
Burgundy has quit [Ping timeout: 252 seconds]
Burgundy has joined #osdev
<mrvn>
Mutabah: write combine will break MMIO on the RPi
<Mutabah>
mrvn: MMIO sure... but in general, some bits of memory (e.g. VRAM) can be WC
<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
<mrvn>
and error prone. Better to just not cache any MMIO.
<mrvn>
Mutabah: all physical memory should be cached and write combine. It's a HUGE speedup.
<Mutabah>
Yep.
<mrvn>
And by huge I mean that before caches the RPi runs on less than 10% speed.
<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?
<mrvn>
0x10_0000_0000?
<dinkelhacker>
yes
<mrvn>
is that outside the physical address range?
<dinkelhacker>
yes
<mrvn>
so the bit has no address line. the hardware doesn't see that bit.
NiD27 has quit [Quit: Leaving]
Burgundy has quit [Ping timeout: 246 seconds]
<mrvn>
A nice cpu would fault when the unused upper bits of a physical address aren't zero.
<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^^
<moon-child>
a _nice_ cpu would let me put whatever i want in the unused upper bits
gog has joined #osdev
<moon-child>
:)
<mrvn>
moon-child: or that. AVL bits are always nice.
<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?
<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
<clever>
unused addr bus bits, are also the cause of an xbox exploit
<dinkelhacker>
have to take a look again at that link once I get home
<kof123>
one man's exploit is another man's bootloader :D
<mrvn>
it's a bit of freedom
<clever>
kof123: exactly
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #osdev
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
<mrvn>
"I have a very specific filing system." "What is that? Gravity?"
<clever>
mrvn: and i can find everything, until somebody cleans the table
<clever>
i lost my keys last week, because somebody moved then by 3 feet
<mrvn>
I know everything and can find everything, until someone asks for it
<mrvn>
Quantum-omnipotent
<mrvn>
etc
Left_Turn has joined #osdev
<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?
<clever>
mrvn: but if the hypervisor tables arent enabled?
<mrvn>
Does that even work? It would be insane for the hypervisor not to protect itself at least.
<clever>
i mean if you have no hypervisor
<mrvn>
then obviously it doesn't fault into the non-existant hypervisor :)
<clever>
exactly
<mrvn>
But say you do have a hypervisor could you run it without page tables?
<clever>
you could, but the hypervisor wont be protected
<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
<clever>
the differences happen before you eret, configuring what gets trapped, and turning on the nested paging tables
<mrvn>
I could imagine that if the hypervisor doesn't enable the MMU then EL1 would be MMU-less or something.
<clever>
the hypervisor nested tables, also impact what the guest thinks is physical, when the guest hasnt enabled its own mmu
nyah has joined #osdev
* mrvn
wants XEN/kvm support in the hypervisor. To be able to reserve cores and run different kernels on them.
<clever>
the kvm api is fairly nice and simple, and i can see how you might implement it on custom kernels
<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
<zid`>
you're welcome
<clever>
ah, same as the rpi internals
<mrvn>
zid`: MIPS does that 4 times. the 2 top bits are cache attibutes
<clever>
yep, thats identical to the rpi
<mrvn>
a quite common hardware hack.
<kof123>
psx is mips :D its only like 1 or 2 M of physical RAM, maybe a dev system had more
<kof123>
i mean, i dont know if that varies between mips versions etc.
<mrvn>
kof123: surely not M and it can't be more than 1G since it only has 30 address bits.
<mrvn>
Not sure how that changes with MIPS64.
<kof123>
MegaOctetBytes
<kof123>
i just mean its not going to fill up the address space by doing that
<clever>
i just remembered, the rp2040 does something fairly neat/funky with mmio
<clever>
~2 bits of the addr, set the write mode, normal write, set bit, clear bit, or flip bit
<clever>
so you can do atomic changes to any mmio register in the entire system
<mrvn>
other systems have to provide 4 registers for that, i.e. use low bits of the address
<clever>
rp2040 has the bits more at the middle, i think you use +4096 to seek over to the next variant
<clever>
that makes it simpler to just slap a struct over every peripheral, and not have to pad it out with 4x the fields
<clever>
and the atomic macros, just set/clear some addr bits
<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
<zid`>
heat wants the left one bad
<sham1>
The right case is amazing
fedorafan has quit [Ping timeout: 260 seconds]
<mrvn>
That's why you run bitcoin miners in the background to slow down the system enough the game plays at normal speeds.
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
yessss lonix best operating
<mrvn>
How is th penguin more expensive? It runs linux, should be cheaper without windows license.
<zid`>
Clever cat who is aware of the state of reality.
<sham1>
Although that's understandable, I'd also be grumpy if I was held up like that
wootehfoot has joined #osdev
wootehfoot has quit [Max SendQ exceeded]
wootehfoot has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 264 seconds]
Jari--_ has joined #osdev
<Jari--_>
hi
joe9 has quit [Quit: leaving]
masoudd has joined #osdev
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
fedorafansuper has joined #osdev
fedorafan has quit [Ping timeout: 256 seconds]
<sham1>
hi
[itchyjunk] has quit [Remote host closed the connection]
LivewareProblem is now known as EthicsGradient
wootehfoot has quit [Read error: Connection reset by peer]
demindiro has joined #osdev
dude12312414 has joined #osdev
craigo has joined #osdev
craigo has quit [Client Quit]
craigo has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
c2a1 has quit [Remote host closed the connection]
demindiro has quit [Quit: Client closed]
joe9 has joined #osdev
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
FreeFull has joined #osdev
remexre has joined #osdev
rorx has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
SGautam has joined #osdev
dude12312414 has quit [Ping timeout: 255 seconds]
Vercas has quit [Ping timeout: 255 seconds]
dude12312414 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
<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.
rorx has joined #osdev
invalidopcode1 has joined #osdev
<heat>
ddevault, sorry, I was wrong, that e_lfanew is in fact 32-bits wide
<heat>
so .word was correct after all :/
<zid`>
imagine being heat
<heat>
i personally would never
<zid`>
I thought the problem was that .word was 16bit on some platforms though
<zid`>
so it still broken, if it's supposed to be 32, just not.. in the way you said
invalidopcode has quit [*.net *.split]
invalidopcode1 is now known as invalidopcode
<heat>
i have no idea why but I thought it was supposed to be a 16-word
<heat>
16-bit*
<heat>
so I fixed it, ddevault "fixed it"
<mrvn>
heat: because there is DWORD (32 bit) and QWORD (64 bit)
<heat>
and now it's a dword
<zid`>
#ifdef WORD_IS_DWORD_SIZED_IDK
<heat>
so I fucked ddevault
<heat>
no lube
j`ey_ is now known as j`ey
<gog>
hi
<heat>
gog
<zid`>
goob
<gog>
zib
<gog>
calor
<heat>
hola gog
<heat>
por favor ayuda me
<heat>
yo tengo problemas en mi efi stub
foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<zid`>
Imagina ser el mejor país de Iberia.
<gog>
heat:
<gog>
what's wrong with your efi
__xor is now known as _xor
<heat>
idk it doesn't want to load my PE
<gog>
why not
<heat>
it doesn't say
<gog>
can i see code
<zid`>
usually his efi talks to him
<heat>
gog, yes
<mrvn>
gog: are you blind?
<gog>
yes
<mrvn>
then you probably can't see code.
<gog>
dang
<mrvn>
you can feel it
<zid`>
efi: "This PE sukcs"
<kof123>
i see dead code
<mrvn>
kof123: see dead code, delete dead code. Monkey see, monkey delete.
<bslsk05>
github.com: Onyx/boot.S at efistub · heatd/Onyx · GitHub
<gog>
this is beyond me i'm afraid
<heat>
sadge
<gog>
sorry sweetie
<heat>
i live in spain but the s is silent and so is the pain because i live in portugal and not spain
<gog>
bring back al andalus
<heat>
noooooooooo
<heat>
bring back the kingdom of asturias
<heat>
me and the lads defending christendom for 300 years on some mountains
Clockface has joined #osdev
<zid`>
grenada best iberian country
<zid`>
granada
<zid`>
grenade.
<heat>
uk best iberian country
<zid`>
..second best
<zid`>
we already covered what tbe best one was
<heat>
ah right, the algarve
<zid`>
granada > uk > spain > navarra > portugal
<heat>
come for the sun stay for the losing your children and starting a decade-long manhunt part
<zid`>
wait what's the other one called
<heat>
isn't france technically in iberia too
<zid`>
andorra
<zid`>
1839 worst day of my life
<geist>
so, rust.
<geist>
i have started to look at rust again.
<heat>
well, a year-long day sounds pretty terrible to me
<heat>
geist, noooooooooooooo
not_a_robot06 has joined #osdev
<gog>
rust?
<zid`>
It's like if you took C and then made it crash at runtime
<gog>
ohhh rust
<gog>
sorry i don't program
<heat>
geist has taken the new occupation of staring at literal rust the whole day
<geist>
well i do still have an occupation!
<heat>
senior oxidation engineer
<zid`>
I am a lead looker
<zid`>
I do a lot of Cing
<gog>
better than being a keyboard toucher
<zid`>
eww perverts
<mrvn>
zid`: lead is poison, be carefull
<zid`>
I'll stick to being a knob twiddler
<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
<dinkelhacker>
wouldn't work. Once I just used the original arm stubs to let them setup the groups it just worked.
<mrvn>
when you look into the lead, the lead looks back at you
<clever>
dinkelhacker: ahh
<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?
<dinkelhacker>
Yep!
<clever>
that similar to my own issues, where i bypassed the armstub (and official firmware), and then everything broke
<clever>
and something i will need to keep in mind, when i get pi4 working
<dinkelhacker>
The armstub groups all irqs to group1. Basically everything else I did could be done from EL1 in non secure world.
<clever>
or i'll run into your problem exactly
<clever>
is group1 special?
<geist>
yeah, i saw your post a while back and was hoping it wasn't group0/group1 nonsense
<geist>
it's a bit hazy to me, but group 0 and group 1 effectively mean secure/non secure
<clever>
ah
<clever>
so it defaults to all irq's being secure only?
<clever>
and then ns el1 cant claim them?
<geist>
(and it forget which one is which)
<geist>
something like that
<clever>
and its up to el3 to release control and allow access
<dinkelhacker>
From the manual "In the context of a GIC that implements the GIC Security Extensions connected to a processor that implements the
<dinkelhacker>
ARM Security Extensions, Group 0 interrupts are Secure interrupts, and Group 1 interrupts are Non-secure
<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,
<dinkelhacker>
interrupts.y
<geist>
ah yeah, i remember it being backwards from what you'd expect. ie, you'd kinda think group 0 would be the 'default'
<clever>
similarly, flushign the L2 cache is secure-only by default, and that caused all kinds of crazy memory corruption for me
<zid`>
EL3>EL1 stuff is already backwards, so they're going for consistency by being always backwards
<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.
<clever>
this also circles back to the problem about all PL011's sharing an irq on the bcm2711
<geist>
well, i disagree with it being backwards. higher number for higher run modes makes total sense to me
<clever>
you cant route just one uart to a group0
<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
<geist>
also allows you to add higher numbers, which is more likely to happen over time than something 'less' than user space
<clever>
so you have to route every irq to group0, then decide in software
<zid`>
pfft imagine not needing bizzare made up negative rings
<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)
<clever>
or it might drop to el1, but leave a stub in el2 for future use
<clever>
depending on thar armv8 flag i keep forgetting the name of
<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
<clever>
the arm stubs changing, are also what broke little-kernel at one point
<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
<clever>
but afterwards, somebody complained, and RPF changed the stub to run kernel.img in EL2 anyways, even without a gic
<clever>
LK then sets up the EL1 mmu, and then turns on the mmu for the current (EL2!) mode, and *fault*
<dinkelhacker>
Well there are many ways to shoot onself in the foot I guess^^
<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
<geist>
but now unobtanium, so..
<zid`>
rpi6 is just an x86
<zid`>
You start with mips ppc or arm, then end up on x86, just ask consoles
<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
<dinkelhacker>
clever: how come you're so dedicated to documenting the pi?
<clever>
dinkelhacker: it started with the pi4 release, having spi flash onboard for bootcode.bin
<clever>
which in theory, means you could slap open firmware + uboot onto the spi
<clever>
and boom, its now a standard uboot based SBC and boots like any other uboot SBC
<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
<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
<bslsk05>
christinaa/rpi-open-firmware - Open source VPU side bootloader for Raspberry Pi. (113 forks/1087 stargazers/NOASSERTION)
<clever>
mainly, it works on pi2/pi3
<dinkelhacker>
wow that's impressive!
<clever>
the main thing that was missing, was the kernel .config, and the dts files
<clever>
i also extended it, from just loading a single .dtb, to deteting the model and loading the correct dtb
<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
<clever>
dinkelhacker: so i ported little-kernel over, and its highly modular framework made things run great
not_a_robot06 has quit [Quit: WeeChat 3.6]
EthicsGradient has left #osdev [WeeChat 3.6]
<dinkelhacker>
Sounds like tedious work. Is it possible to debug it with JTAG at all?
<clever>
the VPU jtag is undocumented, and nobody outside of broadcom/rpf has gotten it to work
<clever>
the arm jtag is officially documented, and ive RE'd the enable flags, to use it without the official firmware
EthicsGradient has joined #osdev
<geist>
dinkelhacker: i think rpi is clever's great whale
<geist>
it probably took their arm in years past
<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
<geist>
that was raspberry pi!
<clever>
i slept on it wrong, and must have pinched a nerve
<geist>
oh that too
<clever>
woke up, with everything from the elbow down paralised
<clever>
i was lifting the limp arm with just the shoulder, looking at it
<clever>
when the whole thing just flopped over, and punched it in the face
<geist>
that's what i call a sticky situation!
<clever>
after a few minutes, the arm resumed working normally
FreeFull has quit [Ping timeout: 256 seconds]
<geist>
yeah i'm a side sleeper, that has happened more than once
<clever>
always sleep on my side, its only happened once
FreeFull has joined #osdev
invalidopcode has quit [Remote host closed the connection]
<dinkelhacker>
xD
<dinkelhacker>
speaking of sleep - I have to get some. Good night!
<clever>
goodnight
masoudd has quit [Quit: Leaving]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
SGautam has quit [Quit: Connection closed for inactivity]
<Clockface>
on regular UEFI boot, do most of them still leave the lower 640k availible for random stuff?
<Clockface>
or will i have to assume that the firmware might have some random crap in there
<gog>
i'm a side sleeper and i managed to yank on my new face piercing really hard by acciden the other night
<gog>
it's ok i think but owie
<Clockface>
ow
srjek has quit [Ping timeout: 252 seconds]
gabi-250 has quit [Ping timeout: 255 seconds]
gabi-250 has joined #osdev
Burgundy has joined #osdev
PapaFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
PapaFrog has joined #osdev
gog has quit [Remote host closed the connection]
gog has joined #osdev
gog is now known as pog
fedorafansuper has quit [Ping timeout: 246 seconds]
[itchyjunk] has joined #osdev
fedorafansuper has joined #osdev
dude12312414 has quit [Ping timeout: 255 seconds]
dude12312414 has joined #osdev
<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
<geist>
but presumably UEFI treats unused sections of <640k as unused, since it is Truth at that point in time
xenos1984 has quit [Read error: Connection reset by peer]
danilogondolfo has quit [Remote host closed the connection]
fedorafansuper has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
fedorafansuper has joined #osdev
epony has quit [Remote host closed the connection]