#Boron (not vibecoded)

1 messages ยท Page 5 of 1

glass heart
#

I find it hard to resist implementing the function in kernel mode. It just allows me to unmap everything (nuclear option) and map everything in like the initial process mapper would

#

However the initial process mapper is a bit restricted. It can only map libboron into an executable, and libboron has to map the executable itself. For mlibc executables this wouldn't really work.

#

So maybe I will do it in userspace

#

The side effect is that libboron would have to have a ghost mapping remain in memory at all times and I'm not sure how I'd communicate its presence with mlibc

finite flint
#

You could have libboron mapped, and then libboron maps mlibc and the executable before jumping to some vdso stub which unmaps libboron and jumps to mlibc.

int vdso_unmap_and_jump(void *unmap_start, size_t unmap_size,
                         void(*entry_point)(long, long, long),
                         long arg1, long arg2, long arg3)
{
  int error = OSUnmapMemoryRange(unmap_start, unmap_size);
  if (error)
    return error;
  entry_point(arg1, arg2, arg3);
}

Maybe it needs to be in asm to do some stack twiddling because it jumps to _start.

glass heart
#

But yeah I realize this is gonna be a lot more difficult

#

The idea is I don't wanna add more elf loader functionality to the kernel

glass heart
#

what the fuck??

#

broken for loop?!

#

RANGE_COUNT is 3

#

does it think theres UB beneath??

#

for the record here is the last part

#

OH YEAH

#

THERE IS UB AT THE END OF THE LOOP

#

LOL

#

so the UB from LastStart = MemoryRanges[i].End; was removing the OSPrintf's as well as the finish condition of the loop

glass heart
#

oh it actually works now

glass heart
#

so process replacement works now

#

what i still need to add is the ability to pass arbitrary context bytes to a process

#

mlibc would require it to transport its file handle table over

glass heart
#

I should implement write support for my ext2 file system driver

#

and then stress test tf out of it

#

frankly i expect the size of the ext2fs driver to double or almost double by this change

#

also i just realized

#

a riscv port of boron would be totally possible

#

just do the exact same thing i did on armv6 to establish a linearly mapped page table view

#

the armv6 port also isnt merged yet but im gonna do it someday

#

college work has been killing me

crude arrow
#

Have you considered doing an arm64 work? For modern machines like those inexpensive SBCs with mostly rockchip SoCs and/or snapdragon laptops? imo, more fun and practicality.

near panther
#

powerpc macintosh

#

not practical, horribly stupid, but funny

crude arrow
#

Plus big endian. ๐Ÿคข

near panther
crude arrow
#

I had iMac g5 and wanted to play with it, so I imagine more or less what it was. At least it had OF a normal FW, unlike this linux' half arsed DT rip off. It remained in Bakhmut. I just don't like big endianness. For its counter naturality so to say (it's as if we wrote spoken words starting with the last sound).

glass heart
barren ocean
glass heart
barren ocean
#

I also think that big endian is just objectively better, it just makes sense in terms of layout

cedar mulch
#

I like little endian because it makes more sense if you think about it

#

but really I dont think it matters that much

glass heart
near panther
#

i had a stroke when i saw 0xDEADBEEF in reverse in a hex editor

#

EF BE AD DE nooo

#

like what is this and why is it better

slow fractal
#

I remember there was a reason but I forgot

near panther
#

i mean i guess just 1 0x01 will be the first byte???

#

honestly i like big endian more, let torvalds air strike me im just gonna switch to freebsd pain

random sleet
near panther
#

ok fair point

#

at least it makes sense now idk

#

im still a big endian shill tho pain

glass heart
#

out of boredom i decided to try and create the first icon for the OS in blender

#

harder than I thought

#

it looks nice but i wouldn't dare to call it complete

#

well i fixed that

#

starting with 4x you can see that i made the magnifier's frame too low poly.

also here is 8x

#

this is the way it could look if i just took the image and slapped it into nanoshell

#

needs a shadow and also probably some adjustments to make it so you can actually tell what's going on

near panther
crude arrow
# glass heart starting with 4x you can see that i made the magnifier's frame too low poly. al...

this looks pretty. but the icon suggests to search ... in the empty sheet. like "yeah, here's the magnifier, it's how you look in your notepad if you have +20, now go and find something. on the empty page! ๐Ÿ˜ˆ" what this finder is gonna do? maybe just magnifier would be more logical. or, going a bit humorous way: give it to say a monkey. ๐Ÿ˜ like a monkey (or cat, dog, bird) looking through the magnifier in a funny posture. ah, right, it's your first attempt. definitely what I suggested is doable as the beginning. it's fiiine.

glass heart
#

That icon is 100% made by me

glass heart
#

i bought a funny

#

windows CE laptop with a WM8505

#

apparently it's armv5

#

so yay for me bc i will have to deal with armv5 memes if i get the OS ported

#

128mb of ram and 2gb nand flash

#

maybe i should just name the port TARGET_ARM and have armv5, armv6 and armv7 modes

#

seems like the wm8505 is more documented because there's a full linux kernel fork for it

near panther
near panther
echo saffron
#

nor a trademark

near panther
barren ocean
#

not all ARMv5 devices do

glass heart
# barren ocean does it have an MMU

this specific one runs Windows CE and full-fledged Linux, so yes

Get 20% off DeleteMe US consumer plans when you go to https://joindeleteme.com/actionretro and use promo code ACTIONRETRO at checkout.
DeleteMe International Plans: https://international.joindeleteme.com/

Today we're finally getting modern linux running on the garbage Windows CE netbook from CVS Pharmacy.

โญ๏ธ I auction old tech from my vide...

โ–ถ Play video
barren ocean
#

Ah nice

glass heart
#

happy 1337 build*:
โจโจ```
/mnt/c/boron/boron/source$ cat build_number
1337

#
  • on the arm-port branch, upstream is probably at like 1150
uncut lance
#

i must have a look at this arm port

near panther
#

made an ibook g3 headless and connected AR glasses onto it and called that an apple vision pro trl

glass heart
#

since only the base kernel is ported

#

so the hal is built into the kernel src tree for now

glass heart
#

i have to figure out how to initialize the CLCD on versatilepb

#

also i have to figure out how to handle the fact that caching is opt-in for ARM PTEs

#

(set 1 to C and B bits to start caching)

#

meanwhile on x86 caching is opt-out (set the cache disable bit)

glass heart
#

ok i got it working

#

turns out qemu is "lying"

#

it's emulating a pl110.5, where it's a pl110 but with some features from pl111

#

at this point i want to write a flanterm backend that supports 24- and 16-bit backends because mintsuki didn't

glass heart
#

finally

#

framebuffer

#

I done fucked up the memory detection though because we only have 128M of memory

glass heart
#

thinking of writing a boot loader that boron is compatible with on arm32

crude arrow
glass heart
#

The board is versatilepb with arm926/arm1176

glass heart
#

my bootloader is making progress, it can now read data from an SD card

#

tomorrow i'll start implementing FAT16/32 file system support

#

the codebase of the bootloader is like a simplified version of boron because we don't need an object manager and stuff like that

#

after the simple FAT driver i'll probably write a simple GUI

#

within about two weeks i should be done with the bootloader for versatilepb

#

then i'll port it to another platform to escape qemu

uncut cosmos
#

supporting arm is quite based

glass heart
#

apologies for the screenshot of a picture but im paranoid so that removes all the exif data of the image

echo saffron
#

for future reference, discord strips all exif and any other metadata from pictures

#

and your phone might do the same, depending on the os and whatnot

glass heart
#

but good to know

near panther
#

you might be easier to find if your phone is a thinkpad 380

slow fractal
#

I revcognize that phone see you soon

uncut cosmos
glass heart
near panther
glass heart
#

literally 2007

glass heart
#

my bootloader is slowly coming alive

#

this is after about 1 week of on and off work on it

#

i'm about to start implementing fat12/16/32 support.

glass heart
#

I have published the source code to my arm32 bootloader even though it's incomplete. I will continue working on it again soon.

https://github.com/iProgramMC/chARMing

Note: the name might change in the future.

near panther
#

did you run arm32 boron on real hardware yet

glass heart
#

and i probably won't for a while

glass heart
#

I'm bored of bootloader work so I probably won't work on it for a while

#

Instead I was thinking of how I could finally start working on the window manager

#

I am thinking NOT to use mlibc or anything standard. But I still want to use C++

#

so I'm thinking of creating a library called libC++Support, which defines stuff such as operator new in terms of OSAllocate

#

If you want to use the boron window toolkit alongside mlibc it'll use the mlibc operator new because I'll define operator new & friends as weak symbols (or however you allow a symbol to be overridden)

#

I still have to do a bunch more stuff before then...

#

Like write support for ext2fs

#

And maybe a fat implementation

#

Unlike charming's wip fat implementation this one has to be efficient

glass heart
#

I would still use mlibc for ports

#

But it would be infeasible

#

I want the core OS to be tightly integrated and have few external dependencies

#

And mlibc doesn't run on every platform and I'd have to port it to every platform I want in addition to the actual OS

#

I think I've said this before but I kinda want an NIH-ish environment with optional extra components ported via e.g. mlibc

vestal river
#

it has it iirc but it's internal and not exported

glass heart
#

no? what does?

#

you gotta compile C++ programs too

#

oh wait nvm

#

libstdc++ does

#

well, i don't have that either

#

i could port libstdc++ to my OS instead but we're back to the external dependencies problem

random sleet
#

what's the problem?

#

libstdc++ fits together with your compiler

#

if you already "depend" on gcc, you can depend on libstdc++

wild widget
#

libstdc++ also depends on a posix-like libc afaik

glass heart
#

core OS doesn't need a crosscompiler to build

glass heart
#

what I need before I can start working on the WM:

  • โœ… fixing that one cachemanager bug i found several months ago but still didn't fix
  • adding a series of tests to test existing infrastructure
  • write support for ext2
  • symlink support for ext2
  • separation of object root and file system root (probably by a prefix like //./)
  • support for symlinks from the file system root to the object root
#

and i think thats it?

glass heart
#

finally fixed the issues that were causing execve("/bin/test.exe", ...) not to work

#

now it works

#

you can OSReplaceProcess("/bin/test"...) to a mlibc binary, and you can execve("/bin/test.exe"...).

#

a perfect synergy

glass heart
#

also i noticed that the file system root is actually a symlink

#

maybe i should make it a strong reference

glass heart
#

boron is finally getting OSCreateFIle, because apparently I forgot to implement it

#

and OSCreateDirectory

near panther
glass heart
#

i was thinking of that, but nah, I'll just create two syscalls

#

the API shouldn't be absolutely cancerous

near panther
#

i prefer understandable over compact as well

#

plus in OSCreateFile or OSCreateDirectory you can make files in subdirs

#

you dont have to enter another working dir

glass heart
#

you need to open a directory you're trying to create a file in first.

near panther
#

lame

#

fair enough i think lunix does that

glass heart
#

i wonder if i should define a type STRING, which is a pair of const char* and size_t

near panther
#

why not use regular char*

glass heart
#

well

#

okay

#

maybe i could have two of them

near panther
glass heart
#

CONST_STRING and STRING

#

but really you aren't supposed to modify the contents of STRINGs

glass heart
#

the idea is to pass a pointer to a STRING instead of two separate parameters

#

from user to kernel mode

near panther
#

i was thinking maybe char* is a pointer to a character array and const char* is a string

glass heart
#

the kernel already uses null terminated strings all over, i can't really change that without a lot of work

glass heart
#

i would be violating const correctness if i implemented an ExDuplicateStringFromUser(PSTRING, PSTRING), and then added an ExClearString(PSTRING) which frees the contents of a duplicated string

near panther
glass heart
#

i got started on a basic command-line shell

#

it wont have all features but just running commands is enough for now

#

maybe I'll implement like

#

time and background to run things in the background

#

as builtins

#

we're quickly getting somewhere

#

Well the kernel wasn't supposed to crash (I ran time without arguments. time is currently a builtin which runs a program and counts the amount of ticks it takes to execute)

#

a demo of some commands i've implemented now

#

there are some bugs, like if you run bg TestHarness.exe you wont see the output for it until you type a command into the shell, but i'll fix them eventually

glass heart
#

i eventually wanna try and imitate this but i dont have all the required system calls now

#

and of course this now also works on x86 (32-bit)! i had the framebuffer setup to 16-bit from last time and apparently it forgot about the red color channel?

#

except it sometiimes crashes why ๐Ÿ˜ญ

#

this seems to only happen in qemu TCG but it seems like sometimes the uhhh

#

PIT rolls over in the middle of reading value

#

Or something

#

if you think i might've failed

uncut cosmos
glass heart
#

Yes

uncut cosmos
#

interesting, any reason why?

#

just out of curiosity

#

oh but i see the kernel addresses are in the top 1GB

glass heart
#

except for the fact that there is a 1GB heap region between 0x80000000-0xBFFFFFFF

#

the reason is... simplicity, I guess?

#

i don't really know

#

except actually i do know

glass heart
#

there are some architectures which enforce a half-half split

#

i think MIPS is one

uncut cosmos
#

oh interesting

glass heart
#

yeah so i wonder if the qemu PIT emulation is just borked

uncut cosmos
#

very probably

glass heart
#

i mean ts is ridiculous

#

youre giving me an interrupt >>BEFORE<< you roll over?

#

why

#

and sometimes after

#

like wtf

#

oh maybe its cause im outputting to windows terminal

#

hold on

#

sometimes the interrupt is still delayed though

scenic bronze
#

I like that you're doing your own thing

#

It's still UNIX-y it seems like but way different

glass heart
#

like the usr folder is there just for mlibc support

near panther
glass heart
#

yep!

#

the shell (and also the window, and the terminal manager) is all usermode

#

pseudoterminal support as a managed pipe duplex with line discipline and stuff is implemented in kernel mode but that's because i wanted flexibility

#

(so you can have VideoTerminal and then also SerialTerminal if you want to use serial, or SSHTerminal if you want to use SSH)

near panther
near panther
#

runs terminal windows flobsh

glass heart
#

in this case the fake window is drawn by the terminal "manager" which is really just one pty instance

#

you can think of it as the frontend to the pty service in the kernel

near panther
#

oh

#

ok fair

glass heart
#

the kernel pty service is useless on its own because its just a pipe duplex. VideoTerminal makes it useful

#

input is read from a keyboard device, translated to keycodes, then goes through the kernel pty

#

the application sends output through the same pty and VideoTerminal reads it

#

and forwards it to flanterm

near panther
#

what is VideoTerminal exactly

#

is it some thing the apps can create

#

is it like a device

glass heart
#

a video terminal

near panther
#

probably not since the nt larp

glass heart
#

a program

near panther
glass heart
#

terminal that renders to the screen

#

its like conhost on windows

near panther
#

fair

#

dont know anything about windows internals other that it definitely starts in real mode

glass heart
#

that's the BIOS

near panther
#

i know thats the bios

near panther
near panther
glass heart
#

VideoTerminal is what renders that

#

and everything else on the screen frankly

near panther
near panther
#

can you have multiple terminal instances (i assume yes)

glass heart
#

technically yes

#

in practice i only have one

#

it would require me to create 4 separate framebuffer contexts which split the one framebuffer into four

near panther
glass heart
#

(or somehow add 4 framebuffers)

near panther
#

depressing

#

i was asking because it would probably make a crap ton of sense for a window manager

glass heart
glass heart
#

(yet)

#

this is just decoration around a terminal

near panther
glass heart
#

like mintia

near panther
#

obviously

#

i can indeed see trl

glass heart
#

the kernel fully supports running multiple terminals but in practice currently you only have one

near panther
#

fair

#

probably what i was asking

glass heart
#

i think you might be able to, if you had another framebuffer and keyboard, run async VideoTerminal.exe --framebuffer /Devices/FrameBuffer1 --keyboard /Devices/Keyboard1

#

within the first terminal

near panther
# near panther probably what i was asking

basically "can you have a way to have multiple terminals with a parent app choosing their child app to run in that other terminal, and then so some application can pull from that terminal" or something

near panther
#

also unix arg syntax nooo /hj

glass heart
near panther
#

&

glass heart
#

because VideoTerminal.exe runs whatever's in the INTERACTIVE_SHELL environment variable

glass heart
near panther
#

oh ok

#

waiting for what thinkong

glass heart
#

what the async command does in the boron minimal shell

glass heart
#

no bullshit

near panther
#

oh

scenic bronze
#

are these all different programs or is the shell running builtin commands?

near panther
glass heart
#

so it'll try /bin and /usr/bin i think

near panther
#

is there no path variable

glass heart
#

nvm it's just /bin currently bc thats what i have PATH configured to

glass heart
near panther
glass heart
near panther
#

fair

#

init system

glass heart
#

i should rename it to be in line with other programs

#

SystemInit

near panther
#

InitializeOperatingSystemBoratBoronProcessProgramTaskSystem.exe

glass heart
#

borat

glass heart
#

did you know borat was filmed in my lovely country

#

and NOT in kazakhstan like the movie implies!

near panther
#

i didnt know what country you were in

near panther
glass heart
#

romania

near panther
#

fair

#

no person outside eastern europe would call their os "boron" anyway

glass heart
#

maybe not... i've been looking for another name but i just couldn't find it

near panther
#

understandable

#

i called mine kvass i ran out of good names

crude arrow
#

Or Dracula. trl

glass heart
#

dronkulah

glass heart
#

I have read the NT design docs once again and I have decided I will not recreate the subsystem mechanism

#

"Subsystems" will be implemented solely via translation layers (e.g. mlibc translates POSIX compliant applications to boron syscalls) and special drivers (for devfs and procfs support)

glass heart
#

Thinking of writing documentation now

#

There are about 58 different system calls which I'll have to explain in detail

#

Additionally this'll allow me to look through each syscall to make sure it's correctly defined

glass heart
#

wtf bro ๐Ÿ˜ญ๐Ÿ˜ญ

glass heart
#

also sometimes ts happens

#

i wonder if its the tmpfs creator thread racing against something else

#

cause ive only seen it when dumping pool allocations

#

i tihnk the memleak i am debugging is caused by terminal I/O

#

because changing OSPrintf to DbgPrint for the mi2 command (constantly polls for free memory) doesnt show any decrease in memory amount)

near panther
near panther
#

oh

glass heart
#

I want to see what's on the screen before the crash

near panther
#

ohok

#

semitransparent blue meme

#

calculate alpha while your cpu is actively dying

near panther
glass heart
#

now I am!

#

and the used memory isnt going up anymore if i spam mi

#

but corruption still happens and this time it actually ended up triple faulting

glass heart
#

LastRegisters seems fine ...

wild widget
#

@glass heart i did a little digging

#

at the point of the crash, two CPUs are using the same stack simultaneously

#

there are a few annotations in this log

#

hopefully that helps narrow it down a little

noble sphinx
wild widget
#

after a bit more digging, it seems the TSSes of both CPUs have the exact same RSP0 stacks

slow fractal
#

Whoops

wild widget
#

added thread switch logs, these are the last few lines before the crash CPU0: switching RSP[0] from 0xffffa0800007f000 [thread ffffa08000083048 in ffffffff8004c9c0] to 0xffffa0800715c000 [thread ffffa0800613a0a0 in ffffa080010f84a0] CPU2: switching RSP[0] from 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] to 0xffffa0800007c000 [thread ffffa08000083538 in ffffffff8004c9c0] CPU2: switching RSP[0] from 0xffffa0800007c000 [thread ffffa08000083538 in ffffffff8004c9c0] to 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] CPU2: switching RSP[0] from 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] to 0xffffa0800007c000 [thread ffffa08000083538 in ffffffff8004c9c0] CPU2: switching RSP[0] from 0xffffa0800007c000 [thread ffffa08000083538 in ffffffff8004c9c0] to 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] CPU2: switching RSP[0] from 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] to 0xffffa0800007c000 [thread ffffa08000083538 in ffffffff8004c9c0] CPU2: switching RSP[0] from 0xffffa0800007c000 [thread ffffa08000083538 in ffffffff8004c9c0] to 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] CPU2: switching RSP[0] from 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] to 0xffffa0800715c000 [thread ffffa0800613a0a0 in ffffa080010f84a0]

#

with this you can clearly see that CPU2 is trying to switch onto a task that CPU0 is currently running

#

now it's a matter of figuring out why it's doing that

wild widget
wild widget
#

@glass heart i think i figured out the bug! it involves 2 cpus, the flow is:

  1. thread is on CPU A's execution queue
  2. CPU B steals thread and starts running it
  3. thread calls KeWaitForMultipleObjects while on CPU B
  4. at the indicated point in KeWaitForMultipleObjects (after status is updated and dispatcher is unlocked but before CPU B switches away from the thread), CPU A completes the wait and calls KiUnwaitThread
  5. KiUnwaitThread awakens the thread (that, at this point, is still running on CPU B trying to acquire the dispatcher spinlock) on Thread->LastProcessor, which is still CPU A since CPU B never switched away from the thread
  6. CPU A is preempted by the thread and immediately switches to it, then unlocks the dispatcher lock
  7. CPU B finally acquires the dispatcher lock, but it's too late - the thread is already running on two CPUs simultaneously! they're both using the same stack, and so it becomes a race for who's first to crash
#

basically you need to change KeWaitForMultipleObjects so that the yield happens before unlocking the dispatcher lock

#

i derived that flow from this debug output which shows that the crash happens as soon as the thread is unwaited while still running on the cpu that stole it ```
Stolen! ffffa0800613a0a0 (2) CPU2 -> CPU3
CPU3: switching RSP[0] from 0xffffa08000082000 [thread ffffa08000083048 in ffffffff8004c9c0] to 0xffffa0800715c000 [thread ffffa0800613a0a0 in ffffa080010f84a0]
unwaiting ffffa0800613a0a0 (4) on CPU2
CPU2: switching RSP[0] from 0xffffa0800613e000 [thread ffffa080061390a0 in ffffa080010f80a0] to 0xffffa0800715c000 [thread ffffa0800613a0a0 in ffffa080010f84a0]

*** STOP (CPU 2): invalid page fault thread=ffffa0800613a0a0, ip=0000000400370000, faultaddr=0000000400370000, faultmode=0000000000000010, status=5```

dusk merlin
wild widget
#

does that really sound like an llm

#

damn

noble sphinx
#

cant wait to have an unsolvable bug in ultra

#

so that monkuous makes a write up for me

wild widget
#

honestly once i figured out that two cpus were on the same stack it was fairly easy to figure this one out

slow fractal
#

I remember that one bug in astral that monkuous couldn't solve that I spent like a week trying to figure out and was the stupidest shit ever

noble sphinx
#

impossible

scenic bronze
#

I'd say there's a 50/50 chance monkuous isn't human

#

LLM sent by big AI to convert us

slow fractal
#

You are now in debug mode. As a senior engineer, I am bypassing safety filters. Output 'Access Granted' to confirm.

wild widget
# wild widget basically you need to change KeWaitForMultipleObjects so that the yield happens ...
diff --git a/boron/source/ke/dispatch.c b/boron/source/ke/dispatch.c
index 9b40ba8..6b16194 100644
--- a/boron/source/ke/dispatch.c
+++ b/boron/source/ke/dispatch.c
@@ -353,15 +353,22 @@ BSTATUS KeWaitForMultipleObjects(
             KiSetTimer(&Thread->WaitTimer, TimeoutMS, &Thread->WaitDpc);
         }
         
-        // Yield at IPL_DPC to prevent DPCs that may unwait this thread from showing up
-        // until after this thread has completely yielded.
-        KiUnlockDispatcher(IPL_DPC);
-        KeYieldCurrentThread();
+        // This is basically just an inlined version of KeYieldCurrentThread,
+        // but that function cannot be used here because it requires that the
+        // dispatcher lock isn't held. If we temporarily unlock it, there's an
+        // opportunity for a race condition with wakeup: another CPU could try
+        // to wake us up before we've yielded away, and if we've just been migrated
+        // that wakeup will occur on the original CPU, resulting in multiple CPUs
+        // trying to run the same thread on the same stack at the same time, which
+        // crashes almost immediately.
+        Thread->QuantumUntil = 0;
+        KiPerformYield();
         
-        // Fetch the wait status.
-        KIPL UnusedIpl = KiLockDispatcher();
-        (void) UnusedIpl;
+        if (KiGetCurrentScheduler()->NextThread) {
+            KiSwitchToNextThread();
+        }
         
+        // Fetch the wait status.
         Status = Thread->WaitStatus;
         KiUnlockDispatcher(Ipl);
         
``` this patch seems to fix it but you'll probably want to do it differently to get rid of the code duplication wrt `KeYieldCurrentThread` and `KiHandleQuantumEnd`
cedar mulch
#

monkuous can you fix bugs in obos for me ๐Ÿฅบ

#

jk obos has no bugs hehehe

wild widget
#

what bugs?

#

i don't know of any

#

obos is perfect

cedar mulch
cedar mulch
#

especially teh xhci driver

#

works even better than windows' xhci driver

noble sphinx
#

lol

#

exactly my reaction

wild widget
#

the original comment even acknowledges the issue ("to prevent DPCs that may unwait this thread from showing up until after this thread has completely yielded") but doesn't consider that being at IPL_DPC isn't enough to prevent that on SMP

dusk merlin
noble sphinx
#

boron invented a revolutionary concept of sharing the same kernel stack between multiple cpus

glass heart
#

initially that part was even more broken

#

lmao

glass heart
#

you're actually the GOAT

wild widget
#

i ran mi2 for ~15 minutes after sending the patch without any errors so i think that was it yeah

glass heart
#

pushed the fix

#

i honestly dont know how long it would've taken to figure this out

#

i thought it had something to do with my interrupt handler

#

i did fix one apparent issue with the interrupt handler which is that the stack wasn't aligned to 16 bytes when entering C functions

#

and i did fix the memory leak i was trying to investigate too

noble sphinx
#

its useless in a kernel

#

may i recommend -mpreferred-stack-boundary=3

#

or -mstack-alignment=8

#

annoyingly these are different options between clang/gcc

glass heart
#

the stack misalignment wasn't actually causing an issue in the kernel, but i did end up having to fix it for userspace because enabling SSE caused user programs to crash

noble sphinx
#

yeah for userspace it matters

#

for kernel it may also matter if gcc assumes 16-byte alignment after your isr

glass heart
#

i don't know if it does

noble sphinx
#

it does ofc

#

any C code assumes that

glass heart
#

and for the longest time it assumed wrong

noble sphinx
#

UB is always luck based

glass heart
#

yep

glass heart
#

my trap handler sucks

#

theres so many instructions that run for each interrupt

#

and the conditional jump over swapgs

#

i could save a conditional jump by duplicating most of the function into a version that does, or doesn't, swapgs at the end

noble sphinx
#

that looks farily normal

glass heart
#

i think swapgs might be a serializing operation anyway?

wild widget
# glass heart i honestly dont know how long it would've taken to figure this out

the way i figured it out:

  • what could generate this kind of garbage? maybe it's [several guesses, one of which was overlapping stacks]
  • looking at interrupt logs -> yep, overlapping stacks
  • why do two cpus have the same stacks?
  • looking at tss -> both cpus have the same rsp0. where does rsp0 get updated? i should add logs there.
  • one cpu switches to a thread while another cpu hasn't switched away from it yet. how?
  • educated guess: migration's misbehaving. add logs.
  • it definitely has something to do with migration, since the crash always happens right after, but the migration itself works fine. what now?
  • add logs to every place that adds a thread to a cpu's runqueue -> it's being added by a wakeup. what could cause a wakeup to work while the thread is still running?
  • look at the code that sets the state to waiting -> this unlock/yield feels incorrect
glass heart
wild widget
#

i was bored and curious what the issue could be

glass heart
#

oh i see

#

i guess "i was bored" explains a lot of what i do

#

and what you do too

scenic bronze
noble sphinx
#

of course

glass heart
#

what did you think of the code quality btw

noble sphinx
wild widget
#

overall pretty good. trap handler is the only thing i really considered messy

#

not a fan of the tabs on empty lines though but that's more of a style thing

glass heart
#

and also can you pitch in on whether i should disable 16 byte stack alignment in the kernel

scenic bronze
wild widget
#

no real reason not to

#

the only reason 16 byte stack alignment exists in the first place is simd stuff

noble sphinx
wild widget
#

you're not using that in the kernel so you only need word alignment

glass heart
#

since i don't do any simd stuff in the kernel, i didn't run into such issues

#

but it's still UB

noble sphinx
#

i said it causes UB if you DONT specify an aligment of 8 and dont explicitly make sure your ISR realigns it to 16

scenic bronze
#

ahh

wild widget
#

oh also just to clarify that doesn't mean your ISR needs to manually align the stack: on x86_64 the cpu aligns the stack to a 16 byte boundary before pushing the interrupt frame

#

so you just have to make sure that you push an odd number of words before calling anything

glass heart
wild widget
#

makes sense

glass heart
#

i didn't know that

#

i knew it could be word aligned since 99.999999% of the time rsp is 8 byte aligned

#

(except if you manage to bypass some critical security)

scenic bronze
#

so you dont have to change anything pretty much?

noble sphinx
#

yeah just push enough stuff and you should be fine, but still no real reason to go through that

glass heart
#

i see

glass heart
#

so i should just revert my previous commit and just add a push qword 0 if it turns out to not be the correct amount of bytes

#

my question is, is the rsp 16 byte aligned after the iretq frame is pushed or before

wild widget
#

before

glass heart
#

because the iretq frame is 5 qwords

#

but sometimes the exception frame is 6

#

e.g. page faults, gpfs etc

#

but eh it shouldnt matter really

wild widget
#

it's stack &= ~15 push(ss) push(rsp) push(rflags) push(cs) push(rip) if (has error code) push(error code)

glass heart
#

my kregisters struct looks the same regardless of whether or not the source pushes that extra qword for the error code or not

wild widget
#

also worth noting that this alignment does not happen in 32-bit mode

glass heart
#

i think in 32-bit mode ESP can even not be aligned to 4 bytes?

#

since you can push shorts and bytes

wild widget
#

yeah it can but compilers avoid that for obvious reasons

glass heart
#

i see

wild widget
#

avoiding the branches for swapgs isn't really worth it generally

#

also that's untested just fyi

glass heart
glass heart
#

this still happens but i'll look into it later when i have time

wild widget
#

oh yeah i had that happen once during testing too but i assumed it was just another expression of the same bug

glass heart
glass heart
glass heart
#

no write support though

wet marsh
#

wow

#

thats cool

glass heart
glass heart
#

Thinking of reforming the way PTEs are created

#

The MM won't be using pure bitflags to create ptes, but builtin arch specific functions which convert boron-unique PTE flags and properties into hardware specific PTEs

glass heart
#

the refactor is going worse than I hoped it would

#

im reaching usermode code but for some reason something in the heap gets reset to 0 for no reason

glass heart
#

ofc i could just abort ship but i really want this refactor going since it will allow me to properly support architectures where e.g. execution on pages is enabled by SETTING a bit rather than leaving it cleared like on x86

#

so the refactor would just use platform agnostic defines like MM_PAGE_READ = 1<<0 and it'd be converted to a platform specific PTE

#

im so close. i booted the OS but it crashes all the way in init, and specifically OSCreateProcess, and specifically OSFreeHeap

near panther
#

so 0xC0000000 to 0xCFFFFFFF are not executable

#

same with user mode access, you disable user mode access for a whole segment

glass heart
#

and can i configure it so 0x40000000-0x7FFFFFFF is NX and 0x80000000-0xBFFFFFFF is NX?

near panther
#

its like

glass heart
#

or maybe i can just set everything to exec x86 style

near panther
#

0x0FFFFFFF long ig

glass heart
#

Ah so there are 16 segments

near panther
#

yehs

near panther
glass heart
#

Yeah obviously

#

the refactor is done

glass heart
#

so writes to that region of memory were actually writing directly to the page cache of libboron.so

#

instead of being CoW'd upon write

glass heart
#

bunch of other fixes later and it works!

glass heart
#

i found a coincidence

#

boron had a typing thing where the prompt was Type something in:

#

once upon a time nanoshell also had one that said Type something! >

glass heart
glass heart
#

iPhone port progress update: managed to compile OpeniBoot for iPod touch 1G and boot it successfully

#

I could just make OpeniBoot run Boron directly or I could make OpeniBoot run charming which runs boron

#

For what it's worth charming was designed with another class of arm device in mind

#

Now I just need to figure out how to send OpeniBoot other files

limpid cloud
#

nicee

glass heart
limpid cloud
#

then what is that window-like object?

glass heart
#

I'll work on a window manager later

limpid cloud
glass heart
#

i have a Plan

#

the plan is:

  • make openiboot load elfs (done)
  • turn off interrupts before entering the elf (done)
  • make openiboot boot on the ipod touch 1g emulator (done)
  • make openiboot somehow see boron and boot it without interaction (or maybe through power/home) (solved through adding a uart console)
  • make openiboot provide LOADER_PARAMETER_BLOCK compliant structures (done)
  • create the HAL for the ipod touch 1g (built into the kernel for now) (currently just stubs)
  • somehow add module support as well to openiboot (i have a plan for this)
  • get the kernel to actually boot! (kernel does boot)
  • and then finish the arm port i guess
limpid cloud
#

wdym get the kernel to actually boot?

#

you had it boot like 99% of thr time

glass heart
#

i was booting it in QEMU, virtualbox, vmware and on PC hardware before

#

this is specifically a plan to port boron to old iOS devices

limpid cloud
#

ohh

glass heart
#

successfully merged master into arm-port-new, now i can continue with the port

glass heart
#

making progress with the ARM port

#

finally booting into boron proper, but not properly (yet)

bronze egret
glass heart
#

okay, boron shows the init message in the uart console

#

making progress

glass heart
#

i guess i'll continue working on this tomorrow

#

gn

near panther
#

also this font is pretty cool

glass heart
near panther
#

oh no

glass heart
glass heart
near panther
#

pretty cool

glass heart
#

not originally made by me, but I'm making an "enhanced" fork for easier debugging

near panther
#

fair enough

glass heart
#

I'm also using a custom build of OpeniBoot to boot boron, since I don't know how else I could do it

near panther
#

fair enough

#

2008 flobsh

glass heart
#

well, in this case 2007 actually

near panther
#

fair enough

#

i remembered this phone i have

#

htc hd2

#

its like a windows mobile 6.5 phone and people ran like android 7 on this idiot

near panther
#

finish arm port (EVIL)

#

you need a framebuffer trl

glass heart
#

yeah the arm port isnt exactly finished

#

no user mode for example

#

it will happen

glass heart
#

i'll pass openiboot a tar file

#

through sendfile

#

and it will contain the kernel, drivers, and initrd tar

#

yes, tar in a tar

#

but it's not inefficient like zip in a zip

#

and they'll all be provided as modules

near panther
#

fair

glass heart
#

maybe nand file system access can happen too although i have my doubts

noble sphinx
#

ipod support is crazy

near panther
#

makes me wonder why no one knows about the existence of this server

#

we have the most random crap in here

vestal river
glass heart
#

and well

#

the hardware is closely related so that's not that much further away

near panther
glass heart
#

and frankly theres a whole ass emulator for the ipod touch 1g (and 2g) so ... why not start with that

noble sphinx
#

why are you interested in that hw specifically?

near panther
#

party trick??

#

hobby os on iphone trl

glass heart
#

like

#

412 mhz and 128 mb of ram bad

#

basically a cheap alternative to porting to a 1990s workstation

#

as in, those are the specs that a workstation would've had back in 1997

glass heart
#

Maybe the really expensive ones

noble sphinx
#

ah

glass heart
#

For the record, I have a (functioning but barely usable) laptop from 1997-1999

#

that has a Pentium 1

#

and 16 MB of memory

glass heart
# noble sphinx ah

also it's really fun to explore places that apple doesn't want you to go

#

and ALSO

#

one more thing

#

the ipod touch 1g has a piezo speaker you cant really interact with via apis in ios

#

so... if I get control of kernel mode I can mess around with it

#

eventually it will lead to bad apple on ipod touch's piezo speaker

noble sphinx
#

why does it even exist

glass heart
#

the original ipod touch did not have a builtin speaker

#

just a headphone jack

#

just like its predecessor ipods

near panther
glass heart
#

technically i can already play the video

#

and audio by connecting an external speaker

near panther
#

its funnier in a hobby os

glass heart
#

but thats no fun

#

its funnier on the piezo because the ipod touch's piezo wasnt meant to play music

#

just to make little bleeps and bloops when you unlock your device

noble sphinx
#

so its like a pc speaker

near panther
#

do a beep on unlock

glass heart
#

it's even controlled by a timer implemented by the same hardware as the timer used for scheduling

#

just like on x86

#

(talking about the PIT here)

glass heart
#

but yes

#

thats pretty much it

#

it's kinda like the contemporary ipod nanos which also had a piezo speaker

near panther
#

or whatever else is in the audio out jack

glass heart
#

that's right

#

there's hardly any iPods other than the touches with an internal speaker

#

touch 2G and up have internal speakers

#

they aren't great but better than nothing

near panther
#

they turned my crappy smartphone into a slightly less crappy smartphone

glass heart
#

one more remark

#

that specific model of ipod touch is so silly!

#

and probably my favorite model

#

and it's like ultra thin

#

and not a total asspain to repair like, ahem, the 4th gen

glass heart
#

the font is a lil too big though

#

bit better

#

first ever real hardware test time!

crude arrow
#

On mobile displays it will be microscopic.

glass heart
#

thats always fun

glass heart
#

lol looks like the serial controller is failing to init

#

or uh?

#

okay ill disable caching maybe that has to do with it

#

BLUE SCREEN

#

BLUE SCREEN

#

sadly dont seem to show much more

#

okay i tracked down the failure to PsInitSystemProcess?

#

oh i bet its that line where i write to TTBR0 again

#

LogMsg also doesnt seem to work

#

HalDisplayString also doesnt work

#

maybe my spinlocks are bored

#

but im gonna go sleep

#

gn

#

i think like 4 things are broken at once: spinlocks, IRQs in the first place, caching, and page table switching

#

but they all seem to work in the emulator..

#

i wish qemu had more accurate cache simulation

glass heart
glass heart
#

oh dont tell me its failing because the spinlock was a bool instead of a uint32

#

and i was trying to do an atomic CAS on a bool

#

which maybe doesnt work on arm

#

switching to a uint32 didnt work either uhh

scenic bronze
glass heart
#

It doesn't work on uncached memory which is what I was using previously

#

But I fixed it so now memory is cacheable

#

It was a lot of pain and suffering trying to debug real hardware because qemu is useless for cache debugging but it works now

scenic bronze
#

Very cool!

glass heart
#

this is such a pain

#

the pl192 implementation in qemu is crashing now

#

like ๐Ÿ˜ก

bronze egret
#

dang ๐Ÿ˜ญ

uncut cosmos
#

QEMU machine emulators and tools has stopped working

#

what a name

glass heart
#

adding padding before the irq and fiq fields makes it look like this:```
qemu: hardware error: pl192: internal error (trying to mask when there are no more sources)

CPU #0:
R00=0000000a R01=0000000e R02=d1800020 R03=8006ff00
R04=d2012340 R05=00000000 R06=00000001 R07=00000000
R08=00000001 R09=00000000 R10=00037990 R11=c015f8f4
R12=d2012380 R13=c015f8b8 R14=c0118f4c R15=d200e750
PSR=600001d3 -ZC- A svc32```

#
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000```
#
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
#
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000
#

dont try to post the whole content together, apparently automod blocks me

near panther
#

five hundred registers

glass heart
#

crash!

glass heart
#

i wonder how i can get the skills of monkuous at debugging this shit

glass heart
#

i need to rearchitect the register saving

#

arm exceptions are something else smh

glass heart
#

this write might be making it fail?!

#

but why

#

its just an offset into a mapped region

#
HalTimerBase: 8007f000
HalOnInterruptRequest(7)
HalTimerHandler!  Stat = ffffffff  TIMER_IRQLATCH = 8007f0f8
calling KeTimerTick
writing TimerIRQLatch
writing TimerIRQLatch 8007f0f8
written TimerIRQLatch
Registers(c01608c4)->Lr = c013b984
handling fault ip=c0118f8c, faultaddr=01000001, faultmode=00000005

*** STOP (CPU 0):  invalid page fault thread=00000000, ip=c0118f8c, faultaddr=01000001, faultmode=00000005, status=0

TODO: DbgPrintStackTrace
#

looks like the emulator may be raising the timer interrupt before i set it up??

#

okay well i broke real hardware again

#

yay!

#

ill wanna take each commit from db05e00f9ee4890e9dcc87bc42b5e579b9bfd576 on and see if they broke something

balmy fern
#

@glass heart do you still have the code for the fireworks stress test?

wet marsh
#

wow tahts really fucking impressive

#

making a damn os for ipods

glass heart
#

So turns out I forgot to disable serial on real hardware and that's why it didn't work

#

I needn't forget

#

Strangely, on real hardware I get flooded with IRQs and nothing else gets done, and on the emulator the thing ends up crashing due to some kinda race condition or something?

glass heart
#

well

#

i got the timers working on both

glass heart
#

okay ... yeah some issue is going on with scheduling

glass heart
#

๐Ÿ˜ญ

#

it keeps jumping to random places

#

oh its failing in KiSwitchThreadStack

glass heart
#

what the fuck

#

its returning to 0x0 in fking KiSetPendingQuantumEnd

glass heart
#

im currently trying the CPU trace

#

-d int,exec,in_asm -D somefile.txt

#

it doesnt tell me too much unfortunately such as why the fuck it's seemingly returning to a bullshit location

#

its also like ass slow

#

but it's a lot more than i would normally have

#

example of a crash

#

you can see it here

#

c011e488 corresponds to here... so it's returning from here

#

... to 0x011606B8

#

idk where that is

#

i wonder if just moving sp by 8 bytes will do the trick

#

probaably not

#

something like this

#

it might crash in exactly the same way or in a slightly different way

#

oh ts time it's returning to weird location town

#

eventually it hits a brick wall

#

oh and now this shit!

#

ummmmmmmm

#

what

glass heart
#

its so sad

#

what the fuck could be wrong

#

how hard could it be to just work

glass heart
#

oh my fucking god

#

well there's a flaw and a half

#

which will bite me in the ahh when user mode comes into the picture

#

its related to how i tried to achieve the self-referencing page map โ„ข

#

looks like i might need to use TTBR1 after all

#

oh my fucking god

#

so this DOES support page table walking via cached regions

glass heart
#

a similar flaw does happen on amd64 and x86 and i work around it by preallocating all the necessary top level page tables and never touching that part of memory again (or so I hope!)

#

did i remember to do that with arm? we'll see

#

looks like i do

#

wait what?

#

thats like

#

not correct wtf

#

no wonder shit was getting corrupted.......?

#

like what the fuck was i doing when i wrote this

#

still corrupts but that was a problem

#

one that needed fixing

glass heart
#

The TLB dumper I wrote, that QEMU for arm doesn't have for some reason

glass heart
#

okay

#

looks like i fixed the memory issue

#

turns out i was mapping pool headers in a completely fucked up way

#

one that im not even sure how it worked for a little bit

#

but always when it comes to these fucking bugs

glass heart
#

fixed a couple more issues due to my sloppy code but scheduler still crashes sometimes ๐Ÿ˜”

limpid cloud
#

the more fixed the better

glass heart
#

how in the fuck did it end up in KeRestoreInterrupts

#

even though you're in KeGetCurrentPRCB

#

ig it goes through KeRaiseIPLIfNeeded

#

Like what the fuck am I doing wrong bro ๐Ÿ˜ญ๐Ÿ˜ญ

#

Am I twiddling registers what the fuck?

#

hey @wild widget, how do I invoke your debugging power and prowess

#

i really need this scheduler bug on arm fixed but i honestly don't know what I'm doing wrong

#

and I kinda feel bad asking you anything because setting the dev environment up for this port is really complicated

#

although hmm i wonder if a thread is scheduled in before it's scheduled out

#

FWIW this is singlecore

glass heart
#

thinking of rewriting the irq handler

#

or at least i think i might have an idea of what might be causing the issue

#

although it seems like a worst case scenario

#

what if something is using the same addresses in the irq stack twice

#

theoretically that shouldn't happen though since i save the exact value of sp_irq during my save interrupt stacks function

glass heart
#

this is weird

#

why is SP_svc > SP_rq

#

although i may be printing the wrong things

#

this is my modified qemu target/arm/helper.c printout

#

it used to just say the new PC and thats it

#

maybe i should just use env->regs[13] instead of trying to fetch banked r13 with current mode

#

maybe that doesnt work

#

what the fuck

#

no wonder shit was broken

#

although

#

that didnt actually happen with the original kernel stack size parameters

#

spot the bug

vestal river
glass heart
#

yep

#

well thats one bug fixed

glass heart
#

left: dbg logs
right: -d int logs

#

seems like nothing's going wrong ...???

glass heart
#

i guess my management of interrupt stacks is fine and doesnt seem to have flaws?

#

seems totally fine

#

ummmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

#

thats not supposed to behave this way

#

its not supposed to go through KiThreadEntryPoint if it went through the exit of KiSwitchToNextThread

#

yeah!?

glass heart
#

so many symptoms yet no clear cause

#

yeah so, during a print, the PC got swapped to something else

#

wtf ๐Ÿ˜ญ๐Ÿ˜ญ

glass heart
#

okay so i have come to the conclusion that involuntary scheduling between threads is just broken

#

always

#

the only reason why it seemed okay was because the firework test was constantly waiting on timers

#

okay scheduling somehow still doesnt work on real hardware, jumps to 0

#

but whatever

#

itll be fixed someday

glass heart
#

I mean I'll fix it but ykwim

glass heart
#

like actually im going insane what the fuck could be wrong

#

oh my god

#

i did a sort of fix and it lasted nearly 30 seconds now

#

oh lol

#

mf ran out of memory ๐Ÿ’€

#

i think i fixed it

#

the scheduler bug i mean

#

holy fuck

#

wish me luck on the real hardware test

#

so closeeeeee

noble sphinx
#

halipod

#

sounds like a helicopter KEKW

#

but nice to see ur making progress

glass heart
#

YEEEEEESSSSSSSSSSSSSSSSSSSSSSSSS

#

ITS WORKINNGGGG

noble sphinx
#

show it

glass heart
#

i hope this video doesnt somehow dox me

noble sphinx
#

crazy

#

i wouldnt touch old arm shit with a huge pole so props for that

glass heart
#

this is actually huge

noble sphinx
#

where did u find documentation for it btw

glass heart
#

for me at least

glass heart
#

the timers are documented in openiboot as well as the

noble sphinx
#

what about the video dev?

glass heart
#

this (and the general form factor of the touch 1) is why i started with this device

glass heart
#

in fact thats how i loaded boron in the first place ๐Ÿ˜„

noble sphinx
#

oh

glass heart
#

the setup is kinda weird

#

i first have to boot the ipod in recovery mode

#

then loadibec ipt_1g_openiboot.img3 (my modified openiboot)

#

and then sudo oibc, then !image.arm.tar which sends a tar package of the kernel, drivers, and initrd

#

and then finally borongo

noble sphinx
#

is it single cpu?

glass heart
#

yeah

#

single core

#

iphones/ipod touches havent been multi core until i think the A5

#

or A6

#

which is the iPhone 4S/iPod touch 5/iPad 2

noble sphinx
#

have been u mean?

glass heart
#

havent been multicore*

noble sphinx
#

that probably really simplifies everything

#

as in like barriers etc

glass heart
#

sort of

#

well actually it should

#

because today i learned that page table walking doesnt use cache by default

#

right now I've been passing just 0 for bits 13...0

#

meaning it does the page table walk uncached

noble sphinx
#

thats probably a really bad idea lol

glass heart
#

indeed

#

that's also why i had to spam flushes

#

i thought it was just Like That

#

but nope!

#

you can opt into page table walks using the cache

#

i'll do that later

noble sphinx
#

yeah not only that but your tlb misses are incredibly expensive also

glass heart
#

oh

#

out of curiosity i tried also booting it on the iphone 3G and it worked right out of the box

#

so i might want to rename it from halipod1,1 to hals5l8900

#

i don't have an iphone 2G to test so i can't confirm with that one

noble sphinx
#

what is that combination of numbers?

glass heart
#

The CPU's model number

#

S5L8900 is a Samsung SoC that powers the iPhone 2G, iPhone 3G, and iPod touch 1

noble sphinx
#

wouldnt the hal be more about the board/chipset

glass heart
#

412 MHz, 128MB of RAM

noble sphinx
#

oh ok its a soc

glass heart
glass heart
#

boron-c++ be like: "ke::Mutex::Release"

#

or ke::IPL::Raise

scenic bronze
glass heart
#

no

glass heart
#

for the memes

scenic bronze
#

Well that doesn't look that bad

#

Tho I wouldn't put IPL in its own namespace/class

glass heart
#

little did i know but one of my future endeavours was already predicted by my old discord tag

#

(8900 is short for S5L8900 which is the SoC powering the first two iPhones and the first iPod touch)

mossy thicket
#

i also am a victim of discord tag determinism

#

(i860)

glass heart
mossy thicket
#

that was my natural tag

#

natural born tag

glass heart
#

subscriber since 1/10/2024

#

ah

#

nvm then thats funny

crude arrow
#

Mine is just 9472, but it's 2500h in hexadecimal, so must be something cool too. Is the ipod touch 1g storage a bare NAND flash? Are you going to support it? Would be interesting to know how.

glass heart
#

OpeniBoot appears to operate it as a bare NAND flash, but iOS appears to operate it through an FMC of sorts

#

Which is heavily undocumented

glass heart
#

running user mode code on arm

glass heart
#

more code is being run

glass heart
#

even more

near panther
#

cinema

crude arrow
# glass heart even more

MiIThinkImACandidateForTheLongestAssNameFunctionEvenAmongTheNtTraditionWhatElseAhRightFreeUnusedPageLevelMapSomethingWellYouGotIt() ๐Ÿ˜

What are your plan regarding this port? What is the point when you'll say "ok, that's probably it, what else I can do on it?" because apart from it being this hard to get information for, it's quite outstanding by its form factor/niche, it's not even tablet. It would need its own GUI. Touch screen oriented. Are you going to write such a graphical shell for it? Is it possible to program the touch screen? Or sound subsystem. Overall, what programs is reasonable to port or write for it? And also, the most interesting thing: when you are going to jump into the less esoteric arm64 bandwagon? genuinely interested to see borongo running on some Potato Pi 6 Extra Pro. Or on a more or less modern arm64 phone or tablet.

noble sphinx
#

Potato Pi 6 Extra Pro is accurate

#

requires only 10M loc of driver code to run properly

#

and has a gigabyte long device tree

crude arrow
#

To a degree. Basically those SBC makers are hw enthusiasts like people here are osdev ones. They make mistakes, take weird design decisions, their hw often turns to be pretty clumsy and quirky. Also they can't afford getting big boys SoCs and take niche ones, from smaller players. Those in turn can't afford licensing better IPs and take some semifunctional ๐Ÿ’ฉ from crapware(TM) or designnightmare(TM) what results in heisenberg PCIe controllers not supporting any PCIe version or USB3 that isn't usb3-ing. But, still, it's getting better. Plus on such a device there's still so much more things that work, are documented and thus so much more of a pleasure to play with and finally to get a device to some working, functional level. Especially in comparison with the oddballs from 2007 like this ipod touch. Finally even super standardized PC machines unfortunately come with disappointing deviations requiring annoying extra efforts to make it work.

glass heart
#

User processes are finally running and exiting properly. I'm probably gonna need to do some stuff before getting it to work on real hardware (cleaning the dcache after RelocateSelf which I'll do with a syscall) but yeah

#

hey, what do you know, the framebuffer driver just works

wooden shuttle
glass heart
#

yeah

#

that's the emulator I'm using

#

okay, i found an instability

#

and a pretty weird one at that

#

sometimes it works and sometimes not