dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
k8yun has joined #osdev
sprock has quit [Ping timeout: 256 seconds]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
sdfgsdfg has joined #osdev
biblio has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
gxt has quit [Ping timeout: 276 seconds]
gxt has joined #osdev
biblio has quit [Quit: Leaving]
gog has quit [Quit: byee]
sprock has joined #osdev
vinleod is now known as vdamewood
freakazoid333 has quit [Ping timeout: 256 seconds]
sdfgsdfg has joined #osdev
k8yun_ has joined #osdev
k8yun_ has quit [Remote host closed the connection]
k8yun has quit [Ping timeout: 256 seconds]
k8yun has joined #osdev
heat has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
sprock has quit [Ping timeout: 256 seconds]
CaCode has joined #osdev
nyah has quit [Ping timeout: 250 seconds]
<heat>
wow riscv atomics are different
<klange>
howso
<heat>
a cas is a load + memory monitor on an address + store (which tells you if its succesful by writing a 0 to a register you give it, and it's only succesful if nobody touched the memory in between the lr.w(load) and the sc.w(store))
CaCode has quit [Quit: Leaving]
<Mutabah>
ARM does the same thing
<Mutabah>
Quite elegant
<heat>
then you can use .aq and .rl to specify acquire or release semantics on atomic instructions
<klange>
Had to implement an atomic & to reset a flag as part of my context switch operation so I learned the ARM approach doing that
<klange>
I should look into doing a riscv64 port now that the ARM one is shaping up.
<bslsk05>
'2d and 3d demo' by michael bishop (00:00:21)
<dmh>
moon-child, i agree, for some reason i misunderstood the old news about mali stuff getting open sourced which they did, but not the full blown DDK ofc
<dmh>
clever, thats cool
<dmh>
bcm chips are off the board tho
<dmh>
stuffing in start.elf is based :D
<clever>
dmh: https://i.imgur.com/Yeh6wEr.jpg is another demo, a 96kb bootcode.bin, that boots to a working text console in 0.61 seconds
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
<dmh>
impressiv
<clever>
so if you can accept the board design, and the current limitations (no hdmi yet), you could use the open firmware on any pi0-pi3 era board
<clever>
but yeah, broadcom wont sell to outsiders, because "you need an nda" to make use of the chip
<clever>
one group bought a sample batch of chips, but then violated a license agreement by running rpi firmware on a non-rpi board
<clever>
so broadcom just shut the door
<dmh>
yea not surprised
<clever>
but with what ive learned, you could design a board that is intentionally not compatible with the rpi firmware
<clever>
just put the SD card slot on the wrong pins :P
<dmh>
thats half of it. the other half is they kinda suck for industrial use compared to competely open stuff anyway
<dmh>
lol
<clever>
the hw can be configured to boot anyways, and the open firmware can be adapted
<dmh>
emmc on second MMC XD
<clever>
but the closed rpi firmware just wont work anymore
<clever>
both SD interfaces can be used on gpio 22-27
<dmh>
i am familiar with this
<clever>
34-43 can only be used with the 8bit capable SDIO capable controoller
<clever>
and both again on 48-53
<heat>
moon-child, tbf most gpu drivers are huge
<clever>
so if i just moved the SD card to the 22-27 bank, the official firmware is screwed
<heat>
if you get the 2D + 3D stuff all going you're in for a treat, it's like writing a whole new kernel for the GPU
<moon-child>
heat: yeah, exactly
<clever>
i think modern gpu's are kinda like the vl805 xhci controller, where you have a complicated internal api, wrapped in firmware that exposes a simpler external api
<moon-child>
that's why I don't wanna do it!
<clever>
and the v3d on the rpi kinda was that, when using the blob/broadcom gl stack, but linux has since gained drivers to drive the internal api directly
<heat>
you need to write whatever the thing needs to drive the display engine + HDMI code + display port code + maybe dvi, vga + managing the ring buffer (in a fast way) + context switching + memory mapping
<heat>
then you're onto user-space
<clever>
yeah, hdmi is still a major roadblock for me
<bslsk05>
01.org: 2020-2021 INTEL(R) PROCESSORS BASED ON THE "TIGER LAKE" PLATFORM | 01.org
<dmh>
i hate computer.
<heat>
for intel you need to do everything I mentioned above correctly and keep track of how each generation works
<heat>
because sometimes things change slightly
<klys>
Intel Horse Creek
<heat>
the linux driver is a really complex beast because it supports everything up to the original i915 lol
<clever>
for the rpi in 2d only mode, you just create a list of images to render, set the resolution and video timing parameters, and configure an output PHY(how depends on each phy)
<clever>
and once setup, your just changing the image list on vsync
<clever>
the 3d core is entirely isolated, and just drops 2d images in ram when done
<heat>
haha how cute
<clever>
how does the intel differ overall?
<heat>
worth noting that after everything I mentioned you still dont have gpu video acceleration
<heat>
good luck writing a stack for that as well
<clever>
the only generational thing i need to worry about is a fairly small list
<clever>
1: the list defining what images to render has changed slightly, some fields are bigger, some are re-arranged
<heat>
intel GPUs are the COMPLEX CLUSTERFUCK OF REGISTERS AND THOUSANDS OF PAGES OF DOCS EXTRAVAGANZA
<clever>
2: some outputs are in a DDR mode, 2 pixels per clock, so all horizontal timing parameters have to be halved by the driver
<clever>
3: the 3d core had minor changes all over, but ive not documented them yet
<heat>
yo dawg I heard you like MMUs so I put an MMU inside your CPU and a GPU inside your CPU with an MMU as well
<clever>
heh, yeah, the bcm2711 did gain another mmu
<Griwes>
I mean that's how you achieve the sanity of a single address space
<heat>
also fun fact: intel GPUs (at least up to haswell I believe) cannot handle page faults at all
<heat>
they just fall over and die
<Griwes>
programming a heterogeneous node with non-uniform memory accessibility is hard enough without the gpu having its own MMU
<clever>
for the vc4 era (pi0-pi3), the 2d and 3d cores lived in the VPU addr space, where the entire 1gig of ram was just repeated 4 times, the top 2 bits of the address control how it uses caches
<clever>
the chip didnt support over 1gig of ram, so that limitation was never a problem
<clever>
but for bcm2711, with support for up to 16gig of ram, and only a 32bit bus on the 3d core....
<clever>
so they added an mmu to convert from the 32bit bus of the 3d core, to the newer 64bit bus
<clever>
but, the 2d core on the 2711 is still stuck in the VPU space, and can only access the lower 1gig of ram
<heat>
also I read that most vulnerabilities on intel and AMD chips are on the graphics' side
<heat>
rejec graphic return 2 serial
<dmh>
cli and tui are good enough
<dmh>
:<
<clever>
for the vc4 era, there is no protections to stop the 3d core from reading/writing whatever it wants
<clever>
the linux drivers will basically audit your shaders/control-lists to enforce rules, and all physical addresses are auto-populated by the driver
<clever>
so userland cant do anything nasty
<clever>
but there could be bugs in the driver, or unknown features in the 3d core it isnt keeping you out of
<clever>
for the 2711, you could re-configure the mmu on each context switch, and directly map the 3d core to the userland of a given process
<clever>
and then it can never hit anything it shouldnt
<clever>
and would potentially be simpler to code for
the_lanetly_052_ has joined #osdev
k8yun_ has joined #osdev
sprock has joined #osdev
k8yun has quit [Ping timeout: 256 seconds]
Brnocrist has quit [Ping timeout: 256 seconds]
Brnocrist has joined #osdev
ElectronApps has joined #osdev
heat has quit [Ping timeout: 256 seconds]
masoudd has joined #osdev
freakazoid12345 has quit [Ping timeout: 256 seconds]
garrit has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
k8yun_ has quit [Quit: Leaving]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Belxjander has joined #osdev
<geist>
Ugh, another internet outage
Electron has joined #osdev
ElectronApps has quit [Ping timeout: 256 seconds]
doppler has quit [Ping timeout: 250 seconds]
<geist>
yay back i think
<zid>
Maybe I should be selling internet to your poor wartorn country
doppler has joined #osdev
<zid>
One of you is probably a CS nerd, I was thinking about how to perfectly hash some slightly sparse integers
<zid>
I guess you could just do it like an fft? Sum of sines or whatever as a huge polynomial.
<g1n>
here is the link to it, there should be 2 files: paging.h and paging.c
<heat>
you've got your concepts mixed up
<heat>
1) urrr durr james molloy bad
<heat>
2) what's your definition of a page frame allocator?
<gog>
g1n: we went over this in our prior conversations, paging refers to the mappings between virtual and physical address space, where as the page frame allocator keeps track of the phsyical conventional memory pages
<gog>
i.e. it is possible to implement a page frame allocator without paging
<g1n>
oh
<gog>
and it is possible to do virtual address translation without a page frame allocator
<g1n>
so i don't need to load it on every new frame?
<bslsk05>
wiki.osdev.org: Page Frame Allocation - OSDev Wiki
<gog>
forget about virtual address translation for awhile because that's only confusing you and worry about understanding page frame allocation for the moment
<gog>
and then page frame allocation can later help you to make it possible to allocate page tables dynamically
<gog>
the bitmap allocator is simple because it can be implemented as a large array inside your kernel's data segment and can work independently of any address translation
<g1n>
but i am doind like arrays of arrays isn't it?
<heat>
no
<heat>
that's paging
<heat>
not page frame allocation
<g1n>
oh
<zid>
Memory is a large disconnected stack of integer addresses grouped into batches (pages). Your job is to pick which number to give to someone when they call *alloc().
<zid>
Try not to give someone the same number twice, try to be able to accept stale numbers that are no longer in use (*free()).
<gog>
i think i didn't help with your confusion because i showed you my solution, which depends on address translation being present and set-up with some page tables already in order to work
<GeDaMo>
Paging maps A to B; page frames keep track of which Bs are available
<zid>
That's an allocator.
<gog>
but in the meantime it's time to go to the grocery store
<zid>
Paging is an integer to integer mapping between those batches.
<zid>
handled by the cpu
<g1n>
oh so i need to make list of "pages" and store there value if this "page" is free or not free
<heat>
yes exactly
<zid>
That would be one way to do it yes
<zid>
I use a stack, you might use a bitmap that you search through, whatever.
<heat>
you need to find a way to manage pages (or page frames but I don't like that term) basically
<gog>
and i have an array of structures that acts like a singly-linked list
<heat>
page_alloc() and page_free() allocate and free a page
<heat>
try to get that working at first
<zid>
a singly linked list is a stack as long as you only return pages from one end :P
<gog>
true
<g1n>
heat: so it is like changes in that list current index to used and returns pointer to it?
<gog>
also my wife wasn't ready to go but i am leaving momentarily :p
<heat>
what list
<g1n>
heat: bitmap i mean
<g1n>
list of pages
<heat>
yes
<zid>
a bitmap specifically isn't a list it's a map :p
<heat>
assuming you know how a bitmap works you'd set the bit and calculate the pointer to the page
<g1n>
how would i calculate it?
<heat>
ok a primer on bitmaps
<zid>
We cannot make that assumption, it turns out.
<heat>
you know how bytes have bits?
<g1n>
yes
<heat>
well imagine each bit maps to a single thing
<GeDaMo>
table[page >> 3] & (1 << (page & 7))
<heat>
in the case of page frame allocation, each bit in the bitmap represents a page
<zid>
Pop quiz, how many bits in a page.
<j`ey>
PAGE_SIZE
<zid>
Incorrect.
<j`ey>
*KB
<zid>
Very incorrect.
<j`ey>
*B
<j`ey>
lol
<g1n>
1
<GeDaMo>
PAGE_SIZE * 8
<g1n>
lol
<zid>
GeDaMo is correct.
<g1n>
oh
<zid>
4096 bytes, each byte has 8 bits, so there are 16384 bits in one page.
<heat>
if you're scanning through the bitmap you're scanning what, byte to byte? something like that. You can try to see how with a i,j as (byte, bit in byte) you can calculate a number
<heat>
zid: it's obviously PAGE_SIZE * CHAR_BIT because who knows how many bits a char has
<j`ey>
and how big a page is
<zid>
nah it's always 4096 and alwys 8
<g1n>
heat: ok i will try, thanks
<zid>
Anyway, I tell you one popsicle stick represents 400 cows.
<j`ey>
whats 4096 * 8?
<zid>
32768?
<zid>
sorry I had to take my socks off
<heat>
g1n, great, try to understand it fully. I know osdev is pretty hard in the beginning but it starts to get easy as you get a grip in some concepts you might not already have
<zid>
Anyway, I tell you one popsicle stick represents 400 cows. So my 0st popsicle stick must be cow 0-399, my 1nd popsicle stick must be cow 400-799, my 2rd must be 800..
<zid>
Which batch of cows is popsicle stick 72?
<g1n>
heat: ok i will try :)
<zid>
g1n quick, the cows!
<zid>
Before they escape!
<heat>
by the way it's not PAGE_SIZE * CHAR_BIT but sysconf(_SC_PAGESIZE) * CHAR_BIT because PAGE_SIZE is not portable
<j`ey>
it was pseudo code :P
<zid>
My poor cows :(
<heat>
screw your python
<heat>
embrace POSIX.1
<zid>
heat I am sending you an invoice for my lost cows
<zid>
you scared him off
terminalpusher has joined #osdev
<heat>
lost cows turn into dirty cows and boom you've got a CVE on your hands
terminalpusher has quit [Remote host closed the connection]
<zid>
Hmm I think I am missing some mappings up at -2GB, all I see is one page of .text, I apparently have no stack
<zid>
I wonder if I did that in .bss in my real kernel
vdamewood has joined #osdev
freakazoid343 has joined #osdev
gog` has joined #osdev
<gog`>
zid: btw my printf appears to work well, im starting to add more useful debug messages here and there
<gog`>
since you asked
<gog`>
2 days ago
<zid>
nice
<gog`>
lol
<zid>
I just did it incrementally
<zid>
I added %d then added %x later on by adding an extra switch case, etc
<zid>
I just did "Oh I want to print this as x" printf("%x", 0xBEEFC0DE); printf("%x", 0); and made sure it printed the right thing, then replaced them with the real line, move along!
<gog`>
i was doing that then got a little fixated
<zid>
For some that'd be annoying, shifting gears in the middle
<zid>
but it keeps me motivated
<zid>
I like microtasks
<zid>
I've just been staring at my editor currently, it says int main(void){ while(1); }
<zid>
for a day
<_eryjus>
yup, too much ADD for me... I forget what I was doing
<gog`>
i just do a thing and get itchy if it's not "proper"
<zid>
did you get rid of all your count++s
<gog`>
sometimes i can ignore it and move on with important things other times not
<gog`>
that's up next, I'm gonna do that stream struct
<zid>
GeDaMo: nextbyte requires the memory map to be.. a thing
<zid>
so I need to implement mmap sorta first
<GeDaMo>
Ah, I thought the BIOS might be in a file
<zid>
after I've eaten my chips make sure I unmap the 1M mappings and then map the vga bios to a random pml4e
<zid>
pick one for me
<GeDaMo>
1 << 21
<zid>
..that's bigger than 511 I think
<zid>
511 and 510 are taken
<zid>
510 is my recursive mapping, 511 is kernel memory, could use some of that though!
<zid>
I have what, 512GB to play with?
heat has quit [Ping timeout: 256 seconds]
<gog`>
309
<zid>
0x9A8000000000 it is then
<gog`>
\o/
<vdamewood>
Pika pika!
<zid>
Okay question, should I try share mem.h with boot/
<gog`>
yes
<zid>
which is a separate binary that chain loads this kernel, and passes a memory map along
<zid>
or just manually keep them in sync like a pleb
<gog`>
one big header
<gog`>
cram everything in it
<zid>
actually I only need one struct dec
<gog`>
not enough structs
* vdamewood
gies gog` a struct fishy
<gog`>
int eat_fishy(struct fishy *f);
<zid>
Halp I can't get #include to work
<zid>
oh do I need.. ../../ fancy
<zid>
couldn't figure out what #include was relative to there for a second, I was including a header in another dir that was including a header from a different dir
<gog`>
oops
<vdamewood>
Now I want fishy.
<vdamewood>
Ohh... the local meat market has smoked fishy.
<vdamewood>
They should be open nowish, too. Yay! I can has fishy!
<zid>
if you hate it because it's technologically inferior, you're wrong and you should feel silly. If you hate it because it stopped z80 becoming the one true cpu? Zealous but acceptable.
<dmh>
no valid reasons considering there are several decades of assembly available to handle all of the boot and legacy things i can even pretend to argue
<zid>
even hating that would be stupid
<dmh>
beating z80 good reason
<dmh>
yea, i thought it was bad till i did something else
<zid>
because.. *any* arch would have that much legacy, if it were *actually used*
<heat>
arm is full of crap
<dmh>
at least its somewhat standardized yea
<Arsen>
heat: python3 -c 'import fcntl, termios, struct; struct.unpack("HHHH", fcntl.ioctl(0, termios.TIOCSWINSZ, struct.pack("HHHH", 100, 100, 0, 0)))' running this doesn't deliver a signal anywhere actually
<heat>
armv8 was a nice re-write of crappy arm
mahmutov has quit [Ping timeout: 240 seconds]
<zid>
It was designed by customer need.
<dmh>
as much fun as keeping up with uboot upstream is
<dmh>
does x86 have shadow registers
<dmh>
i overused some SRS
<heat>
dunno what that is
<Arsen>
ah nvm it does deliver to the child
<dmh>
shadow register sets, for push/popping context
<dmh>
usually
LostFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
dormito has joined #osdev
<dmh>
helps quite a lot on eg mips code size in some stuff. i think it finally in like freertos port
<dmh>
but anyway im splitting hairs and finding any excuse to not do stuff
<heat>
well no
<heat>
you use the good old stack :)
<heat>
though SMM does have something similar I think
<dmh>
i wouldnt be surprised if the concept was hiding somewhere
<dmh>
it was really nice when using a lot of regs tho hehe
<heat>
x86 is really crufty in some aspects but it makes the world go round and we should appreciate it
<dmh>
it could have ended up a lot worse considering
<zid>
It's crufty *because* it makes the world go round
<heat>
you can't just end up going: hehe riscv go brrrrrrrrrrr
<dmh>
yea i already had that fetish
<zid>
If anybody actually used riscv it'd have all sorts of silly extensions, like divis- oh wait
<dmh>
yea, lol beat me to it
<dmh>
which extension set we targetting today
<heat>
no x86 is crufty because it was poorly designed and no-one got around to actually re-design it well
<heat>
x86_64 was close but it's still weird
<zid>
they redesigned it well twice
<zid>
the first one took two bites though
<zid>
286 sucked
<heat>
why is fs and gs a thing but no other segment?
<heat>
why is swapgs a thing?
<zid>
swapgs already been redesigned by intel, FRED
<zid>
but now we have CRUFT
<zid>
cus swapgs will stay extant
<heat>
in a new extension which most CPUs dont have
<heat>
thanks fred, very cool
<dmh>
lol
<zid>
you mean.. like *every* redesign?
<zid>
"resign it" "omg you redesigned it, thanks very cool smh"
<heat>
if it were done properly from the start you wouldn't need to add code for both ways of doing it
dennis95 has quit [Quit: Leaving]
<dmh>
well im still in microcontroller/mpu land where i get luxury of knowing everything going on
<dmh>
relatively speaking
<dmh>
but its time
<dmh>
long weekend ahead
<dmh>
time to waste it just thinking about cool projects
<heat>
just do it
<heat>
write an OS
<klange>
waste ten years of your life writing an OS and then complain about it on irc
<heat>
not a waste if its fun
<klange>
It stopped being fun around the sixth year.
dude12312414 has joined #osdev
gog has joined #osdev
<heat>
:(
<gog>
:(
epony has quit [Ping timeout: 240 seconds]
<dmh>
hehe
<dmh>
ive spectated yalls progress that long
<heat>
hehe other osdevers go beep boop
<gog>
i've been at this on and off for a decade and all i have to show for it is uh
<gog>
i got nothing :(
<FireFly>
I think I joined #osdev a bit less than a decade ago, but perhaps fortunately I only got to the ideas stage before giving up on osdev .p
<FireFly>
:p*
<gog>
yes
<gog>
give up on your dreams
<FireFly>
nah :o
<FireFly>
not sure that's good advice
<gog>
give up on your dreams if they involve osdev
<heat>
dont
<gog>
sorry
<heat>
also what are you talking about you have an OS
<gog>
i barely have a kernel
pretty_dumm_guy has joined #osdev
<heat>
you have a scheduler
<gog>
i don't even have that
<heat>
that's better than 95% of osdevers
<heat>
i see task switching
<heat>
and demand paging
<gog>
idek if the task switching works for real :p
<gog>
demand paging i'm pretty proud of though
<gog>
my memory management is shaping up fairly well
<heat>
keep going then :)
<gog>
it's gonna need a big refactor at some point though
<j`ey>
demand paging = page in on page faults?
<gog>
well, it has anonymous memory
<gog>
not exactly demand paging
<gog>
but the bones are there
<heat>
little by little you start getting fancier and fancier until you get to user-space, then you get a shell, then eventually you run gcc
<gog>
nah i'm gonna run clang
<gog>
but compile with gcc
<heat>
proud of you
<gog>
aw thanks
<heat>
note that you can't canadian-cross compile gcc with clang
<gog>
in the next week my goal is to actually get scheduling working
<gog>
i have two weeks and change free from any real responsibilities so i might as well make use of it
<gog>
as soon as i'm done fiddling with this printf
masoudd has quit [Ping timeout: 240 seconds]
MrPortmaster has joined #osdev
MrBonkers has quit [Ping timeout: 240 seconds]
<dmh>
well i didnt give up and made some fs stuff for a product, and ended up w a few task schedulers written from scratch for tiny mcus
<dmh>
that was good background
<dmh>
and i actually know c now :D
<dmh>
honestly if desktop risc-v boards were more a thing i'd give those a shot again. i see that second sifive board is almost reasonable but frig
<dmh>
kinda wanna make something with only cli and network anyway
<dmh>
im done waxing poetic tho
epony has joined #osdev
<heat>
dmh, -machine virt if you don't need it to be real hw
<Bitweasil>
dmh, Pi Pico? :)
<Bitweasil>
It's got enough guts to do something minimal.
<heat>
i got a pi zero 2 w for 15 euro
<heat>
pretty minimal and really really not minimal at the same time
<heat>
quad core, 512MB of ram
<heat>
64-bit too
PapaFrog has joined #osdev
<dmh>
i have many many many far better mcus and sbcs
<dmh>
so good on that front
biblio has joined #osdev
<dmh>
one of the taskers was for pic32mz which i rather enjoyed (microchip sharty tools aside)
<dmh>
dont get me started
<dmh>
ill just bochs and qemu and move on :D
<Bitweasil>
A Pi Zero 2 would be perfect for some projects I have. :/
<Bitweasil>
I don't think they can be reasonably obtained.
<Bitweasil>
Like the rest of the Pis. :(
<heat>
there were "plenty" here
<dmh>
yea well, try to buy a broadcom soc too
<heat>
also a decent number of rpi400s
<klange>
I had no trouble getting my 400.
<Bitweasil>
I need something small. :p
<dmh>
i got a few pi zero 2 w recently in bulk camera kits
<dmh>
digikey had boatload last i looked
<dmh>
which admittedly was a few month ago now
<dmh>
but fu that stuff
<dmh>
i prefer actually open boards
<dmh>
and better socs, and offchance you want to make your own board etc
<heat>
i want to get a pin header and some soldering iron and learn how to solder
<dmh>
oh yea its great
<heat>
it's the only way my zero 2 w can be useful for osdev
<Bitweasil>
f--- me. The Zero 2 W is going for $50-$80 on eBay.
<heat>
cuz I need serial
k8yun has quit [Quit: Leaving]
<dmh>
get one of those cheap packages of male header strips and tons of boards and just go to town on that till you are good at it, then learn how to drag solder tqfp, rework etc and you're good to go
<heat>
i only have a single board :P
<dmh>
heatgun is nice for popping off some stuff
<dmh>
i mean uhh
<Bitweasil>
A... 8GB Pi 4...
<Bitweasil>
$200.
<dmh>
like plated protoboard
<dmh>
so you can just go nuts perfecting solder flow, temps etc
<dmh>
everything so overpriced these days :(
<heat>
well I don't need to be an expert
<Bitweasil>
60/40 and 250C tip temp for light work, 300C for heavier stuff like ground planes.
<heat>
just want to get something serviceable done
<klange>
I think I paid ¥12000 or something for the 400 and that was the full kit.
<heat>
from what I've gathered soldering the gpio header isn't that hard
<heat>
the rpi400 is selling for like 100 euro here
<dmh>
oh yea that header
<dmh>
you can hit and run with a cheap iron and be done w it
<heat>
hmm actually maybe I could just get a mini displayport thing and use that for debugging
<dmh>
you only need to hit 3 pins on the right side
<dmh>
or just solder wire into it
<dmh>
power power ground tx rx only 4 you need to memorize ;)
heat has quit [Remote host closed the connection]
heat has joined #osdev
PapaFrog has quit [Ping timeout: 250 seconds]
xenos1984 has quit [Read error: Connection reset by peer]