channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=11&d=4
12:38:25 <mmu_man> bookmarked! https://sourceforge.net/p/predef/wiki/Compilers/
12:51:37 <mmu_man> oops
12:51:51 <mmu_man> the Date prefs in R5 only knows as far as 2010 :-(
12:52:01 <mmu_man> at least the date cli tools knows more :D
02:19:40 <dormito> hmmm linux seems to push each i386 register (in 32bit x86 mode) onto the stack individuall (instead of using say pusha). anyone know why?
02:20:05 <bcos_> PUSHA is a slow micro-code thing
02:21:54 <bcos_> (best would be to "sub esp.." then do something else for a few instructions, then "mov [esp],..")
02:23:18 <bcos_> (like, "sub esp,32; ...; ...; mov [esp],eax; mov [esp+4],ebx; mov [esp+8],ecx; mov [esp+8],edx; ..." so that there's no dependencies waiting to calculate the address to store to)
02:25:04 <dormito> um afaik the only place where it's sane to pusha/popa is on interrupts/syscall entry/exit. there is no 'something else' that you can do before you preserve the state
02:27:27 <bcos_> 80x86 allows stuff like "mov dword [in_interrupt_flag],1"
02:28:01 <bcos_> (or "mov dword [ss:in_interrupt_flag],1" if you're not sure about DS yet)
02:29:54 <bcos_> Maybe even "cmp word [esp+8],KERNEL_CS; pushad; je .kernel_was_interrupted" if you want
02:37:24 <klys> test byte [esp+8],0x03; pushad; jz .ring0_was_interrupted
02:40:12 <geist> my guess is it's wash if pushd vs separate pushes is faster or not across all implementations
02:40:33 <geist> so probably in face of that someone made the call that doing it manually at least gives you more options
02:41:29 <geist> i've seen gcc do this, and i remember reading it in agner's microarchitecture guide, but i seem to remember there was a period there where it was faster to not put pushes/pops back to back, but to adjust the stack ptr and then use sp relative load/stores
02:41:50 <geist> and then in general modern cpus it's just as well to do it with push/pops
02:41:58 <geist> since they have a highly optimized stack engine
02:42:56 <geist> but all that aside a single pusha or a series of pushes (single byte opcodes i think) is smaller than anything else
02:45:17 <klys> geist, how many instructios does the gigatron have in its isa?
02:46:48 <geist> not a lot, i think like 8
02:47:40 <geist> https://gigatron.io/?page_id=482 is their data sheet and it has the isa on it
02:49:37 <geist> the gigatron machine is somewhat more like an Alto. it has a raw instruction set that also directly drives hardware, and most programs are written on top of a more rich 16bit ISA that is interpreted
02:49:59 <geist> so it runs at about 8Mhz and I think one instruction per cycle, so that's pretty fast actually
02:50:16 <geist> but it spends like 80% of it's time directly driving the vga port and synthesizing audio
02:50:28 <geist> and then in the gaps between that it interprets a 16bit instruction here or there
02:51:31 <geist> also it can do all of that in one cycle because the raw 8 bit isa is harvard, it's direclty fetching 16bit words from rom and can read/write to the separate ram simultaneously
02:52:38 <klys> looks like the ALU is composed of 10 ICs
02:52:42 <geist> yah
02:52:57 <geist> two 4 bit adders an 8 muxes
02:53:31 <klys> I wonder how many logic units that would add up to for vhdl
02:53:45 <chrisf> good lord it's a whole pile of 7400?
02:53:47 <geist> very few. probably tens of luts
02:54:00 <geist> the ALU is pretty clever, worth looking at
02:54:27 <geist> it's all to avoid 74181s which are a) big (24 pins) and b) unobtanium in mass anymore since no one makes em
02:54:56 <geist> but the canonical solution for ALUs is to use a 74181, which is precisely a 4 bit ALU with all of the standard operations
02:55:40 <geist> pretty much any TTL minicomputer in the 70s was using a 74181
02:55:47 <geist> DG nova, etc
02:55:56 <geist> well, multiple 181s actually
02:58:08 <geist> http://www.righto.com/2017/03/inside-vintage-74181-alu-chip-how-it.html is a whole writeup on it
03:04:13 <dormito> hey geist: any thoughts/suggestions about how to store cpu affinity (in a process)? My current inclincation is to use uint32_t[MAX_SUPPORTED_CPU_COUNT/32]
03:04:59 <geist> that's what i'm currently doing
03:05:34 <geist> make a series of accessors for that
03:05:38 <dormito> ok (so I'm not too bat-shit crazy)
03:05:43 <geist> linux has something like that, cpumask.h or something
03:05:56 <geist> it has some #ifdef logic to simplify it if max cpus is set to <=32
03:06:04 <chrisf> do you care about arbitrary masks, or just pick-a-policy-from-a-palette
03:07:03 <geist> arbitrary masks
03:07:31 <geist> but that's a higher level design decision
03:07:45 <geist> but i decided that masks is more useful and simple to test against
04:47:26 <klys> where should x86_64-elf-gcc get stdint.h from?
04:48:47 <Mutabah> the compiler
04:49:10 <klys> #include_next <stdint.h>
04:53:36 <klys> and then it needs a bunch of types, such as uint32_t
05:08:49 <Mutabah> klys: If you compiler was build/installed correctly, then it will provide a stdint.h that you can use with `-ffreestanding`
05:09:15 <klys> okay I linked in a few files from /usr/include and the __GLIBC_USE() macro. Building zircon. musl built. now I have: system/host/fidl/compiler/main.cpp:85:5: error: ‘va_start’ was not declared in this scope
05:09:52 <Mutabah> stdargs.h is also a freestanding header
05:10:42 <klys> I see stdarg.h should have been included then
07:31:00 <mrvn> varargs is also something compiler specific that you can not provide yourself
07:31:39 <Mutabah> ^
07:32:47 <klys> It seems I have zircon up and running, thanks to #fuchsia now
07:33:51 <klys> as it relies on c++17, there were a few blobs I had to download.
07:35:54 <geist> yeah i'm not happy with the blobs, but it is what it is
07:36:21 <geist> usual problem: need to either fix the version of the compiler (in our case to something very recent) and/or tweak the compiler for your ABI or whatnot
07:48:06 <geist> this is also fun: a nice #GPF with no real rationale
07:49:39 <geist> ah blew a stack. woot. got task switching via tss
08:15:17 <geist> so lets, see, about 12400 switches back and forth between two threads per second
08:15:29 <geist> on a 16mhz machine that's about 1300 cycles per round trip
08:17:47 <mrvn> geist: what system do you have that's only 16MHz?
08:17:55 <geist> a 386sx
08:18:16 <mrvn> hardware or software task switching? Task gates?
08:18:20 <geist> TSS
08:18:31 <geist> using a direct jmp to the task segment
08:18:57 <geist> it's in the right ballpark. the 386 manual says it should be in the 350 cycle range to do a TSS switch
08:19:24 <mrvn> you think a factor of 4 is in the ballpark?
08:19:42 <geist> well, it's a switch to and back, so we're already 700 or so cycles into 1300
08:19:55 <mrvn> plus twice an int 80?
08:20:06 <geist> no, these are two hardware threads
08:20:10 <geist> er kernel threads
08:20:19 <geist> just directly switching back and forth
08:20:36 <mrvn> Still. What are the other 600 cycles?
08:20:49 <geist> i dont know, whic is why i'm looking
08:21:05 <mrvn> the TSS are in memory right? You don't create them on the fly?
08:21:12 <geist> note that these old machines are much slower than you think. the average instruction is in the 3 or 4 or 5 cycle range
08:21:18 <geist> plus there's no cache
08:21:30 <mrvn> on the other hand memory is way faster
08:21:34 <geist> and it's a 16 bit wide memory bus (because it's a 386sx) so it's entirely likely it's just all the other code
08:21:54 <geist> not entirely. this is i think 80ns memory, but it's dram, and there is zero cache
08:22:40 <mrvn> and no page caching on the dram either.
08:22:44 <geist> so stuff starts adding up pretty fast. just fetching instructions takes roughly as many cycles per 2 bytes in the instruction itself
08:23:10 <geist> it's interesting to go back and think about how much slower these machines were. the mhz is just part of it, they are highly non superscalar
08:23:39 <mrvn> geist: My Amiga (68060) was way faster than PC at the same time.
08:23:54 <geist> an 060 is a completely different class, yes
08:24:07 <geist> an 040 is already going to blow the pants off a 386
08:24:22 <geist> this particular 386sx is low end, even for the time
08:24:24 <mrvn> 69060 @ 50Mhz does 67MB/s memory copy, a P90 only manages something like 38MB/s.
08:25:11 <geist> i'm also running 32bit code herre, which is generally speaking a penalty since we're on a sx
08:25:28 <geist> etc etc, so i suspect there's nothing particularly wrong here. it's in the same ballpark
08:25:57 <mrvn> Yeah, 386sx is like an 68000. two bus cycles per memory access
08:26:05 <geist> indeed
08:26:18 <mrvn> didn't it even have some L1 cache?
08:26:26 <geist> it's actually almost directly like a 68000, it was built specifically to go up against a 68000
08:26:55 <geist> ie, 'lets extend this stupid x86 arch one last time to at least try to have a feature equivalent to the 68k' was what they were doing
08:27:23 <geist> not this one. some other 386s at the time would have had a cache (wouldn't have been called L1 at the time since that implies that there was an L2)
08:27:24 <mrvn> did the 386 have multi bit shifts?
08:27:29 <geist> yes
08:28:07 <mrvn> On the 69020 they added 256 byte cpu cache. Big boost.
08:28:16 <geist> really a 80386 is about like 68020 feature wise
08:28:40 <geist> or maybe 68030 since it had a mmu built in
08:29:02 <geist> and in both cases, the 040 and the 486 were where both companies started to really focus on performance
08:29:11 <geist> and thus 486 and pentium were big leaps forward in performannce
08:29:38 <geist> but even 000 020 and 030 if you read the cycle count matrix it's far slower than todays machines
08:29:45 <mrvn> The pentium had a huge boost in fpu performance. 68040/60 had faster intergers.
08:29:56 <geist> since most instructions took many cycles, they were far from superscalar
08:30:07 <mrvn> no pipelining
08:30:23 <mrvn> I think the 060 was the first superscalar one.
08:30:41 <geist> yah
08:31:09 <geist> pentium was almost in extremely specific workloads, pentiumpro was the first proper superscalar x86 from intel
08:31:20 <geist> so timeline wise the 386 came out between 020 and 030
08:31:27 <geist> 85
08:33:58 <mrvn> I would have loved a 1GHz m68k or a 64bit extension.
08:35:02 <geist> yah i never owned a 68k machine at the time, so it sort of passed me by
08:35:24 <geist> never got too attached. i did wire one up on a breadboard the other day. it runs in a hard loop
08:36:32 <geist> found a set of 68k chips on ebay the other day. was like $10, a set of random 68k parts
08:36:39 <geist> probably pulled out of an arcade machine or something
08:37:05 <mrvn> I still have an 68030 ans two 68060 here.
08:37:33 <mrvn> Havent used them in 10+ years but can't make myself throw them away.
08:39:07 <mrvn> *wave* got to go.
09:20:45 <lkurusa> if you can find working chips like that on ebay
09:20:48 <lkurusa> i should frequent ebay more
09:25:25 <geist> lkurusa: yeah, i had a fairly low expectation, but these came through
09:25:51 <lkurusa> very nice, i would love to get my hands on some more cpu architectures
09:25:59 <lkurusa> i'm hunting for sparc, pa-risc and m68k right now
09:26:11 <lkurusa> well, not "hunting", i'm barely look to be honest
09:26:16 <lkurusa> s/look/lookig
09:26:22 * lkurusa sighs, he can't type
09:26:31 <klys> type
09:26:50 <Desetude> I've seen a lot about how unikernels by design are unfit for production and was wondering what do you all think about unikernels?
09:28:48 <klys> production may include integration, obfuscation, and risk management
09:32:11 <Desetude> well I'm thinking more of integration
09:33:36 <klys> vertical integration leverages your product, as they used to say
09:34:12 <Jari--> hi all
09:34:15 <klys> hi
09:34:20 <Jari--> ran out of disk space on image crawler
09:34:24 <Jari--> 50 gigs here
09:34:24 <Jari--> :D
09:34:32 <geist> grats?
09:34:33 <Jari--> doing this besides JTMOS operating system
09:35:24 <Jari--> http://www.altse.online
09:37:30 <klys> well it says it found images, though I don't see any
09:37:32 <geist> okay.
09:50:42 <Jari--> klys: geist I see
09:50:56 <Jari--> fixing a bit, got disk full so the databased can be trashed :(
10:24:22 <Jari--> hmm
02:04:51 <SzateX> Hi. Is someone who done something with VGA Registers? I'm trying to read registers (to get values what to set for mode 13h). I enter 13h into bootloader. Draw screen we blue. And try to read - i got black screen...
02:05:37 <MarcinWieczorek> Show us the code or something
02:06:35 <SzateX> https://gist.github.com/SzateX/17f9cbee041415cbcad857191dd99c8e
02:06:56 <SzateX> int i = 0 is only prepared place to set breakpoint
02:07:19 <bcos_> "I enter 13h into bootloader..... i got black screen" = exactly what you'd expect?
02:08:09 <MarcinWieczorek> are you doing the int in v8086 or real mode?
02:09:35 <SzateX> bcos_, i'm trying to set some wahtches to my arrays where store values from vga registers. Before reading i paint my screen with blue color. But when read. My screen got black - it shouldn't - it looks te mode was gone.
02:10:02 <SzateX> MarcinWieczorek, int is called in bootloader in real mode. Rest is done in protected modee
02:13:56 <bcos_> SzateX: I'm thinking you'll need to read through something like this: http://www.osdever.net/FreeVGA/vga/vgareg.htm
02:14:51 <SzateX> I read this. I read also Intel Hd Grpahics documentation
02:15:03 <SzateX> and some other sources
02:17:11 <MarcinWieczorek> do you reset 0x3C0 to the index state?
02:17:13 <bcos_> e.g. "Note that certain CRTC registers can be protected from read or write access for compatibility with programs written prior to the VGA's existence."
02:17:56 <bcos_> Ah..
02:18:18 <bcos_> And "The attribute registers are also accessed in an indexed fashion, albeit in a more confusing way. The address register is read and written via port 3C0h. The data register is written to port 3C0h and read from port 3C1h."
02:18:37 <bcos_> ..you're reading from the "write" port not the "read" port for that I think
02:19:50 <SzateX> MarcinWieczorek, before enter next index i read value from 0x3DA (Intel say that also can be 0x3BA)
02:20:44 <SzateX> bcos_, no. i put index to 3C0h and go next index and read value from them
02:21:45 <bcos_> You put index in 0x3C0 and read from the write port at 0x3C0; when you should put the index in 0x3C0 and then read from the read port at 0x3C1
02:22:12 <SzateX> where?
02:22:39 <bcos_> Line 84?
02:23:16 <SzateX> Line 7?
02:23:41 <bcos_> Ah - OK
02:25:03 <bcos_> ..in that case; aren't all the other's wrong?
02:26:36 <SzateX> i'm looking many times and i'dont see error
02:26:43 <SzateX> maybe i look on it too many times
02:27:54 <bcos_> No - it's right
02:28:26 <bcos_> Hrm
02:28:55 <bcos_> No obvious bugs; so I'd recommend commenting out parts to see which part causes "black screen"
02:29:06 <SzateX> okay
02:31:58 <SzateX> sequencer is ok
02:34:16 <bauen1> https://wiki.osdev.org/index.php?title=Talk:GCC_Cross-Compiler&curid=1967&diff=23067&oldid=22066
02:35:56 <SzateX> it look it errors in reading attribute registers
02:36:39 <SzateX> so in the last
02:40:29 <bcos_> SzateX: Now just try one register (then if that works, the first half or the last half) - mostly try to figure out if it's a specific attribute controller register causing trouble or some or all
02:41:48 <SzateX> first index
02:42:08 <SzateX> is doing weird things
02:44:13 <bcos_> Maybe do a dummy read from 0x3C1 first, in case the internal flip-flop is in the wrong state (in case the write you do to set the index is become a write to a previously selected register instead)
02:45:15 <SzateX> like that? https://gist.github.com/SzateX/15d8b79ec8917f230ebded933e000046
02:46:00 <bcos_> Yes
02:46:11 <bcos_> ..although I'm not sure what 0x3DA is yet
02:46:27 <SzateX> nope it crashed
02:46:27 <bcos_> (external register?)
02:46:36 <bcos_> Crashed = black screen?
02:46:49 <SzateX> yes
02:46:54 <SzateX> from here: https://wiki.osdev.org/VGA_Hardware#Port_0x3C0
02:47:50 <SzateX> oh
02:48:22 <SzateX> i removed 0x3DA, do dumped read from 0x3C1 and for first register worked
02:48:27 <bcos_> Ah - that 0x3D
02:48:28 <bcos_> :-)
02:49:16 <SzateX> 0x3D?
02:49:17 <bcos_> The FreeVGA stuff ( http://www.osdever.net/FreeVGA/vga/vgareg.htm ) says that's an undocumented register that the original IBM VGA supported, and some other cards implement it and others don't
02:50:16 * bcos_ was going to type "Ah - that 0x3DA is an undocumented..." byt you realised it's a problem before I finished typing it :-)
02:50:40 <SzateX> okwy
02:50:50 <SzateX> but for all registers still don;t work
02:50:56 <SzateX> i put two registers to read
02:51:42 <SzateX> for one register works as well, but for two still don't
02:53:06 <SzateX> i will do later
02:53:09 <SzateX> i have to go
02:53:18 <SzateX> Thanks for help in debugging
02:53:26 <bcos_> K - cya
02:54:04 <bcos_> Hrm. It's not 0x3DA that's undocumented
04:31:46 <zenix_2k2> i don't know if this is osdev related but can Windows install itself in 2 or more separated partitions ? i used to see some Linux distros doing that before, like /home in as /dev/sda2, / as /dev/sda3, ...
04:33:59 <mischief> it is not osdev related. go ask ##windows.
04:34:28 <zenix_2k2> ok
05:35:02 <mra90> how is PCI BAR programmed? I mean how it is set to point to specyfic memory region?
05:38:32 <bcos_> For the BAR itself; write 0xFFFFFFFFF and read the value back to determine the alignment requirements and size (and which address space - physical or IO port); then allocate somewhere for it, then write that to the BAR
05:39:04 <bcos_> ..but don't foget that any PCI bridges have to be configured to forward addresses in the selected range from one bus to another
05:39:56 <mra90> bcos_, my situation is a bit different I do have already enumerated device in PCI
05:40:11 <mra90> and I see its BAR points to some memory space
05:40:21 <mra90> the quetsion is how was it decided where to point?
05:40:45 <mrvn> bios?
05:40:47 <bcos_> You can (usually, excluding things like hot-plug and firmware bugs) just re-use the resource assignment that firmware pre-configured
05:42:09 <dormito> mra90: the bar does point to memory. it tells the device which address (range) to 'listen' on
05:42:22 <dormito> *the bar does NOT point to memory
05:44:24 <mra90> dormito: I use read/write everything tool
05:44:43 <mra90> and when I click on BAR address it takes me do some memory inside the device
05:44:54 <mra90> what memory rregin is it?
05:45:13 <mra90> beginning of RAM, ROM, some other space?
05:45:18 <bcos_> That's not necessarily memory (in the "RAM" sense) - often it's registers with bizarre side-effects
05:45:55 <mrvn> mra90: device specific
05:46:14 <dormito> it's 'memory' on the device it self. PCI devices have their own 'memory' regions (it can be ram, or device registers or w/e ... but it's all located on the device itself)
05:46:53 <mra90> so during enumeration/initialization of PCI device the device itself decide what to show for host
05:46:53 <mra90> ?
05:47:51 <bcos_> Firmware does what I was mentioning to begin with ("write 0xFFFFFF, read back to determine...") to assign resources to PCI devices
05:48:34 <bcos_> ..typically in a "recursively visit all parts of the tree" way
05:48:34 <mra90> bcos_: doesn;t make sense
05:49:01 <mra90> firmware writes 0xFFFF to its own memory? Why it alredy know about itself ;)
05:49:11 <mrvn> mra90: the systems firmware
05:49:37 <dormito> mra90: that's sort of correct. each device has it's own resources. The BIOS programs the BARs (and the bridges) so that those resource are accessible (from the processor) at a specific address (it's a memory address, but it's not your typical RAM).
05:50:12 <mrvn> mra90: the bios/uefi enumerates the PCI bus to find boot devices.
05:50:20 <bcos_> No - some bits in each BAR are hardwired to zero and can't be set; so that if you (or firmware) writes 0xFFFFFFFF to the BAR you can figure out which bits can/can't be set, which tells you the size of the area and its alignment requirements (lowest bits are hardwired/can't be set)
05:50:37 <dormito> if you know anything about routable protocols (aka ipv4 being the classic one): in the context of PCI memory addresses are routeable
05:51:02 <bcos_> E.g. you might write 0xFFFFFFFF and read back 0xFFFF0000, so you know it's a 64 KiB area that requires 64 KiB alignment
05:51:28 <bcos_> ..and then you find a 64 KIB area with suitable alignment somewhere, and write that value to the BAR
05:53:34 * mrvn wonders what happens if you hardwire all bits of the BAR to 0.
05:53:50 <dormito> bah. I've drawn (on white boards) so many physcial memory maps. I should draw one and post it on the wiki
05:54:04 <dormito> mrvn: the it's a device that violates the PCIe spec
05:54:09 <dormito> *PCI spec
05:54:18 <mrvn> dormito: why? I need 4GB address apce. :)
05:54:28 <mrvn> space
05:54:32 <mra90> Okay, so now we have address space for the device and lets say it is 0x7FFFFEF000. Now the question is where it will take me if Igo there
05:55:09 <dormito> then you must use a 64bit 'register' (two bars are 'combined'). Also I think the max BAR size is limited in the spec... but it's been a while since I read it
05:55:29 <mrvn> mra90: if you write to any memory the PCI device checks if BAR <= address < BAR + size. If so it uses the data. Otherwise it is ignored.
05:55:55 <mrvn> dormito: even 2GB size would be fatal.
05:56:18 <dormito> mra90: accessing the physical memory addressed that can be found in BAR's takes you to 'memory' backed by the device the bar was located at. The properties of that 'memory' are device specific
05:56:53 <dormito> mrvn: iirc 32-bit x86 reserves a maximum of 1GiB for PCI registers
05:56:53 <mra90> dormito: so in short - the device itself decide what it want to show for OS/host?
05:57:03 <mrvn> mra90: yes
05:57:06 <bcos_> mrvn: I'm not sure what the rules are for 64-bit BARs (you might be able to have 4 GiB of space for a 64-bit BAR)
05:57:09 <mra90> in terms of some register for example
05:57:20 <dormito> yes. because you are accessing a device 'resource'
05:57:35 <mra90> Okay, thank you guys! :)
05:58:10 <mrvn> Is there a device tree for amd64?
05:58:37 <dormito> mrvn: thats a bit... vauge. do you mean a memory map?
05:58:50 <bcos_> mrvn: Maybe (depends on which, could be full UEFI+ACPI+PCI instead)
05:59:09 <mrvn> dormito: no. I mean a device tree. Like 99% of ARM systems use to specify hardware to the kernel on boot.
05:59:23 <dormito> oh you mean a litteral dtb
05:59:34 <dormito> that's a very kernel specific thing
06:00:05 <dormito> most of the info that arm/ppc/etc/ uses dtb for is either archatectural in x86, or findable via ACPI,UEFI/etc
06:00:17 <bcos_> I think 99% of ARM provides nothing at all, and then people add device tree to customised boot loaders (uboot) to provide info to the OS that didn't exist in hardware
06:00:23 <dormito> however the linux kernel does support dtb's in x86 (but I've never seen anyone use them)
06:01:11 <mrvn> bcos_: well, depends on what you mean by provides. Most ARM come with a customized uboot nowadays.
06:01:19 <bcos_> Hrm
06:01:54 <mrvn> As in you buy a board and get an uboot with it.
06:01:57 <bcos_> dormito: A while ago (when Intel was experimenting with smarthpone SoCs) there was a "simplified firmware interface" spec that mostly died
06:02:08 <dormito> I've never seen an arm with a dtb in, say, rom. However yes dtbs are typically provided (by someone in the sw stack) to the kernel &| uboot
06:02:47 <mrvn> dormito: haven't gotten any ARM with a ROM yet. Always flash or SD card.
06:03:41 <mrvn> then again I don't have any ARM servers. Just embedded boards.
06:04:20 <dormito> mrvn: most of the ARM chip's I've seen (both uC and ones with mmus) have a small (typically ~4-32KiB) boot rom region. Typically it does things like examin pin strapping to find the next boot stage
06:06:42 <dormito> like for example: TI's am335x SoCs have a small rom that can 'boot' off mmc, usb (ECM+bootp),nand,uart,spi. (the AM335x series is used on some/all of the BeagleBone series)
06:07:16 <mrvn> dormito: and when you tun it on it doesn't say "UBoot"?
06:07:34 <dormito> the rom code can load uboot, but it's not uboot
06:07:45 <dormito> it doesn't setup dram or anything like that
06:09:28 <mrvn> dormito: maybe my boards have something like that. Never lookes at what happens before uboot starts. I thought at boot the fash would start out being mapped at 0x00000000 and execute the uboot directly.
06:10:16 <dormito> mrvn: that's a very chip specific thing. But all the chips I've looked at. it's rom code that does that mapping (and then jump's into flash)
06:10:28 <mrvn> But with SD cards you are right, something has to read the SD card where the uboot is on.
06:10:47 <dormito> also u-boot is GPL-d I think, so I highly doubt most SoC manufactures would put it in rom code
06:11:14 <mrvn> dormito: they don't put it in ROM because it most likely needs to be updated again.
06:11:30 <dormito> there's that too
06:12:08 <dormito> if your chip has pin strapping that can change where u-boot is loaded from, thenb odds are it has rom code that makes that decision
06:12:38 <mrvn> dormito: makes sense. Just never thought about that.
06:13:34 <dormito> mrvn: when you find bugs in rom code... that's when you have to start caring :/ (good luck never needing to care)
06:13:46 <mrvn> I think the only pins I have are for flash vs SD card. None for booting over uart. For that you use uboot.
06:14:38 <mischief> my ci20 can boot from usb, onboard nand or sd with pin settings
06:14:54 <mrvn> dormito: That's why it makes sens to have only enough in rom to load uboot. As you said they don't even set up dram timings before that.
06:15:54 <dormito> well, I've seen bugs in the MMC protocol rom code ...
06:16:42 <mrvn> dormito: that sucks.
06:16:46 <dormito> yep :(
06:17:29 <clever> the allwinner A20 and raspberry pi both have similar boot roms in the cpu
06:18:04 <mrvn> clever: raspberry PI boots the VC and then has a programm to activate the ARM coprocessor.
06:18:24 <mrvn> That's like 3 or 4 levels later.
06:18:29 <clever> mrvn: yeah, but the VC boots up in pretty much the same way
06:18:59 <clever> a boot rom that supports nand flash, sd cards, usb mass storage, usb ethernet, and something else
06:19:12 <clever> and it doesnt bring up dram, the stub on one of the above media has to do it
06:31:19 <mra90> have you ever seen backslash in fron of a register in gnu assembler?
06:31:37 <mra90> I mean i.e rsr \a0 xyz
06:31:49 <mra90> oO
06:40:56 <dormito> mra90: iirc thats typically done as part of a macro (but I dont use gas so I cou;d be mistaken)
06:46:52 <mra90> dormito: so slash is defined as macro? ;:
06:46:54 <mra90> ;P
07:09:41 <abysslurker> o/
07:45:27 <mrvn> mra90: iirc \ denotes a macro argument.
07:46:03 <mra90> mrvn: yep makes sense however I can not find focumentation for it
07:47:43 <mrvn> info as
07:47:46 <mrvn> 7.58 '.macro'
07:49:09 <SzateX> Okay, i'm back. And thinkinh about 0x3C0 Registers, why they crashed
07:49:40 * geist waves
07:50:31 * abysslurker yawns
07:50:53 <glauxosdever> That's the new meme, eh?
07:51:40 <geist> what, waving and yawning?
07:51:47 <geist> i think that goes back a bit farther
07:51:59 <glauxosdever> Yawning
07:52:15 * mrvn yawns
07:52:16 <glauxosdever> It officially became a meme
07:52:31 <mra90> mrvn: very laconic but I got it from example thanks
07:52:50 <glauxosdever> It's too bad. Now instead of writing code, we will yawn because of boredness...
07:53:04 <mrvn> reading the macro docs again shows how bad a lexer and parser GNU as has.
07:54:21 <geist> well, i got to thinking about the TSS task switch last night so i think i need to try doing it manually and seeing what the performance diff is
07:54:43 <geist> but first, i need to finish voting
07:54:48 <mrvn> geist: I wonder if it was faster back then
07:54:54 <geist> exactly, dunno
07:54:57 <mrvn> geist: do you have an FPU?
07:55:04 <bcos_> SzateX: I'm wondering if you need to read from 0x3DA before every "write index, read data" in case reading data doesn't cause flip-flop to flop
07:55:06 <geist> i do, via an external 80387
07:55:10 <aalm> .roa
07:55:10 <glenda> 10 Greed is eternal.
07:55:14 <geist> but most 386s wouldn't have had one
07:55:21 <mrvn> geist: I think one big time saving comes from lazy FPU saving.
07:55:33 <geist> almost assuredly yeah
07:55:45 <mrvn> especially back then with the external FPU
07:56:25 <mra90> mrvn: why do you think gas is bad?
07:56:31 <SzateX> bcos_ but in begining i do it
07:56:39 <SzateX> maybe something interrupts
07:57:01 <SzateX> or... optimalization
07:57:35 <mrvn> mra90: because '\foo:' isn't lexed/parsed as BACKSLASH <ident> COLON but simply as <ident> and later magically cought as label. So the macro subtituion doesn't subtitute the \foo
07:58:35 <bcos_> SzateX: Unlikely something interrupts if you're in protected mode, and I'd hope your inline assembly (for in/out instructions) is "volatile" to prevent re-ordering
07:58:51 <mra90> mrvn: but as long as you don't use it to produce labels it is ok
07:59:14 * lkurusa yawns
07:59:31 <mrvn> mra90: it shows a lack of proper lexer, parser and abstract syntax tree
08:00:21 <mra90> mrvn: I agree, and after all the choice of '\' is just awkward isn't it?
08:00:37 <mrvn> mra90: the other things is that GNU as can't load a PC relative address from another section
08:00:44 <SzateX> bcos_ they look like this: https://gist.github.com/SzateX/29507379727f09fa1c7c2e50de38b9aa
08:00:58 <mrvn> mra90: clang can on ARM
08:02:01 <mra90> mrvn: gnu as is the most popular assembler
08:02:08 <mra90> so there must be a reason for it
08:02:25 <mrvn> because it used to be pretty much the only one you got for free
08:02:43 <mra90> yeah that;s maybe
08:02:52 <mra90> btw, can you show an example of "the other things is that GNU as can't load a PC relative address from another section"
08:02:58 <mra90> I don;t quite get it
08:03:43 <mrvn> You got this nice pool of 20 unix systems at the university but don't have the extra $20k to buy the compiler. So you install GNU gcc+binutils and have a even better (as in everything compiles) one.
08:06:02 <mrvn> mra90: you can do: ldr r4, =memory_regions
08:06:12 <bcos_> SzateX: Try "__asm__ volatile" instead of just "__asm__"
08:06:23 <mra90> mrvn: yes and?
08:06:46 <mrvn> mra90: where memory_regions is in another section. That then creates a constant in the ".ltorg" part with the address.
08:07:20 <mrvn> mra90: but you can't make the PC relative. GNU as always complains that the symbol is in a different section. clang does it right and creates a REL32 constant in the object file.
08:08:11 <mra90> mrvn: ok I see
08:08:41 <SzateX> still doesn
08:08:53 <SzateX> bcos_, still doesn't help
08:09:03 <SzateX> also locked interrupts
08:09:11 <SzateX> and reenable after
08:09:43 <mrvn> SzateX: an asm() statement with input/output parameters must list all side effects because the compiler is allowed to optimize it out.
08:09:47 <bcos_> SzateX: Ok - now try putting the "inb(0x3DA)" inside the loop (before every "set index")
08:10:31 <bcos_> mrvn: Not sure there's any side-effects (other than "al = output" for the inb)
08:10:53 <bcos_> (at least none that GCC can be told about)
08:11:05 <SzateX> but is putted: https://gist.github.com/SzateX/90b494e0b892d5189dab0bc59b9b932b
08:11:20 <mrvn> bcos_: yeah. I don't think there is a flag for "this changes a port". volatile will just mark it as "this has some unspecified side effect"
08:11:39 <SzateX> i done a++ to make sure, the gcc doesn't remove this
08:12:11 <mrvn> SzateX: The result of a++ is not used so a++ gets optimized out.
08:13:20 <SzateX> so maybe... inb(0x3DA) is optimized too
08:13:27 <mrvn> SzateX: add the volatile as suggested above and do check the objdump for but.o to see what the compiler actually generates.
08:13:55 <mrvn> SzateX: without volatile I think it should.
08:14:19 <SzateX> volatile after asm yes?
08:14:24 <SzateX> a put
08:14:49 <SzateX> wait i open hex editor
08:15:03 <mrvn> SzateX: with volatile the compiler is not allowed to optimize the inb away since you told it that it has observable side effects
08:15:15 <mrvn> SzateX: not hex editor, use objdump -d
08:15:48 <SzateX> objdump you say...
08:16:36 <mrvn> My expectation would be that the loop is unrolled and getRegisterDataNext is inlined.
08:17:40 <isaacwoods> or the inb is hoisted out of the loop and so only happens once
08:17:51 <mrvn> isaacwoods: can't, it's volatile.
08:18:15 <isaacwoods> mrvn: ah I thought this was still not declared volatile
08:18:19 <isaacwoods> my bad
08:18:40 <mrvn> isaacwoods: if it's not then it should disappear completly.
08:18:55 <isaacwoods> true
08:19:21 <mrvn> SzateX: add the objdump -d output to the gist please
08:20:02 <SzateX> wait a minute, i need to get objdump - i'm working on windows...
08:20:15 <bcos_> :-)
08:20:23 <mrvn> bcos_: reading a port can have side effects on the attached hardware. Like the uart loads the next received byte into the data register.
08:21:58 <mrvn> SzateX: did you cross compile gcc and binutils?
08:22:19 <mrvn> ^^built a cross compiler + cross binutils I mean
08:23:00 <SzateX> yes we did it (generally we worked with this with few people)
08:23:27 <mrvn> then you should have the cross objdump too. It's part of binutils
08:23:49 <SzateX> https://gist.github.com/SzateX/f77eff95cf3e5bad9459898947c1f5f1
08:24:25 <mrvn> SzateX: you do know that you can edit gists, right?
08:24:33 <SzateX> yes yes
08:24:40 <SzateX> i use gists many times :)
08:26:23 <mrvn> did you use -O2?
08:28:01 <bcos_> I'd assume no..
08:28:20 <SzateX> Yes we use
08:29:47 <mrvn> I'm seeing the "a++" in there but not the "asm volatile"
08:31:56 <mrvn> An objdump of the kernel image could also help instead of the object file. So the linker refrences are filled in properly. E.g. "9c9: e8 fc ff ff ff call 9ca <getAtributteContRegisters+0x1e>" looks incomplete.
08:32:01 <SzateX> so problem will be here? https://gist.github.com/SzateX/168d83bbcaed1ce5278e24681c648650
08:33:04 <mrvn> is that a .h file? a .c file? did you "make clean" or ensured your Makefile predepends are correct and it actually compiled the getAtributteContRegisters again?
08:33:48 <SzateX> is this c file
08:34:13 <mrvn> From the code it looks like a .c file, which means it doesn't get inlined. So some of the call statements in the dump are the inb calls.
08:34:22 <geist> yah .o files usually have their branch offsets set to 0 or whatnot for externals
08:35:05 <mrvn> I assumed (wrongly) you had those inb/outb in header files. But then they should have been static inline.
08:38:35 <mrvn> SzateX: you have to objdump the full kernel image to see what those "call" lines actually call. And check again that you actually use -O2 or -Os. Looks to me like -O0 output.
08:39:09 <dormito> gcc doesn't have intrinsics for in/out?
08:39:28 <mrvn> dormito: you mean __builtin?
08:40:12 <dormito> I rarely use them, but yeah I think they are part of the builtin subset
08:40:19 <bcos_> Might be better to just shift the in/out into a header file as "static inline"
08:40:58 <bcos_> (than to objdump the full kernel image)
08:41:11 <SzateX> i'm shifting first
08:41:43 <geist> for in/out? if there are builtins they're news to me
08:41:44 <mrvn> dormito: no __builtin_inb in the info files
08:41:52 <geist> that being said, a simple inline asm works fine
08:41:55 <geist> it's easy to do
08:42:02 <bcos_> Other than not inlining and being unoptimised; I think it's doing what it's told (e.g. the "inb(0x3DA)" is inside the loop, etc)
08:42:05 <mrvn> dormito: builtins are more for things many architecture have.
08:42:25 <geist> there's a tiny subtley that i discoverd the other day that lets you use the immediate form of in/out if the port is < 8 bits
08:42:34 <geist> but aside from that it's ez
08:42:38 <dormito> I know they have them for some sse registers
08:42:51 <mra90> I recently heard two audio engineers talking about some audio stream encoded as "24bits in 32bits" - does anybody have any idea what does it mean?
08:43:17 <geist> sure, use a uint32_t to hold 24 bits of audio data
08:43:24 <mrvn> mra90: probably that each 24bit value has 8bit padding.
08:43:26 <geist> you waste 8 bits, but it's easyer for the cpu to parse
08:43:58 <mrvn> more likely each 12bit channel has 4bit padding so you have int16_t sample[2];
08:44:19 <geist> dunno about that, how many things pass around 12 bit audio channels?
08:44:50 <mra90> hmm ok it is possible
08:44:57 <mrvn> geist: does 24bit make any sense for audio? Would be pretty high quality
08:45:02 <geist> sure
08:45:21 <dormito> mrvn: see https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions they have builtins for a whole lot fo x86 extensions
08:45:26 <geist> lots of stuff is 24 bit now. and definitely makes sense for inner audio processing, since it gives you headroom to expand your 16bit audio bits
08:45:46 <geist> process in 24, then decimate back down to 16 if that's all your audio hardware supports
08:45:56 <mrvn> hmm, true
08:46:04 <mra90> geist: very likely ;)
08:46:04 <geist> or just immediaely promote everything to 24 internally and use a 24bit audio DAC, which lots of sound cards and whatnot support now
08:46:32 <geist> similarly, some audio engines use floats for internal processing
08:46:42 <geist> a 32bit bloat gets you a sign bit and 23 bits of mantissa
08:46:49 <geist> hah float i mean
08:47:17 <mrvn> geist: 24bit samples and much more for silent stuff
08:47:49 * bcos_ can do silent stuff with 0-bit samples!
08:47:51 <geist> pro audio stuff usually works up in 24 bit and maybe 96 or 192 sample rate nowadays
08:48:16 <geist> 24/96 is i think a fairly common format
08:48:20 <mrvn> bcos_: but no more than 2 seconds or you have to pay license fees
08:48:35 <geist> anyway back to voting. nearly done!
08:49:15 <mrvn> I need a system with 3, 5 or 7 cpu cores so I can have them vote without deadlocks
08:49:35 <mischief> just don't boot one of the cores?
08:50:45 <SzateX> Okej: https://gist.github.com/SzateX/dc7f22fea45f00afafcc4a1d250e4458 - vga.dmp and kernel.dmp: https://gist.github.com/SzateX/166a07864a172a635bb53d6f39cf1b59
08:50:45 <mrvn> mischief: that would be too easy.
08:50:47 <dormito> the Hifirve unleashed has 5 core (though one of them is... very different)
08:50:54 <dormito> *Hifive
08:51:45 <mrvn> SzateX: see: 111c0: e8 22 f6 ff ff call 107e7 <inb>
08:51:54 <mrvn> 111ea: e8 7c fd ff ff call 10f6b <getRegisterDataNext>
08:52:57 <SzateX> looking for...
08:53:05 <mrvn> And the fun of having -O0 output from gcc: 111c8: 88 45 f3 mov %al,-0xd(%ebp)
08:53:08 <mrvn> 111cb: 8a 45 f3 mov -0xd(%ebp),%al
08:53:20 <mrvn> Lets store something on the stack so we can load it right back into the same register.
08:53:35 <SzateX> in build scripts it is -02 setted
08:53:55 <mrvn> SzateX: but it's not getting used.
08:54:49 <mrvn> SzateX: for gcc the last -Ox option counts if you have it multiple times
08:55:39 <mrvn> SzateX: anyway, the generated code does what you wrote in the source. So your source must be wrong. Not an optimizer problem.
08:56:03 <SzateX> but.. i haven't see problem with code.
08:56:22 <SzateX> i do what in Intel docs and osdev wiki says
08:56:59 <mrvn> SzateX: maybe it is a timing problem. You only have X cycles time between the inb/outb to the hardware and due to not optimizing the cpu takes too long.
08:57:13 <SzateX> And in scripts they are not Os
08:57:20 <SzateX> more then one
08:57:39 <mrvn> Had that happen on ARM. When I removed my debug printf()s the code suddenly worked because the timing was right.
08:58:21 <geist> yay done
08:58:21 <bcos_> mrvn: Unlikely for 80x86 though - the in and out instructions are so slow that everything else will be relatively insignificant
08:58:36 <SzateX> i didn't see any informations about timing
08:58:51 <mrvn> bcos_: yeah. But O0 code is so horribly long.
09:00:24 <SzateX> build script: https://gist.github.com/SzateX/ed3dd7d2ebc3d24736fd12f9c97b74b5
09:00:34 <mrvn> Like a simple "inb; outb;" turns into nearly 100 bytes with 4 function calls.
09:01:13 <mrvn> ~/opt/cross/bin/i386-elf-gcc -g -c $SourceFiles -ffreestanding -Wall -Wextra -fshort-enums
09:01:17 <mrvn> no -O2 in there
09:01:51 <mrvn> You only have -O2 when linking. Which makes no sense without LTO
09:02:13 <SzateX> okay i'm building and diong dump
09:03:03 <SzateX> https://gist.github.com/SzateX/fc89d38a98c08ff3bc1bcc48357d1d28
09:04:23 <SzateX> ohh... ok
09:04:52 <SzateX> 34 line -O2 should be? Am i right?
09:05:33 <mrvn> don't forget -W too
09:07:05 <SzateX> oh from 100KiB to 86 KiB yeah!
09:07:11 <mrvn> At some point you should look into writing a Makefile so you don't recompile everything on every change. But that is not relevant to the current problem.
09:07:41 <mrvn> And either use LTO or put some of the trivial functions as "static inline" into header files.
09:07:52 <SzateX> paste dump?
09:08:17 <mrvn> SzateX: read it yourself. shouldn't differ much. Still have the calls to the function you call.
09:08:31 <mrvn> The "a++" part should be gone
09:09:13 <SzateX> yes
09:09:26 <SzateX> and in is inline now
09:09:50 <SzateX> no...
09:10:26 <SzateX> there is no calls to functions except disable and enable
09:10:42 <mrvn> SzateX: are the inb/outb in the same .c file?
09:10:58 <SzateX> no
09:11:00 <SzateX> only included
09:11:25 <SzateX> maybe i should paste code, and get link to repo
09:11:32 <SzateX> paste dump*
09:11:43 <mrvn> are you including the .c file that has inb/outb in it?
09:12:05 <mrvn> (don't)
09:12:12 <SzateX> no, .h where inb and outb are static inlines
09:12:24 <mrvn> Ok, you didn't paste that before.
09:13:12 <SzateX> i do change after paste code - because you or someone ask about it
09:13:25 <bcos_> Does it work now that it's faster?
09:19:19 <SzateX> works faster... but still not solving problem - this is not timing problem
09:20:11 <bcos_> Can you try skipping first 16 registers and only doing last 5 (e.g. "for(i = 0x10; i <= 0x14; i++) {"
09:20:57 <bcos_> (those first 16 registers are for internal palette and aren't used for mode13 anyway - I'm thinking video card doesn't emulate them right because they don't get used)
09:21:58 <jjuran> mrvn: If they're in header files, shouldn't they just be `inline`?
09:22:07 <SzateX> bcos_, no
09:22:16 <SzateX> it doesn't work...
09:24:31 <bcos_> D'oh\
09:24:48 <SzateX> https://github.com/Tearth/MicrOS/tree/GVGA/Source/Kernel/Drivers/VGA here is whole code
09:25:01 <SzateX> i seriously have no idea what is wrong
09:25:49 <bcos_> SzateX: Can you try a different computer (with different video card - maybe AMD or Nvidia)?
09:26:50 <SzateX> where am i here now i have no physics pc :(
09:27:13 <SzateX> i will try maybe on Virtual Box not QEMU
09:27:26 <bcos_> Oh
09:27:36 * bcos_ wouldn't trust emulators much.. ;-)
09:28:13 <bcos_> (when you said you were reading Intel's GPU docs I mistakenly assumed you were testing on an Intel video)
09:28:16 <SzateX> but i read that doing something wrong in register can burn monitor or card
09:28:51 <bcos_> Extremely unlikely
09:29:25 <bcos_> ..especially if you're only messing with VGA regs and don't have a CRT monitor from 30 years ago
09:30:38 <SzateX> so it looks something meesing in registers
09:37:21 <bcos_> Hrm
09:38:56 <bcos_> SzateX: Looking at the code for Qemu's "Cirrus logic" video card, it looks right enough - reading from 0x3C1 doesn't flop the flip-flop, but reading from 0x3DA does. The rest is sane enough - if index < 21 it grabs a value from an array and returns it else it returns 0
09:39:10 <bcos_> ..and if the flip flop is in the wrong state it returns zero
09:39:23 <bcos_> ..so.. can't cause black screen from reading attribute registers
09:40:04 <bcos_> (assuming you're using cirrus logic in qemu - there's a few other video cards Qemu can emulate that are probably similar but might not be)
09:40:24 <SzateX> hmm... VBox errors with critical error
09:40:44 <bcos_> Does it give any more information?
09:40:53 <SzateX> wait i need see logs
09:40:58 <bcos_> :-)
09:44:47 <SzateX> weird error: https://gist.github.com/SzateX/90e8efb760ce6b2d6b0ab7c6654b5a89
09:49:13 <bcos_> SzateX: Did it let you read attribute registers and then crash while reading sequencer registers?
09:54:29 <SzateX> bcos_, but attribute registers are last
09:58:27 <bcos_> Hrm - maybe it crashed for some other reason; then decided to dump all the VGA registers to the log itself (and couldn't do sequencer registers)
09:58:49 <bcos_> ..the error message at the bottom has almost zero useful information
09:59:32 <bcos_> ..unless there's an error message higher in the logs maybe?
10:00:22 <bcos_> (e.g. maybe it adds "couldn't do something with something" before it starts dumping VGA state to the log)
10:03:11 <SzateX> no the is not
10:05:14 <mischief> oh lordy, my program segfaults normally but valgrind reports no errors
10:06:34 <bcos_> SzateX: Could change the "testRegisters()" function so that "getAtributeContRegisters()" is the only function it calls; just to double check that getting attribute controller registers is still the problem
10:07:02 <SzateX> yes fo course
10:07:02 <bcos_> ...wouldn't be the first time someone had 2 problems where fixing the first caused the second one to cause similar problems ;-)
10:07:50 <bcos_> mischief: If you design a program to cause a segfault, and it successfully segfaults, is there an error?
10:07:53 <bcos_> ;-)
10:08:01 <SzateX> bcos_, still black screen :(
10:08:18 <bcos_> Hrm
10:08:44 <bcos_> SzateX: Can you write some 0xFF bytes to 0xA0000 - maybe it's mode13 is still working even though it's black
10:09:26 <SzateX> have to be 0XFF?
10:09:39 <SzateX> or i can reuse my function to color blue?
10:10:12 <bcos_> Any should hopefully work (except for black - hard to see a black pixel on a black background ;-)
10:11:33 <SzateX> no... black screen
10:13:47 <bcos_> Ok..
10:14:25 <bcos_> Maybe try reading a register that doesn't exist (e.g. "index = 0x99") in Qemu and see if that works
10:14:40 <bcos_> (should return 0x00 for registers that don't exist)
10:15:11 <SzateX> hmm ok
10:16:44 <SzateX> also blackscreen
10:16:52 <SzateX> wait i check value
10:18:55 <SzateX> ugh... why he move my breakpoint...
10:19:16 <SzateX> oh... O2
10:20:31 <SzateX> is 0
10:23:33 * bcos_ only has 2 ideas left - if something put the card into "monochrome mode" then 0x3DA might need to be 0x3CA; and maybe something is corrupting the code before it's executing causing strangness
10:24:34 <SzateX> ill try 0x#CA
10:24:57 <bcos_> D'oh
10:25:01 <bcos_> It'd be 0x3BA
10:27:58 <SzateX> 0x3BA doesn't works
10:28:08 <bcos_> Same (black screen)?
10:28:16 <SzateX> yes
10:30:15 <SzateX> hmm
10:30:18 <SzateX> new behavior
10:30:34 <SzateX> i removed all code which write to text mode
10:30:47 <SzateX> booted, draw something... restart
10:31:25 <bcos_> Booted, read the VGA registers, drew something then restarted?
10:31:52 <SzateX> hmm rather
10:32:11 <SzateX> Booted, draw, read restart
10:32:36 <bcos_> Hrm
10:33:14 <bcos_> Is there anything in Qemu's log saying why it restarted?
10:33:25 <SzateX> wait i neeed look
10:33:27 <bcos_> (usually something about an exception that happened 3 times)
10:40:08 <SzateX> i do one more check before look to logs
10:40:25 <bcos_> k
10:45:45 <SzateX> do you know where qemu put logs?
10:46:14 <bcos_> I have no idea.
10:47:40 <bcos_> SzateX: https://lists.gnu.org/archive/html/qemu-devel/2013-01/msg04059.html
10:52:08 <ybyourmom> I'm trying to piece together a way to begin to integrate cryptography in everything I do
10:52:56 <ybyourmom> And it's really hard to find a way to have a hardware private key storage and signing device, which also acts as a server I can connect to which will sign things and encrypt them for me
10:53:06 <ybyourmom> And also store public keys for me
10:53:33 <ybyourmom> And also allow itself to be used with my PC, my phone, and everything
10:54:11 <SzateX> hmm... log is empty...
10:56:51 <dormito> ybyourmom: sounds like you want an HSM (hardware security module)
10:57:23 <ybyourmom> Thanks for the search keyword
10:58:05 <bcos_> SzateX: Is qemu still running? Might need to stop it before it writes the log properly
10:58:34 <SzateX> Yes is still running
10:58:42 <SzateX> i'll try with monitor
11:02:46 <mischief> fg
11:05:55 <geist> bg
11:07:30 <dormito> good job there's no 'curses-over-IRC' protocol
11:08:04 <geist> ncurses
11:09:26 <dormito> fg-in a (n)curses app into a channel would be pretty high on the evil list
11:10:44 <jjuran> I'm working on the Linux fbdev front-end for my Mac emulator, and it's a PITA
11:11:26 <jjuran> Switching the console from text mode to graphics mode requires root
11:12:17 <jjuran> It would be really easy (though a bad idea) to run the whole thing under sudo.
11:13:41 <jjuran> Or I can limit root privilege to a program that just opens a file, sends the fd back over a socket, and exits.
11:13:58 <jjuran> But then the caller needs a way to find this program…
11:28:49 <jjuran> And this doesn't work for /dev/tty0 anyway. Apparently you have to be root to set the mode, even if root opened the file and gave it to you.
11:29:33 <klange> i think, with the linux console, if you're not already in graphics mode tough tits
11:29:41 <klange> there's probably a reason it didn't mode set to a graphics mode in the first place
11:30:09 <jjuran> So users can login to a shell?
11:30:28 <klange> those normally run in graphics modes if available
11:30:37 <klange> for that glorious resolution
11:31:22 <jjuran> I'm not talking about VGA text vs. fbdev. I'm talking fbdev text vs. fbdev graphics.
11:31:33 <jjuran> Raspbian boots up in text mode.
11:32:42 <jjuran> Oh well, I guess I can always require the user to create setuid binaries.
11:37:55 <klange> I'm not sure what you mean by a "text mode" then, because you can totally spit out graphics directly to an fbdev console even if it's running the kernel terminal emulator
11:57:30 <jjuran> I'm referring to the KDSETMODE ioctl
11:58:36 <jjuran> In KD_TEXT mode, the cursor blinks, the screensaver is active, and text written to the console is displayed.
11:58:54 <jjuran> In KD_GRAPHICS mode, none of that happens.