IRC channel logs


back to list of logs

<AlmuHS>hi. I'm starting to refactor the Startup IPI, adding a little HAL to fill the ICR register. But, in the SIPI sequence, I need a good RTC. damo22 had you implemented any delay() function using Lapic Timer?
<damo22>yeah i think so
<damo22>not quite the delay but the timer stores a value somewhere
<damo22>its a WIP
<damo22>latest stuff is in apic.c?
<damo22>sorry im at work
<AlmuHS>my latest work is here
<AlmuHS>I'm not started the startup IPI yet, because I need to get a delay() function, and discover how to correctly store the routine in memory
<damo22>maybe just write a dummy delay function for now that does an empty for loop if youre stuck
<damo22>or figure out how to use the timer value in the code
<damo22>the lapic timer is set up for BSP
<damo22>when you enable ncpus >1
<damo22>it is set up to interrupt periodically
<AlmuHS>the current delay function is a for-loop. But I need some more precise
<AlmuHS>ok, timer in BSP is enough
<AlmuHS>but I need to learn how to capture these interrupts
<damo22>there are two timers in each processors
<damo22>one is for timer interrupt
<damo22>i think you can use the other one for one shot timers
<AlmuHS>where are this implemented?
<AlmuHS>in what file?
<AlmuHS>i will study this then
<AlmuHS>btw, why lapic functions are in ioapic file?
<damo22>the lapic timer is calibrated by pit
<damo22>since it varies with cpu model how fast the timer counts
<damo22>its implemented already
<AlmuHS> calibrated_ticks = pit_measure_apic_hz();
<damo22>yeah, the pit can pause for an accurate amount of time
<damo22>and then we use this to count how many lapic ticks is in 10ms
<AlmuHS>good idea
<damo22>but i dont think you can use pit for every delay
<damo22>once you calibrate the lapic timer you can use that to trigger an interrupt on your desired vector
<AlmuHS>i need 3 or 4 delays for each SIPI
<AlmuHS>1 ms if i remember weill
<damo22>i think you can use lapic_timer_val and calibrated_ticks to create a delay function
<damo22>but you probably have to handle wraparound of the u32
<damo22>lapic_timer_value is a uint32_t and keeps overflowing every time the timer value exceeds 32 bits
<damo22>so if you compare to the current value you have to handle the case where it has wrapped
<AlmuHS>oh, it's true
<damo22>i didnt bother writing the delay function yet
<damo22>but you could do that
<AlmuHS>good idea
<AlmuHS>i will try it
<damo22>the basic idea is that timer interrupt updates the timer current value
<AlmuHS>i did it some years ago in a 8086 over MSDOS :-[
<AlmuHS>add a memory resident routine to capture the hw interrupts from the clock, and increase a counter each N ticks as a timer
<AlmuHS>but 8086 in MSDOS was a bit easier ;)
<damo22>i gtg
<damo22>good luck
<clarity_>okay, so it looks like the best way to run gnu/hurd is to use the debian port and run in kvm on amd64 hardware?
<clarity_>is it 32-bit? Also, it looks like there's a 1.8gb limit?
<clarity_>it looks hurd only uses 1 core?
<clarity_>I'm wondering if I can put it on my eeepc. I can't get anything to work decently on that anymore
***roptat is now known as Guest1860
<Pellescours>clarity_: yes 32bit and 1cpu for now
<Guest6>I used to run gnu/hurd on my eeepc
***Guest1860 is now known as roptat
***roptat is now known as roptat_
***roptat_ is now known as roptat
<clarity_>yeah, the main issue with the eeepc is the keyboard is too small for me LOL
***valerius_ is now known as valerius
***valerius is now known as 077AAB7C8