<gorgonical>
Let me ask a potentially dumb question. I should be able to take the u-boot-sunxi-with-spl.bin image, dd it onto a completely blank sd card, and boot to a u-boot prompt, right?
<clever>
gorgonical: i would assume so
<clever>
it will either fail to find its env, or fail to find a config file, and then drop to a prompt
<gorgonical>
That's what I thought. I'm just trying to make sure there isn't some magic autoconfiguration that's happening where it fetches a file from one of the partitions on the sd card or something wild like that
nyah has quit [Ping timeout: 248 seconds]
nyah has joined #osdev
ElectronApps has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.2]
dragestil_ has quit [Ping timeout: 258 seconds]
dragestil_ has joined #osdev
jjuran has quit [Read error: Connection reset by peer]
srjek has quit [Read error: Connection reset by peer]
jjuran has joined #osdev
srjek has joined #osdev
dragestil_ has quit [Quit: No Ping reply in 180 seconds.]
dragestil_ has joined #osdev
Terlisimo1 has joined #osdev
sprokl has joined #osdev
MrBonkers has quit [Quit: Ping timeout (120 seconds)]
riposte has quit [Remote host closed the connection]
sts-q has quit [Ping timeout: 272 seconds]
Terlisimo has quit [Ping timeout: 272 seconds]
pretty_dumm_guy has quit [Ping timeout: 272 seconds]
sprock has quit [Ping timeout: 272 seconds]
xenos1984 has quit [Ping timeout: 272 seconds]
clever has quit [Ping timeout: 272 seconds]
riposte has joined #osdev
pretty_dumm_guy has joined #osdev
mctpyt has quit [Remote host closed the connection]
MrBonkers has joined #osdev
mctpyt has joined #osdev
xenos1984 has joined #osdev
YuutaW has quit [Ping timeout: 268 seconds]
YuutaW has joined #osdev
<gorgonical>
unbelievable
<gorgonical>
I flashed an armbian image onto the disk that worked, which made me wonder what the u-boot in that .img looked like. Turns out they are using a different u-boot configuration. So I built that one, and it works
<gorgonical>
So why does the defconfig included with u-boot itself for the board not work, but a more generic one does?
pretty_dumm_guy has quit [Quit: WeeChat 3.2]
<moon-child>
hmm, I'm looking at the lfds ring buffer, but it seems to be ... not actually a ring buffer, except in semantics
<moon-child>
it seems to be implemented in terms of a queue and a freelist of nodes
Izem has joined #osdev
<moon-child>
I think my multi producer ringbuffer can work, but you have to synchronize twice: once before you start writing and once after you're done
<moon-child>
coupled with false sharing necessitating high alignment, and copying large buffers being not preferrable to sharing them (in most cases) I guess y'all are probably right: having a separate buffer per connection is lower overhead
z_is_stimky has quit [Ping timeout: 256 seconds]
autopsy has joined #osdev
z_is_stimky has joined #osdev
gog has quit [Ping timeout: 272 seconds]
sts-q has joined #osdev
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 272 seconds]
Izem has quit [Quit: Connection closed]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
riposte has quit [Quit: Quitting]
vinleod is now known as vdamewood
dude12312414 has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
ElectronApps has quit [Remote host closed the connection]
<bslsk05>
eli.thegreenplace.net: Parsing expressions by precedence climbing - Eli Bendersky's website
YuutaW has joined #osdev
theruran has quit [Ping timeout: 258 seconds]
paulbarker has quit [Ping timeout: 240 seconds]
YuutaW has quit [Ping timeout: 248 seconds]
<sham1>
Seems somewhat similar to Pratt parsing
<sham1>
...which seems fitting since apparently they might be somewhat related
<zid>
I only got as far as having 2 or 3 levels of prec and I already noted what a pain it was going to be to get to C's 15 levels
<zid>
so this seems like it'd be pretty rad
<GeDaMo>
At the bottom it says: "Andy Chu notes that precedence climbing and TDOP are pretty much the same algorithm, formulated a bit differently. I tend to agree, and also note that Shunting Yard is again the same algorithm, except that the explicit recursion is replaced by a stack."
<zid>
this is basically the article I wanted to read last week, anyway :P
SanchayanMaity has quit [Ping timeout: 245 seconds]
<GeDaMo>
Are you writing your own C compiler?
<zid>
sure why not
<GeDaMo>
Yeah, why not? How hard could it be? :P
<sham1>
Are you writing a compiler for some other language that just happens to have same precedence levels as C
<sham1>
:P
<zid>
well it'll be C, but without the stuff I don't personally use ;)
<GeDaMo>
zidC! :P
<zid>
I will finally be able to dereference structs with incomplete final members
<sham1>
Are you going to change some of the syntax, because if so, may I introduce you to "Pascal-styled variable type declarations" which aren't such a headache as C's variable declarations which require silly things like the "lexer hack"
<zid>
lexer hack is why I hand-wrote instead of using bison
SanchayanMaity has joined #osdev
<sham1>
oh
<zid>
typedefs are kinda useful for u64 u32 u16 u8
jakesyl has quit [Ping timeout: 240 seconds]
<sham1>
Well yeah, but you can have typedefs even if you had variables like "var foo: int" or whatever
<zid>
typedefs is why you need le hax though
<zid>
because you don't know if anything is a type or identifier unless you parse the typedefs not just lex them
<sham1>
Not in this case, because you always know that what is after the colon is a type of some kind and you can parse it as one
<zid>
casts?
YuutaW has joined #osdev
<sham1>
(1 as float)
<sham1>
For example
<zid>
that's called rust :P
YuutaW has quit [Client Quit]
<sham1>
Yes
<zid>
could do, but I want it to basically be C
<sham1>
I see
<zid>
I like C, it just has a couple of stupid things that never got updated
<sham1>
Well, as much as I'm not a fan of C's syntax in some places, it's not enough of a turnoff for me either
<zid>
I might add proper enum types too
<zid>
and fix constants
<GeDaMo>
Proper arrays too?
<zid>
no
<GeDaMo>
Boo! :P
<zid>
C has arrays like it has them so you don't have to write every function twice
<zid>
between a pointer to thing and automatic array of thing
<sham1>
C has proper arrays though. What it doesn't have, is arrays that know their own lengths at runtime
<zid>
It's a 10 min job to create a full compile time encapsulated length tracked array
<sham1>
Yeah
<zid>
make it once in 1989, reuse it ever since
<zid>
it's not python it won't stop compiling next week :p
<sham1>
Just as it is easy to create a proper string type, which people seem to bemoan C for not having
<sham1>
struct string { size_t len; char data[]; /* could also be a pointer to char */ };
<sham1>
One more size_t and it can be made expand dynamically and efficiently
<sham1>
By doubling the capacity
<zid>
meh just make the add/concat operator method function thing do it
theruran has joined #osdev
<zid>
if it's always full, length and allocation size are the same thing
<sham1>
Well yeah, but if you can reuse the stroage, you should :P
paulbarker has joined #osdev
<zid>
Use your own allocator to modify its behavior depending on runtime needs
<sham1>
Dat amortized O(1) resize doe
<zid>
low memory use, fast, etc
<zid>
that size info is in the allocator anyway, so just use it
jakesyl has joined #osdev
clever has joined #osdev
childlikempress is now known as moon-child
dennis95 has quit [Quit: Leaving]
autopsy has joined #osdev
Arthuria has quit [Ping timeout: 258 seconds]
mctpyt has quit [Ping timeout: 268 seconds]
mctpyt has joined #osdev
flx has joined #osdev
paulbarker_ has joined #osdev
paulbarker has quit [Ping timeout: 248 seconds]
theruran has quit [Ping timeout: 248 seconds]
paulbarker_ is now known as paulbarker
jakesyl has quit [Ping timeout: 272 seconds]
theruran has joined #osdev
SanchayanMaity_ has joined #osdev
jakesyl has joined #osdev
SanchayanMaity has quit [Ping timeout: 248 seconds]
SanchayanMaity_ is now known as SanchayanMaity
mahmutov has quit [Read error: Connection reset by peer]
mahmutov has joined #osdev
nvmd has joined #osdev
dormito has quit [Ping timeout: 248 seconds]
dormito has joined #osdev
Izem has joined #osdev
isaacwoods has quit [Read error: Connection reset by peer]
isaacwoo1 has joined #osdev
wootehfoot has joined #osdev
GeDaMo has quit [Quit: Leaving.]
dormito has quit [Ping timeout: 268 seconds]
srjek has joined #osdev
sts-q has quit [Ping timeout: 248 seconds]
sts-q has joined #osdev
Izem has quit [Quit: Going offline, see ya! (www.adiirc.com)]
dormito has joined #osdev
devcpu has joined #osdev
pretty_dumm_guy has joined #osdev
Arthuria has joined #osdev
anon16 has quit [Ping timeout: 248 seconds]
anon16 has joined #osdev
devcpu has quit [Ping timeout: 258 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
devcpu has joined #osdev
ahalaney has quit [Quit: Leaving]
Burgundy has quit [Ping timeout: 268 seconds]
vin has quit [Ping timeout: 272 seconds]
vin has joined #osdev
sortie has quit [Quit: Leaving]
Arthuria has quit [Ping timeout: 272 seconds]
<klange>
I have a problem in my compositor. A design issue that's been there for a while. I need to fix it, but I thought I'd plop a description off the issue here for posterity.
<klange>
I animate windows when they appear and disappear, and while this looks neat and really demonstrates how it's a 'modern' composited UI, it's also hiding a flaw.
<klange>
When applications create windows, there's a race. You ask the server for a window, it sets up a texture - initially fully transparent - and then gives you a reference to that texture's memory in the shared memory subsystem.
<klange>
And as an app, you bind that shmem reference and you can draw and tell the compositor when you have updates. But window textures, in the system, are single-buffered. That's not the flaw in itself, though moving double buffering to the server side would be an improvement...
<klange>
The flaw is that when you ask the server for a window, it happily creates one at coordinates 0,0... and the animation starts immediately.
<klange>
The race comes from the fact that applications generally want windows to be in a particular place - menus, for example.
* geist
listens...
<klange>
And you have to ask for the window and then ask the server to move it... and then you start drawing.
<klange>
The combination of single-buffering, windows starting at 0,0, and then being "displayed" immediately can mean that you can end up drawing to the texture for a window and having it rendered on screen before the message to the server telling it to move the window has arrived.
<klange>
If the conditions are right, a window will flash on screen in the upper left before moving to its actual location.
<moon-child>
doesn't sound super difficult to resolve. Make 'initial location' part of the 'open window' request
<klange>
Yeah, there are a handful of different ways to fix this, but the one I'm going for is a reveal event.
<klange>
I'm not even going to add it as a new event, it's just going to be the first damage message.
pretty_dumm_guy has quit [Quit: WeeChat 3.2]
<gog>
i was gonna say, keep it hidden until the first draw
<klange>
That way a window won't be displayed at all until the app says it has content, and that always gets sent after a move request, and the server handles messages in-order, so the window will be created, moved to its correct location, _and_ filled with content before we get the first 'flip' request.
<zid>
windows does ShowHidden() and ~WM_VISIBLE
<zid>
to work around that
wgrant has joined #osdev
<gorgonic->
What in the world is happening? I have a kthread_create function that, for some unknown reason, is masking out the top 32 bits on arm64
<gorgonic->
As far as I can tell, every call in the stack is specified as a pointer type (struct task_struct *), but when we finally get the retval, it mysteriously has the upper 32 bits cleared
<geist>
whomp whomp!
<gorgonic->
but like, I don't understand why
<geist>
what mcmodel are you compiling with?
<geist>
are you running at a 'high' address?
<geist>
or negative address space?
<gorgonic->
small
<gorgonic->
And I can kmem_alloc stuff and that gets the right address
<geist>
are you running at high addresses?
<gorgonic->
And the addresses inside the callstack that are being return'd up are correct.
<geist>
are you running at high addresses?
<gorgonic->
The physical memory is pretty low
<geist>
are you running at high addresses?
<gorgonic->
I am not exactly sure how to answer this question
<gorgonic->
Excuse my ignorance
<geist>
ie, is the mmu on, are you running with the program counter up at say 0xffffffff80000000...
<gorgonic->
yes? let me double-check
<geist>
if so you really should probably be using mcmodel=kernel or not using small
<geist>
it's possible it's zero extending addresses in some cases