gorgonical has quit [Read error: Connection reset by peer]
gorgonical has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
Izem has joined #osdev
Izem has quit [Remote host closed the connection]
skipwich has joined #osdev
YuutaW has quit [Read error: Connection reset by peer]
pretty_dumm_guy has quit [Quit: WeeChat 3.2]
dude12312414 has joined #osdev
gog has quit [Quit: bye]
sts-q has quit [Ping timeout: 245 seconds]
flx-- has joined #osdev
flx- has quit [Ping timeout: 258 seconds]
sts-q has joined #osdev
nyah has quit [Ping timeout: 258 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
autopsy has joined #osdev
riposte has quit [Ping timeout: 258 seconds]
<autopsy>
Hey ok, I need to know what to do in order to write something in C to basically, allocate a block of memory, write a known value to it, read that memory address back and compare the two buffers, then iterate to the next segment of memory, and do it again..... verifying the contents are unchanged from the original data, in orrder to test memory. Can anybody help?
autopsy has quit [Quit: Leaving]
<zid>
apparently not
<moon-child>
some version of memtest was oss, no?
<kazinsal>
memtest86+ iirc
<kazinsal>
only problem is it's super out of date and doesn't neceessarily work perfectly on platforms newer than about Haswell
<kazinsal>
the changelog since the last version that has any "added support for" is completely devoid of any actual information
autopsy has joined #osdev
riposte has joined #osdev
riposte has quit [Client Quit]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
riposte has joined #osdev
riposte has quit [*.net *.split]
flx-- has quit [*.net *.split]
dutch has quit [*.net *.split]
sts-q has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
thinkpol has quit [*.net *.split]
robert_ has quit [*.net *.split]
sprock has quit [*.net *.split]
riposte has joined #osdev
Terlisimo has joined #osdev
Affliction has joined #osdev
xenos1984 has joined #osdev
clever has joined #osdev
flx-- has joined #osdev
sts-q has joined #osdev
robert_ has joined #osdev
dutch has joined #osdev
thinkpol has joined #osdev
sprock has joined #osdev
Raito_Bezarius has joined #osdev
mcfrdy has joined #osdev
vin has joined #osdev
jjuran has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined #osdev
HeTo_ has joined #osdev
mhi has quit [*.net *.split]
lava has joined #osdev
valerius_ is now known as valerius
NieDzejkob has joined #osdev
kazinsal_ has joined #osdev
kazinsal_ is now known as kazinsal
mniip has joined #osdev
phr3ak has joined #osdev
FireFly has joined #osdev
thaumavorio has joined #osdev
hl has joined #osdev
fkrauthan has joined #osdev
andrewrk has joined #osdev
ckie has joined #osdev
shan has joined #osdev
air has joined #osdev
kanzure_ has joined #osdev
andreas3- has joined #osdev
dennisschagt has joined #osdev
eltonpinto has joined #osdev
meisaka has joined #osdev
drewlander has joined #osdev
jeaye has joined #osdev
klys has joined #osdev
srjek has quit [Ping timeout: 245 seconds]
paulusASol has joined #osdev
freakazoid12345 has quit [Read error: Connection reset by peer]
hgoel[m] has joined #osdev
koon has joined #osdev
happy-dude has joined #osdev
flx-- is now known as flx
flx has quit [Ping timeout: 272 seconds]
flx has joined #osdev
mctpyt has quit [Ping timeout: 250 seconds]
YuutaW has joined #osdev
YuutaW has quit [Ping timeout: 256 seconds]
autopsy has quit [Quit: Leaving]
sortie has joined #osdev
ElectronApps has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
mhall has joined #osdev
ElectronApps has joined #osdev
autopsy has joined #osdev
ElectronApps has quit [Ping timeout: 276 seconds]
FireFly has quit [Quit: WeeChat 2.0.1]
FireFly has joined #osdev
zoey has joined #osdev
zoey has quit [Client Quit]
isaacwoods has joined #osdev
theruran has quit [Quit: Connection closed for inactivity]
GeDaMo has joined #osdev
Burgundy has joined #osdev
ElectronApps has joined #osdev
dormito has quit [Ping timeout: 258 seconds]
Brnocrist has quit [Ping timeout: 240 seconds]
Brnocrist has joined #osdev
anon16_ has quit [Read error: Connection reset by peer]
mctpyt has joined #osdev
mctpyt has quit [Ping timeout: 272 seconds]
anon16_ has joined #osdev
dormito has joined #osdev
Mikaku has joined #osdev
wolfshappen has joined #osdev
dennis95 has joined #osdev
wolfshappen has quit [Quit: later]
wolfshappen has joined #osdev
pretty_dumm_guy has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
gog has joined #osdev
nyah has joined #osdev
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
valerius has quit [Killed (NickServ (GHOST command used by theophilus!~corvus@user/theophilus))]
valerius_ has joined #osdev
dutch has quit [Quit: WeeChat 3.2]
dutch has joined #osdev
ahalaney has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
mctpyt has joined #osdev
robert_ has quit [Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.]
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has quit [Remote host closed the connection]
<Bitweasil>
autopsy, memcmp?
<Bitweasil>
With some memset first?
k0valski has joined #osdev
archenoth has joined #osdev
nvmd has joined #osdev
YuutaW has joined #osdev
Arthuria has joined #osdev
<autopsy>
Bitweasil, yeah but how to iterate through the whole range of addresses from 0x0000011 to 0xfffffff
<zid>
inc
<zid>
also a bunch of that memory is unwriteable
<kazinsal>
It's time for my favourite question to answer a question: What exactly is it you're trying to *do*?
<zid>
glhf
<Bitweasil>
^^ That, yes. If the goal is to test memory, use memtest.
<zid>
If the goal is to reimplement memtest, learn more about the x86 architecture and assembly
<zid>
we're not actually, a tutoring system
<autopsy>
Fuck that then you're not actually here to help either.
autopsy has left #osdev [Leaving]
<kazinsal>
Problem solved, I guess?
<gog>
:|
<zid>
perfect outcome imo
<zid>
rather than him begging for the next 8 hours and then saying that and leaving anyway
<Bitweasil>
Yup.
<Bitweasil>
*sigh*
<Bitweasil>
In the words of Peg and Cat, "Problem solved! Problem solved! We solved the problem, problem solved!"
<Bitweasil>
(kids show)
<Bitweasil>
(gratingly annoying, but popular enough)
kanzure_ is now known as kanzure
Arthuria has quit [Ping timeout: 268 seconds]
mahmutov has joined #osdev
<mjg>
geist: (or some other armista?) is there a way to convince gcc to *NOT* generate ltm and stm instructions?
<mjg>
there is a prog which has to work on cortex a53 which has numerous misaligned reads and stores
<mjg>
which fault on this cpu
<zid>
-march it?
<zid>
oh the program is incorrect to begin with though.. I guess that won't help
<mjg>
(:
<zid>
don't write incorrect code, that's my final offer :P
<mjg>
i did not
dennis95 has quit [Quit: Leaving]
<zid>
You can't generate unaligned writes in C without breaking rules
<mjg>
and it's not feasible to fix it
<mjg>
maybe there is a magic knob for the compiler to always assume data is misalgined
<GeDaMo>
Maybe -mno-unaligned-access
<zid>
wouldn't you want the opposite, tell it to never use aligned accesses
<zid>
convert everything to special unaligned moves, or byte moves and shifts and ors
<mjg>
GeDaMo: w00t
<mjg>
i don't know how i missed it
<mjg>
will try ito ut, thanks a lot!
<GeDaMo>
)
<GeDaMo>
:)
<zid>
If unaligned access is disabled, any unaligned data that is wider than 8 bits is accessed 1 byte at a time
<zid>
That's a toothbrush vs tooth brush problem with the name of that param, heh
<mjg>
i can tell you someone already tried to patch it up with -O0
<mjg>
that apparently had a side effect of working... until it stopped
<nshp>
I don't think mno-unaligned-access is going to solve that. That should only apply to cases where the compiler _knows_ the pointer is unaligned, not places where it thinks your pointer should be aligned
<mjg>
sure that very well may be true, will not hurt to try
<geist>
mjg: so the obvious question is why do you have unaligned traps on? is it becaus eyou didn't set the SCTLR bit, or because you're running with mmu/cache disabled?
<geist>
modern arm cpus can mostly deal with unaligned accesses, but require mmu/cache enabled
<nshp>
does that work with LDMs and STMs though? I thought that was only for single loads/stores
<bslsk05>
c9x.me: Winter: x86 Instruction Set Reference
<nur>
ah I see
<nur>
ok it works now :)
<nur>
thanks
Izem has joined #osdev
<mjg>
btw no dice with -mno-unaligned-access
<mjg>
got the same number of stm/ltm
<mjg>
"arm-assume-misaligned-load-store"
<mjg>
now that's interesting
<mjg>
hmmmm
<mjg>
ye
<mjg>
it whacked all ltm
<mjg>
this may be just enough
<geist>
note: cortex-a53 is armv8
<geist>
did you set the bit in SCTLR to enable unaligned access?
<geist>
also yes you may be correct, honestly i haven't dealt with armv7 cores in some number of years, but again, a53 is armv8
<geist>
also is there a strong reason you're using 32bit arm on a 64bit capable cpu?
<geist>
arm64 doesn't have most of these limitations, partially because it also doesn't support LDM/STM style instructions
<geist>
the switch i was going to recommend was -mno-strict-align, which does basically what you want
<geist>
but alas, its 64bit arm only
<geist>
but it does basically what everyone is assuming the -mno-unaligned-access does for arm32
<geist>
basically useful for when compiling C code that runs with cache disabled (and thus unaligned accesses not allowed)
<geist>
bootloaders, etc
<geist>
but indeed, does not help you if you get a truly unaligned access, what that flag does is keep the compiler from intentionally emitting unaligned load/stores, which it happily does (much like x86) in armv8-64 because the architecture states that unaligned accesses shall always be allowed
Izem has quit [Ping timeout: 248 seconds]
<zid>
and code that does do it violates the spec to begin with
Izem has joined #osdev
Izem has quit [Client Quit]
<Bitweasil>
The ARM spec is a hot mess.
<geist>
zid: what specifically do you mean there?
<Bitweasil>
Tons of "This is supported; deprecated; mandatory; deprecated" sort of stuff with regards to some of those hardware feature flags.
<Bitweasil>
Hardware page table accessed bits being one that's gone all over the place.
<geist>
i dont get it. there's a clear feature bit that says when it is and isn't supported
<geist>
it's fully documented, it's an optional feature, mandatory in newer versions of the spec. you can read a feature bit that says it's present or not
<geist>
complicated != hot mess
<Bitweasil>
The ARMv7 spec is a mess.
<Bitweasil>
I hear ARMv8 clears up a lot of the ambiguity and "uh... yeah, thar be 50 miles of legacy baggage" stuff.
<geist>
then get something designed in the last 10 years
<Bitweasil>
But v7 is sort of peak complexity. :(
<Bitweasil>
*shrug* I'm being paid to implement v7.
<geist>
then i humbly request being more specific when bitching about the arm spec
<Bitweasil>
it just has a /lot/ of corner cases.
<Bitweasil>
Ok.
<Bitweasil>
Hypervisor traps. ;)
<geist>
yes hypervisor stuff was a zygote in armv7
<Bitweasil>
I'm dealing with the interaction of that and the generic timers.
<geist>
i'm sorry of anyone that has to actually screw with armv7 hypervisor stuff
<geist>
which was basically dead on the vine. i dont think anything really seriously implemented it. except you
<geist>
they even removed support in linux, iirc
<Bitweasil>
Not even fully implementing, just stubbing in some of the permissions checks.
<Bitweasil>
Hrm, I thought Linux still supported v7 hypervisor stuff.
<Bitweasil>
You can tell it was really crammed in where they could fit it.
<geist>
what i *do* like, though it adds complexity, is the fact that ARM can deprecate something and replace it, instea dof just dragging old implementations along
<geist>
it just takes a while. 10 years or so horizon for stuff
<Bitweasil>
"This bit does this. Unless this other bit over here is set, then... uh... check this other bit in this unrelated register to see what you're supposed to do."
<geist>
right
<Bitweasil>
Yeah, v8 being a more or less clean cut sounds niec.
<Bitweasil>
I'll get there eventually.
<Bitweasil>
Probably after having moved my personal life to non-Apple ARM as much as possible. :/
<geist>
re: linux. i swear i had read something to the effect of KVM on <v8 is tossed. or at least arm32 KVM
<nshp>
er... isn't pretty much all of armv7 still present as a mode in armv8, just like x86->x86_64?
<Bitweasil>
nshp, userspace code, mostly. System code, no.
<nshp>
ahh
<Bitweasil>
AArch32 is /mostly/ ARMv7, I think, but not entirely.
<geist>
nshp: yes, but its incorrect to say there's a armv7 core in armv8. it's an armv8 core that has arm32 support
<nshp>
didn't know that, that's nice
<geist>
but that being said, system mode stuff in armv8-32 is largely identical to armv7
<Bitweasil>
Hm... the paging granule sizes and stuff are 64-bit only?
<nshp>
right, I at least appreciate that they don't still boot in 32bit mode (or 16bit real mode, like certain beasts)
<geist>
but stuff like whether or not it's UNDEFINED that an armv7 core implements unaligned on this or that, if you consult armv8 manual it may actually make a harder stance on the same thing
<geist>
since something like an a53 is an armv8 core, even when running -32
<Bitweasil>
Yeah, there is a /lot/ of "IMPLEMENTATION DEFINED" behavior in the v7 spec.
<geist>
yah some of that is because of cortex-a8 and -a9
<Bitweasil>
"You've run off the main highway. May God help you."
<Bitweasil>
Oh?
<geist>
in the armv7-a world i generally consider there to be three classes of cortex-a cores: cortex-a8 (first one), cortex-a9 (first SMP/OOO arm code), and all the rest
<geist>
-a8 and -a9 are somewhat wonkier and i think generate much of the UNDEFINED stuff that really ends up fairly defined in all the cores that came later
<geist>
for example. a9 has no L2 cache, relies on an external one (PL310 usually)
<geist>
a8 has no SMP capability at all
<geist>
also a9 has optional FPU, which lots of vendors took, which really really sucks
<geist>
whereas IIRC almos all the subsequent cortex-a v7 cores had mandatory FPU/NEON
<gorgonical>
Anyone here happen to have knowledge about the pine64-lts boot process? Or could help me troubleshoot u-boot? I'm stuck with a SPL boot loop. The u-boot SPL portion can't seem to find the main u-boot code, or so I think
<geist>
(where all the rest are off the top of my head: a5, a7, a12, a15)
<clever>
geist: when running arm32 code on an aarch64 core, i'm guessing the lower 32bits of the general regs persist, what happens to the upper 32bits on mode switching?
<geist>
clever: i forget if they're cleared or they retain data. i think the spec says 'dont rely on the top of the regs holding any interesting values across a mode switch'
srjek has joined #osdev
<geist>
i think a fair number of arm32 instructions will implicitly clear the top of the registers. which is irrelevant in arm32 since you cannot get to them
<geist>
and vice versa, you can safely switch to arm32 with crap in the top of the registers, i'm almost positive of
<clever>
geist: i dont know about the pine64 specifically, but my understanding is that the SPL has the search location(s) for the main uboot baked into it at compile time, and for simplicity, that tends to be at SPL addr + SPL size, so you can just concat the 2 blobs and put them at one location
<clever>
gorgonical: ^
* clever
kicks auto-complete
<gorgonical>
I see
<clever>
gorgonical: if you can read the SPL source, you may find an answer there
<gorgonical>
That's what makes sense. So the bl31 trusted firmware blob might be pushing incorrect values onto the stack
<gorgonical>
Or maybe u-boot isn't passing the right one down
<Bitweasil>
Yeah, some of the ATF build process stuff is a bit funky with how you concat blobs. And Pine64 isn't much better, IIRC on the Pinebook Pro stock setup, they just literally barf blobs into fixed offsets in a partition that's theoretically FAT32.
<clever>
Bitweasil: yeah, if ATF is involved, i think the SPL loads the trusted-firmware instead?
<clever>
and the TF then loads uboot
<gorgonical>
yeah, so what I think is supposed to happen based on the docs is that the uboot spl loads the bl31 blob, which does some config, and then that hands off to the untrusted, rest of the uboot blob
<Bitweasil>
That sounds correct for ATF.
<Bitweasil>
Sorry, been a while since I've messed with it, and haven't messed with it on Pine hardware.
<gorgonical>
But evidently the u-boot blob is not where it's supposed to be, or bl31 is mistaken about where uboot is supposed to be
<Bitweasil>
In RAM or on storage? Both tend to be a bit special.
<gorgonical>
I saw something like that with other docs, where there's a bl2 loader that puts images at various addresses
<gorgonical>
Seems like I would need that to happen if bl31 has its own ideas about where the next entry point is
GeDaMo has quit [Quit: Leaving.]
<gorgonical>
I'll try reading this source a little more carefully and printing some bytes at where it's about to go
<clever>
i must be on the wrong fork of uboot, because i cant find the first 2 lines anywhere in the src
<gorgonical>
I pulled from the gitlab.denx.de tree
<gorgonical>
Okay. Found that the bl31 *does* think u-boot is supposed to go at 160MB into RAM
<gorgonical>
So sounds like is maybe the SPL supposed to copy the rest of u-boot to this address?
<clever>
either SPL or ATF
<gorgonical>
So the tf-a bl31 blob might could do it if it knows where that blob is
<gorgonical>
I mean really it's either/or at this stage anyway
HeTo_ is now known as HeTo
dormito has quit [Ping timeout: 272 seconds]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dormito has joined #osdev
divine has quit [Quit: leaving]
Arthuria has joined #osdev
nvmd has quit [Quit: Later, nerds.]
divine has joined #osdev
ahalaney has quit [Remote host closed the connection]
Arthuria has quit [Ping timeout: 256 seconds]
elderk has joined #osdev
elderk is now known as elderK
sortie has quit [Quit: Leaving]
Burgundy has quit [Ping timeout: 248 seconds]
devcpu has joined #osdev
theruran has joined #osdev
<moon-child>
can somebody sanity check my multi producer ring buffer idea? I feel like it could work, but I'm missing some of the details
<moon-child>
you have some fixed number of 'writer slots', which is hopefully greater than the maximum number of producers. Let's say 8 or 32, or w/e
<moon-child>
and you have to spin to acquire a writer slot
<zid>
is it 8 ring buffers, or 1?
<moon-child>
1 ring buffer, 8 maximum producers
<moon-child>
Once you acquire a writer slot, you bump the write head, but not the read cap. Then you copy your data into the buffer
<zid>
doesn't bumping the head need them to take a lock/
<moon-child>
then you check if any producers in slots after (temporally after, not spatially after) yours finished writing befor eyou
<moon-child>
_contiguously_ after, I should say
<zid>
it sounds faster to just make 8 queues
<moon-child>
if so, you add the amount they wrote to your total count. If nobody started writing before you, you add the count to the read cap. Otherwise you leave it in the slot, and the writer who started before you will add it to his count once he's finished
<zid>
but maybe I am missnig something
<moon-child>
the main part I'm missing, I think, is how to do 'check who started after you but finished before you' in a sensible way. If your writes are big it would probably be fine to do that with a lock--since the main gain is you don't have to lock while you're actually writing
<moon-child>
zid: if you have 8 queues then you have to have some way to say 'wait until any of these queues gets written to', which isn't simpler
<zid>
I guess it depends if you 'care' about the readers or writers
<zid>
but it sounds like you're expecting a lot of writing though
<clever>
moon-child: i would just opt for one ring per writer/reader pair