Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - Martin Erhardt

Seiten: 1 ... 5 6 [7] 8 9
121
Lowlevel-Coding / Qemu stürzt ab bei Multitasking
« am: 24. December 2012, 03:13 »
Qemu stürtzt ab bei Multitaskingpflash_write: Unimplemented flash cmd sequence (offset 000000000001fffc, wcycle 0x0 cmd 0x0 value 0xf000e2c3)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001fff8, wcycle 0x0 cmd 0x0 value 0xf000ff53)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001fff4, wcycle 0x0 cmd 0x0 value 0xf000ff53)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001fff0, wcycle 0x0 cmd 0x0 value 0xfffffff4)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffec, wcycle 0x0 cmd 0x0 value 0x1007ac)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffe8, wcycle 0x0 cmd 0x0 value 0xf000ff53)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffd0, wcycle 0x0 cmd 0x0 value 0x103074)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffcc, wcycle 0x0 cmd 0x0 value 0x101048)
PFLASH: Possible BUG - Write block confirm
122
Softwareentwicklung / Re: gcc spinnt(Linkerfehler)[Solved]
« am: 24. December 2012, 01:02 »
Achso,
Kleine Wissenslücke. Ich verwende normalerweise auch kaum globale Variablen soll man ja nicht (http://ubuntuforums.org/showthread.php?t=658778) :-D
123
OS-Design / Re: Dynamische PIT-Frequenz
« am: 23. December 2012, 23:16 »
Naja http://www.lowlevel.eu/wiki/Scheduler#Round Robin
Zitat
Jeder Prozess wird nach einer festen Zeit gestoppt und der nächste gestartet
Man könnte hier z.B eine Zeit festsetzen nach der der Scheduler einmal zu allen Task gewechselt haben sollte und teilen diese durch die Taskzahl. Damit würde die Timerfrequenz nicht geändert sondern nur die Anzahl der Taskswitchs und es könnte trotzdem zu positiven Performance Auswirkungen führen.
124
Softwareentwicklung / gcc spinnt(Linkerfehler)[Solved]
« am: 23. December 2012, 22:59 »
Ich kriege folgende LinkerFehler:
Das macht keinen Sinn mtenabled ist vorschriftsmäßig als extern markiert und time kommt in irq.c nichtmal vor.
mt/ts.o: In function `init_task':
/home/martin/git/el_toro_repo/src/mt/ts.c:16: multiple definition of `mtenabled'
driver/timer/timer.o:/home/martin/git/el_toro_repo/src/driver/timer/timer.c:9: first defined here
intr/irq.o: In function `handle_irq':
/home/martin/git/el_toro_repo/src/intr/irq.c:8: multiple definition of `time'
driver/timer/timer.o:/home/martin/git/el_toro_repo/src/driver/timer/timer.c:9: first defined here
Selbst wenn ich timer.c und .h  komplett wegkommentiere kommt immernoch:
mt/ts.o: In function `init_task':
/home/martin/git/el_toro_repo/src/mt/ts.c:16: multiple definition of `mtenabled'
driver/timer/timer.o:(.bss+0x0): first defined here
irq.c
#include <console.h>
#include <irq.h>
#include <cpustate.h>
#include "../driver/keyboard/keyboard.h"
#include "../driver/timer/timer.h"
#include<ioport.h>
cpu_state* handle_irq(cpu_state* cpu)

cpu_state* new_cpu = cpu;

if (cpu->intr >= 0x28) {
            // EOI an Slave-PIC
            outb(0xa0, 0x20);
}else if(cpu->intr==0x21){kbc_handler(0x21);}
else if(cpu->intr==0x20){timer_handler(&new_cpu);}
// EOI an Master-PIC
outb(0x20, 0x20);
return new_cpu;
}
timer.c
#include<stdint.h>
#include<cpustate.h>
#include<ts.h>
#include<stdbool.h>
#include"timer.h"

//extern bool mtenabled;

void timer_handler(cpu_state* new_cpu){
    time++;
    if(mtenabled){
new_cpu=schedule(new_cpu);
    }
}
timer.h:
#ifndef TIMER_H
#define TIMER_H

#include<stdint.h>
#include<cpustate.h>

extern bool mtenabled;
uint32_t time=0;
void timer_handler(cpu_state* new_cpu);

#endif
ts.c:
#include <cpustate.h>
#include <stdint.h>
#include <stdbool.h>
#include "ts.h"

static int current_task = -1;
static int num_tasks=0;
static task tasks[MAX_CPUSTATE];

/*
 * Jeder Task braucht seinen eigenen Stack, auf dem er beliebig arbeiten kann,
 * ohne dass ihm andere Tasks Dinge ueberschreiben. Ausserdem braucht ein Task
 * einen Einsprungspunkt.
 */
task* init_task(void* entry)
{
    if(!mtenabled){
mtenabled=TRUE;
    }
    /*
     * CPU-Zustand fuer den neuen Task festlegen
     */
    cpu_state new_state = {
        .eax = 0,
        .ebx = 0,
        .ecx = 0,
        .edx = 0,
        .esi = 0,
        .edi = 0,
        .ebp = 0,
        //.esp = unbenutzt (kein Ring-Wechsel)
        .eip = (uint32_t) entry,
 
        /* Ring-0-Segmentregister */
        .cs  = 0x08,
        //.ss  = unbenutzt (kein Ring-Wechsel)
 
        /* IRQs einschalten (IF = 1) */
        .eflags = 0x202,
    };
    /*
     * Stack erstellen
     */
    uint8_t new_stack[STDRD_STACKSIZE];
    /*
     * Den angelegten CPU-Zustand auf den Stack des Tasks kopieren, damit es am
     * Ende so aussieht als waere der Task durch einen Interrupt unterbrochen
     * worden. So kann man dem Interrupthandler den neuen Task unterschieben
     * und er stellt einfach den neuen Prozessorzustand "wieder her".
     */
    cpu_state* state = (void*) (&new_stack + STDRD_STACKSIZE - sizeof(new_state));
    *state = new_state;
   
    num_tasks++;
    /*
     * neuen Task struct erstellen, in die Liste eintragen und zurückgeben
     */
    task new_task ={state,new_stack,num_tasks};
    tasks[num_tasks]=new_task;
 
    return &new_task;
}
/*
 * Gibt den Prozessorzustand des naechsten Tasks zurueck. Der aktuelle
 * Prozessorzustand wird als Parameter uebergeben und gespeichert, damit er
 * beim naechsten Aufruf des Tasks wiederhergestellt werden kann
 */
cpu_state* schedule(cpu_state* cpu)
{
    /*
     * Wenn schon ein Task laeuft, Zustand sichern. Wenn nicht, springen wir
     * gerade zum ersten Mal in einen Task. Diesen Prozessorzustand brauchen
     * wir spaeter nicht wieder.
     */
    if (current_task >= 0) {
        tasks[current_task].state = cpu;
    }
    /*
    * Naechsten Task auswaehlen. Wenn alle durch sind, geht es von vorne los
    */
    current_task++;
    current_task %= num_tasks;

    /* Prozessorzustand des neuen Tasks aktivieren */
    cpu = tasks[current_task].state;

    return cpu;
}
ts.h
#ifndef TS_H
#define TS_H

#include<stdint.h>
#include<cpustate.h>
#include <stdbool.h>

#define STDRD_STACKSIZE 4096 //Stack größe bei der Initialisierung
#define MAX_CPUSTATE 32 // Maximal zahl an Tasks noch keine malloc() funktion implementiert

bool mtenabled=FALSE;

typedef struct {
    cpu_state *state;
    uint8_t stack_a[STDRD_STACKSIZE];
    uint32_t pid;
} task;
task* init_task(void* entry);
cpu_state* schedule(cpu_state* cpu);
#endif
Vielen Dank für die Hilfe
125
Offtopic / Re: Weihnachten!
« am: 23. December 2012, 22:22 »
Hallo,
ich wünsch euch auch ein ganz frohes Fest

[Beiträge zähler erhöh!] 8-)
126
Softwareentwicklung / Re: Pixel ansteuern im Long Mode
« am: 23. December 2012, 00:32 »
Moin,
Es gibt da doch sowas, dass man in RM oder V86 in den Grafikmodus schaltet und später einfach weiter in den Buffer schreibt. Das geht dann ohne Performance Verlust. Hier wären mal bisschen Infos gut. Linux and FreeBSD machen das auch
127
Offtopic / Re: Prozessorcaching was muss/kann man selber machen?
« am: 22. December 2012, 18:03 »
vielen Dank
128
Offtopic / Re: Prozessorcaching was muss/kann man selber machen?
« am: 22. December 2012, 17:23 »
Ich meinte wie die CPU den Überblick behält was im Cache liegt und darauf zugreift, oder wann etw wo gecacht wird.

Aber jetzt wo sich rausstellt, dass ich da eh nichts machen muss interressierts mich nicht mehr so, es sei den SMP Support zählt zu dem "etwas speziellen"
129
Offtopic / Prozessorcaching was muss/kann man selber machen?
« am: 22. December 2012, 16:28 »
http://de.wikipedia.org/wiki/L3-Cache#Prozessor-Cache Caching ist ja ne super Sache um RAM Zugriffe zu beschleunigen.

Ich hab da einige Fragen:

1. Wie geht das (da steht auch was in Intels Prozessor Docs V. 3, K.11 ist mir aber viel zu ausführlich)

2. Vor allem: Was muss/kann man selber implementieren. Ich habe gehört auf SMPs soll das etwas komplizierter sein.

PS: kann das jmd in ein on-topic board verschieben
131
Lowlevel-Coding / Re: Über Zeiger auf nächste Variable zugreifen
« am: 16. December 2012, 23:09 »
Das mit den optimierungen ist mir bekannt(das ablegen Auf dem stack kann man aber auch mit auto short var1 erzwingen oder mit gcc -O0 )

Das mit der pointer arithmetik versteh ich nicht :( hilf bitte
132
Hier ist meine Makefile
SRCS = $(shell find -name '*.[cS]')
OBJS = $(addsuffix .o,$(basename $(SRCS)))

CC = gcc
LD = ld

ASFLAGS = -m32
CFLAGS = -m32 -Wall -g -fno-stack-protector -I inc -std=c99
LDFLAGS = -melf_i386 -Tkernel.ld
kernel: $(OBJS)
$(LD) $(LDFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $^

%.o: %.S
$(CC) $(ASFLAGS) -c -o $@ $^

clean:
rm $(OBJS)

.PHONY: clean
133
Lowlevel-Coding / Re: Über Zeiger auf nächste Variable zugreifen
« am: 16. December 2012, 15:52 »
Also lokale Variablen werden ja auf dem Stack gespeichert. Weil der Stack ja nach unten in Richtung niedriger Speicheradressen wächst(http://de.wikipedia.org/wiki/Stapelspeicher Absatz Mikroprozessoren), zeigt dein Pointer auf den Anfang des Heaps des Programms.
Probier mal long *_var2 = (&var1-2);(ein short ist ja zwei Bytes groß)
134
als ich mein OS kompilieren wollt kam:


console.c:84:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
console.c:84:5: note: use option -std=c99 or -std=gnu99 to compile your code

als ich die params dann in der Makefile hatte, hat gcc sie nicht erkannt
ups falsches board
135
Offtopic / Re: Screen of Death
« am: 14. December 2012, 23:38 »
https://code.google.com/p/lf-os/source/browse/trunk/interrupt.c?r=11
 :-D das erinnert mich an meine anfangszeit mit Python;

50 mal hintereinander gleiche Funktion mit 1, 2 verschiedenen Parametern aufrufen.

Gibz vllt auch Schleifen und Listen?

Nö noch nicht
136
Offtopic / Re: Entwickungsumgebungen
« am: 10. December 2012, 19:10 »
Frag mal bei Java-Programmierern nach, da kriegst du ein völlig anderes Bild.
Ich weiß ich bin ja auch einer; die nutzen (fast(Netbeans)) alle Eclipse.
137
Offtopic / Re: Entwickungsumgebungen
« am: 10. December 2012, 18:31 »
Das es so klar ist hätte ich nicht gedacht ^^
138
Offtopic / Entwickungsumgebungen
« am: 09. December 2012, 20:37 »
Ich probiere zurzeit aus nur mit Terminal zu deven.
Machn des viele?
139
Softwareentwicklung / Re: Linux Cross Compiling - Win32
« am: 08. December 2012, 20:46 »
PE steht wohl für http://de.wikipedia.org/wiki/Portable_Executable und wenn mingw32 für Linux das net kennt dann wird das dort wohl auch nicht unterstützt in der Mingw Portierung):
oder du hast irgendein Softwarepaket zu installieren vergessen
140
Offtopic / A Guide to Kernel Exploitation, Attacking the Core
« am: 08. December 2012, 20:23 »
https://play.google.com/store/books/details/Enrico_Perla_A_Guide_to_Kernel_Exploitation?id=G6Zeh_XSOqUC#?t=W251bGwsMSwyLDUwMSwiYm9vay1HNlplaF9YU09xVUMiXQ..Sehr interresantes Buch wollt ich nur sagen.
Ich habe ja selber in OS-Dev nur reingeschnüffelt aber viel was ich dabei kennen gelernt habe hilft mir jetzt sehr weiter(z.b RaceConditions oder alle Speicherschutzmechanismenw wie Paging oder Segmentation)
Kennt sich hier jemand damit aus?
Eig könnte man dafür ja auch ein Board machen, könnt ja auch für Kernel Devs interessant sein das eigene OS zu hacken.
Was man damit z.B machen könnte wenn man gut wär Root app für android(http://forum.xda-developers.com/showthread.php?t=2013194)
Die Schwierigkeit ist dabei glaube ich weniger das Linux(das alle Unixoide Kernel viel sicherer als alle anderen sind halt ich für ein gerücht) sondern die ARM Architektur.
PS: Ihr dürft auch was dazu sagen;)
Seiten: 1 ... 5 6 [7] 8 9

Einloggen