Cyjon OS

Odpowiedz Nowy wątek
2015-04-10 20:41
51

Programowanie może być ciekawe.

W pełni 64 bitowe jądro systemu jak i oprogramowanie oraz system plików.
W języku asemblera.

Wszystkie programy pisane własnoręcznie, nie są przenoszone z systemów GNU/Linux (tylko na nich wzorowane - wizualnie :)).

user image

Edytor tekstu "nano":

user image

Aby daleko nie szukać, poniżej paczka z obrazem systemu.

Aktualizacja 21.12.2015:

user image

Aktualizacja 3.1.2016:

user image
user image

Aktualizacja 5.1.2016:
Wykonałem trochę modyfikacji i teraz działa znacznie lepiej (znalazłem parę błędów) jak i się prezentuje.

user image

Aktualizacja 27.05.2016:
Obsługa protokołu ARP, IP i ICMP !

user image

Aktualizacja 11.06.2016:

Udało mi się nawiązać połączenie przez przeglądarkę, "stos" tcp/ip przyjmuje tylko jedno połączenie ;)
Teraz muszę wysłać dane do serwera httpd wraz z identyfikatorem połączenia.
Serwer wyśle odpowiedź do klienta(przeglądarka) i demon_tcp zakończy połączenie, oczekując na następne xD
user image

Aktualizacja 30.06.2016:

Udało się, mam serwer WWW, stos TCP/IP i system operacyjny... a wszystko w asemberze :D
user image

Aktualizacja 28.12.2016:

Niewiele zmieniło się z zew. punktu widzenia, ale pod maską jest już pełna obsługa wirtualnych konsol!
Powłoka otrzymała możliwość buszowania po systemie plików (w tym i każdy inny proces).
title

Aktualizacja 15.01.2017:

title
title
title

Aktualizacja 20.02.2017:

title

Aktualizacja 22.02.2017:

Aktualizacja 21.03.2017:

title

Aktualizacja 23.03.2017:

Aktualizacja 02.07.2017:

title

Aktualizacja 25.08.2017:

title


edytowany 19x, ostatnio: akasei, 2017-08-25 14:39
Unikałbym stosowania istniejących nazw własnych programów. Tak tylko piszę. Ogólnie bardzo fajnie. :) - Tacet 2015-04-11 00:24
Tak, zgadzam się... dopóki się z tym nie panoszę na lewo i prawo, mogę je stosować. Nazwy te zastosowałem by osoby postronne szybko się odnalazły. - akasei 2015-04-11 00:34
Powoli przepisuję "uproszczony" kod jądra systemu do GitHub, dodając masę komentarzy. - akasei 2015-04-11 18:00
Plik system.zip powyżej, nieaktualny. Najnowszą wersję zawsze można pobrać z GitHub. - akasei 2015-12-21 07:15
GitHub nieaktualny, najnowszej wersji nie można nigdzie pobrać. Do czasu otrzymania satysfakcjonującego kodu. - akasei 2017-08-25 14:34

Pozostało 580 znaków

2015-06-10 08:32
4

Nie oszukujmy się - poziom dla zdecydowanej większości tutaj nieosiągalny. :)

Pozostało 580 znaków

2015-06-21 02:49
1

Próby z obsługą trybu graficznego (framebuffer).
Niestety nie mogę znaleźć w specyfikacji VESA (VBE 2.0, 3.0) obsługi trybów 16:9

user image
user image

Aktualizacja: 20:05
user image


edytowany 1x, ostatnio: akasei, 2015-06-21 20:06
Ups, to jest rozdzielczość 320x200x24bpp - akasei 2015-06-21 03:13

Pozostało 580 znaków

2015-06-21 08:38
1

Ta strona może się przydać: http://wiki.osdev.org/Getting_VBE_Mode_Info
Zależnie od tego co masz za sprzęt możliwe, że musisz stosować "haki" w rodzaju tego: http://915resolution.mango-lang.org/

Od wszelkich "haków" staram się trzymać z daleka :) Sprawdziłem datę ostatniej specyfikacji VBE (16 września 1998), chyba nie napiszą nowej. - akasei 2015-06-21 11:23
Tak, zdaję sobie sprawę z innych trybów karty graficznej, które nie są opisane w specyfikacji - a procedura 0x4F00 z przerwania 0x10 BIOSu je wykazała. - akasei 2015-06-21 11:28
@akasei: gdzieś czytałem że w którejś wersji zrezygnowano z definiowania nowych rozdzielczości w standardzie, karta ma po prostu zgłaszać listę tego co obsługuje. - Azarien 2016-05-24 14:53
@Azarien: brzmi dobrze. - akasei 2016-05-24 17:51

Pozostało 580 znaków

2015-07-06 01:39
4

Nie przestaję... :)

Rozdzielczość 320x200x32bpp, czcionka Sinclair (zdobycz od http://flabra.mine.nu/).

user image

Idzie ciężko, gdyż Qemu i VirtualBox nie posiadają debugera z prawdziwego zdarzenia, a Bochs nie wspiera kontrolera SATA.


Ty się módl żeby Xix tego tematu nie zobaczył bo ci nie da spokoju :P - Shalom 2015-07-06 08:53
Chyba to już czytałem, ale temat nie był tak "rozbudowamy" :) Najbardziej rozśmieszył mnie ostatni post @azalut "ostatnio doszło mi sprawdzenie czy @Xix nie dodał nowego posta," :D - akasei 2015-07-06 09:51

Pozostało 580 znaków

2015-07-06 09:27
0
akasei napisał(a):

Qemu i VirtualBox nie posiadają debugera z prawdziwego zdarzenia
Do Qemu możesz podpiąć GDB (http://wiki.osdev.org/Qemu#GDB-stub). IMHO to bardzo wygodne rozwiązanie, lepsze niż w Bochs.

Pozostało 580 znaków

2015-07-06 10:07
0
lukasz1235 napisał(a):
akasei napisał(a):

Qemu i VirtualBox nie posiadają debugera z prawdziwego zdarzenia
Do Qemu możesz podpiąć GDB (http://wiki.osdev.org/Qemu#GDB-stub). IMHO to bardzo wygodne rozwiązanie, lepsze niż w Bochs.

Do GDB mam mieszane uczucia, przykład:
Uruchamiam Qemu z parametrami "-s -S"
To jest mój plik .gdbinit

set arch i386:x86-64
target remote :1234
break *0x100147
set disassembly-flavor intel
continue

Uruchamiam GDB i co się okazuje:

GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
0x0000fff0 in ?? ()
Breakpoint 1 at 0x100147
/root/.gdbinit:4: Error in sourced command file:
Remote 'g' packet reply is too long: 0000000000000000a08f12000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000047011000000000004600000008000000100000001000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000
(gdb)

Podobno popularny błąd przy debugowaniu binarek, którego rozwiązania nie idzie znaleźć...
Zdawało mi się, że mogę to zignorować i po prostu debugować dalej, więc wyświetliłem TUI dla rejestrów i disas.

┌──Register group: general────────────────────────────────────────────────┐
│eax            0x0      0           ecx            0x0      0            │
│edx            0x663    1635        ebx            0x0      0            │
│esp            0x0      0x0         ebp            0x0      0x0          │
│esi            0x0      0           edi            0x0      0            │
│eip            0xfff0   0xfff0      eflags         0x2      [ ]          │
│cs             0xf000   61440       ss             0x0      0            │
│ds             0x0      0           es             0x0      0            │
│fs             0x0      0           gs             0x0      0            │
│                                                                         │
│                                                                         │
│                                                                         │
   ───────────────────────────────────────────────────────────────────────┘
  >│0xfff0  add    BYTE PTR [eax],al                                      │
   │0xfff2  add    BYTE PTR [eax],al                                      │
   │0xfff4  add    BYTE PTR [eax],al                                      │
   │0xfff6  add    BYTE PTR [eax],al                                      │
   │0xfff8  add    BYTE PTR [eax],al                                      │
   │0xfffa  add    BYTE PTR [eax],al                                      │
   │0xfffc  add    BYTE PTR [eax],al                                      │
   │0xfffe  add    BYTE PTR [eax],al                                      │
   │0x10000 add    BYTE PTR [eax],al                                      │
   │0x10002 add    BYTE PTR [eax],al                                      │
   │0x10004 add    BYTE PTR [eax],al                                      │
   └──────────────────────────────────────────────────────────────────────┘
remote Thread 1 In:                                       L??   PC: 0xfff0 
000000000460000000800000010000000100000001000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
7f0300000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000801f0000
(gdb)

GDB nawet nie ruszył z miejsca. Sprawdzam co za "kura" zatrzymała mój kod.

(gdb) info threads
  Id   Target Id         Frame
  8    Thread 8 (CPU#7 [halted ]) (running)
  7    Thread 7 (CPU#6 [halted ]) (running)
  6    Thread 6 (CPU#5 [halted ]) (running)
  5    Thread 5 (CPU#4 [halted ]) (running)
  4    Thread 4 (CPU#3 [halted ]) (running)
  3    Thread 3 (CPU#2 [halted ]) (running)
  2    Thread 2 (CPU#1 [halted ]) (running)
* 1    Thread 1 (CPU#0 [running]) (running)
(gdb)

Sprawdzałem nawet nakładki do GDB, typu DDD... zawiesza się.

Dalej dałem sobie siana, i zostałem przy Bochs Enhanced Debugger.


Pokaż pozostałe 6 komentarzy
@Proxima, znalazłem zbędną linię tak zgrubsza, pierwsza przed etykietą ".ok" Między innymi dlatego nie mam zamiaru upubliczniać kodu. Ludzie zaczną wytykać rzeczy, które wiem (i nie ma sensu tego tłumaczyć) - tylko nie mam czasu teraz się tym zająć :) - akasei 2015-07-06 12:12
Faktycznie, mov jest nie potrzebny, ale imo takie błedy-niebłędy, to nie są jakieś krytyczne rzeczy. Co do wytykania błędów to jest ok bo można czegoś się nauczyć, ale jak wiesz że one są, może po prostu spisz je na liście, gdzieś w komentach w danym pliku (w stylu nie-mam-na-to-czasu-chcesz-to-pomóż-naprawić). - Proxima 2015-07-06 12:18
@Proxima, masz jeszcze kod ostatniej wywoływanej procedury :) http://paste.wataha.net/6X - akasei 2015-07-06 12:21
@Proxima: Możesz już przeglądać kod źródłowy systemu Cyjon OS, w tydzień uporam się z przepisaniem do końca :) https://github.com/akasei/Cyjon - akasei 2015-08-19 09:50
Najs, thx za wrzute. Z pewnością przejrze przy herbatce bo z tego co widziałem jest sporo komentów, to sie elegancko czyta. - Proxima 2015-08-19 19:34

Pozostało 580 znaków

2015-07-06 10:13
0

Zapewne próbujesz debugować binarkę 64-bitową. Faktycznie GDB ma z tym problem, ale istnieje patch (na wersję 7.1, nie wiem czy pasuje do nowszych): http://4programmers.net/Pastebin/4225. Widocznie ciągle tego nie naprawili...

Pokaż pozostałe 3 komentarze
Dlaczego zmieniałeś linię 674? Patch tego nie ruszał. - lukasz1235 2015-07-06 12:36
No rozumiem, ale chodziło mi o to, żebyś wziął ten kod który ręcznie poprawiałeś i zostawił tą linijkę w oryginalnej postaci tzn. rsa-&gt;sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa-&gt;regs);. A resztę poprawiłeś chyba dobrze. - lukasz1235 2015-07-06 12:43
@lukasz1235, ha ha - pobrałem najnowszą paczke, nałożyłem PATCHa, zignorowałem błąd, skompilowałem -- działa. Kto by się spodziewał :) Teraz czas na testy. Brak błędów, ładnie zatrzymało się na ustalonym EIP. Tylko podgląd instrukcji znikł "no asembly available" (rejestry widać). Teraz musze się nauczyć poprawnej obsługi GDB dla binarek (jestem zielony z tym debugerem). Zatrzymanie wykonywania kodu na 0x7c00 jest prawidłowe i wszystko ładnie widać (coś mi się zdaje, że to problem z 64 bitami). - akasei 2015-07-06 12:56
Tak, tracę dostęp do podglądu instrukcji już w GRUBie (jeszcze mój kod nie zaczął się wykonywać). Można kontynuuować, nie można wykonywać instrukcji po instrukcji. Dobra, ide pisać doktorat. - akasei 2015-07-06 13:17

Pozostało 580 znaków

2015-07-06 15:34
Xix
0

Nic z tego nie rozumiem ale kupie sobie książkę o asm. Na początek dystrybucja Linuxa. Ale czy to co tu jest to jądro czy też dystrybucja Linuxa ?

2015-07-13 18:01
6

Wyeliminowałem większość błędów po przejściu na tryb graficzny, za pozostałe znalezione z góry dziękuję.

user image

Proszę bardzo do testowania, przedstawiam dwa dyski twarde:
Qemu, Bochs: hda.zip (GRUB potrafi uruchamiać się wraz z jądrem do 15 sek.)
VBox: disk.zip

Dysk SATA w Qemu podłączamy w następujący sposób (Bochs nie obsługuje dysków SATA):

qemu-system-x86_64 -drive id=disk,file=hda.img,if=none -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0
W tym wydaniu jest już programowy kursor! :D

Próba zlokalizowania karty sieciowej e1000 i pobranie jej adresu MAC:

user image

Na tym zaprzestanę. Muszę skupić się na obsłudze dysków i systemów plików, aby za pomocą panelu sterowania móc zapisywać konfiguracje systemu np.: nazwa jednostki (localhost), strefa czasowa itp.

  • disk.zip (5,45 MB) - ściągnięć: 33
  • hda.zip (5,45 MB) - ściągnięć: 36

edytowany 11x, ostatnio: akasei, 2015-07-15 01:50
tak, uptime działa na sterydach, zapomniałem wyłączyć debugera :) (sprawdzałem nim poprawność wyświetleń przy różnych wartościach) - akasei 2015-07-13 18:24

Pozostało 580 znaków

2015-08-08 09:17
1

Gdyby ktoś był zainteresowany to mam w pełni działający patch do gdb 7.9.1:

--- remote-o.c  2015-05-13 19:36:05.000000000 +0200
+++ remote.c    2015-08-08 09:12:42.590407476 +0200
@@ -6154,8 +6154,25 @@
   buf_len = strlen (rs->buf);
 
   /* Further sanity checks, with knowledge of the architecture.  */
-  if (buf_len > 2 * rsa->sizeof_g_packet)
-    error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
+  //if (buf_len > 2 * rsa->sizeof_g_packet)
+  //  error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
+  // Parche implementado para solucionar el problem de reply too long
+  // by Matias Vara 
+  if (buf_len > 2 * rsa->sizeof_g_packet) {
+
+       rsa->sizeof_g_packet = buf_len ;
+
+      for (i = 0; i < gdbarch_num_regs (gdbarch); i++)
+   {
+     if (rsa->regs[i].pnum == -1)
+       continue;
+
+     if (rsa->regs[i].offset >= rsa->sizeof_g_packet)
+       rsa->regs[i].in_g_packet = 0;
+     else
+       rsa->regs[i].in_g_packet = 1;
+   }
+  }
 
   /* Save the size of the packet sent to us by the target.  It is used
      as a heuristic when determining the max size of packets that the
@@ -6167,6 +6184,7 @@
      update our records.  A 'g' reply that doesn't include a register's
      value implies either that the register is not available, or that
      the 'p' packet must be used.  */
+  // Tenemos un serio problema aqui al entrar en real mode me cambia el tamaño de los registros 
   if (buf_len < 2 * rsa->sizeof_g_packet)
     {
       rsa->sizeof_g_packet = buf_len / 2;
A ten patch co poprawia? - vpiotr 2015-08-08 11:11
OK, tnx. Widzę, że proces zgłaszania błędów w GDB jest nadal w latach 90-tych... (lista mailingowa). - vpiotr 2015-08-08 11:29
@lukasz1235: Przyda się :) - akasei 2015-08-08 15:49
@vpiotr: a propos lat 90-tych, całkiem niedawno naprawiono w GDB debugowanie pod DOS-em (było zepsute od kilku wersji) - Azarien 2015-08-10 22:50
@lukasz1235: łatka działa sprawnie :) - akasei 2017-03-13 14:27

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0