Beiträge von klemmi

    Hey, Jungs,

    die im IRC hab ich jetzt lang genug genervt mit meinem mangelnden Grundwissen:

    Was ich gerade versuche ist ein system für meinen Grasshopper selbst zu bauen.
    Hardware:
    Embedded Projects

    Da drauf läuft ein U-Boot.

    Ich habe mir einen crosscompiler gebaut und damit dann einen Kernel kompiliert. Der stirbt allerdings recht schnell.

    Private Paste - Pastie

    Spoiler anzeigen

    Das Problem ist, dass ich zu dumm bin, die Kernel-Meldungen zu interpretieren. MMU - ist klar, aber wüsste jetzt nicht, an welcher Schraube ich stellen müsste.
    Auch verstehe ich den Entry Point nicht. Mein RAM liegt bei 10 00 00 00 und ist 64mB groß. Sprich 0x 4 00 00 00, müsste also bei 14 00 00 00 zuende sein. Das heißt ein Entry Pint bei 90 00 00 00 existiert ja gar nicht. Aber der Kernel setzt das automatisch in die Kconfig rein und mkimage übernimmt das dann und acuh im ursprünglichen (oben verlinkten) System war der EP 90 00 00 00.

    Kernel .config:

    Spoiler anzeigen
    Zitat von klemmi

    Wenn das noch weit genug rausguckt, kannst du auch versuchen ne Feile zu nehmen und einen "Schlitz" für den Schraubendreher da einzufeilen.
    Ansonsten nur Öl und Zange, falls das noch geht.
    Sonst wirds ohne Bohrer schwierig...

    Zitat von thosch97

    Ich würd auch vorschlagen da n Schlitz reinzufeilen und dann rausschrauben. Oder $bekannter fragen ob der son Bohrer hat.

    Manchmal glaub ich auch, ich rede mit der Wand oO

    Bei Alsa gibts da einen schalter. Schau dir das erstmal direkt im alsamixer an. Da hast du erstmal alle Einstellmöglichkeiten und nicht nur die, die die GUI dir bietet.

    Die Lautstärke von Front und Kopfhörer getrennt zu regeln, weiß ich nicht, ob das geht. Ist das überhaupt in Hardware implementiert?

    Zitat von oreissig


    jo, vollkommener humbug
    es gibt zwar prozessoren, die mehr daten auf einmal schaufeln, aber das sind typischerweise DSPs für multimediazeugs oder sowas
    64bit wird jedenfalls erstmal noch 20 jahre oder so halten. vermutlich kommt vorher eher ein gänzlich anderes konzept (quanten?) bevor der addressierbare speicher von 64bit ein problem sein wird

    Mit solchen Behauptungen wär ich in der Computerwelt vorsichtig... Auch wenn ich mir nicht vorstellen kann, dass es in den nächsten 15 Jahern nötig ist, da was zu ändern.

    Ich muss mal Commo aber sowas von zustimmen! Und wie ein Prozessor funktioniert habe ich auch erst mit 20 in einer Digitale Schaltungstechnik-Vorlesung gelernt. Vorher war mir das auch nicht so wirklich klar!

    Ein "Problem" ist vielleicht auch, dass die meisten hier wohl den ersten Kontakt mit dem PC über einen DOS-Prompt hatten. Ich sehe mich auch noch als 7-jähriger, der gerade richtig schreiben konnte, vorm REchner sitzen, die Kommandos vom Zettel abtippen um das Game meiner Wahl starten zu können.
    Dass ich dann irgendwann wissen wollte, was ich mit d:, cd und co tat, ist ja klar. Bei Windows 95 hätte ich einfach aufs entsprechende Icon geklickt und los gehts!
    Außerdem kamm man früher viel schwerer an Software. Internet gabs noch nicht und kaufen ist teuer! Und da man Nibbles (für die Jungen: eine Art Snake) auf QBasic vorfand hat man natürlich angefangen, mit der (damals tollen) Hilfe da selbst drin herumzubasteln!

    Ich finde es im Gegensatz zu Igor nicht schlecht oder falsch, dass MS suggeriert, dass ein PC einfach zu bedienen ist. Das ist ja auch richtig und gut so! Ich Will ja bei einer Mikrowelle auch nicht die Frequenz von Hand justieren, dass die im Resonator passt!

    Im Grunde kann ich Dirk uneingeschränkt zustimmen. Ich habe allerdinsg seit 3 JAhren auch ein ASRock-Board im täglichen Betrieb und das macht zuverlässig sein Ding, auch, wenn ich das manchmal ein wenig ärger!

    Ich weiß nicht, in wiefern die Schaltzeiten der Elektronik noch weiter runter gehen können beim Ram, denn ich galube, da liegt eher die Grenze für die Geschwindigkeit und nicht in der Größe.

    Zitat von DosAmp

    Siehe meinen Code-Schnippsel hierzu [...]
    Windows kann man zudem so konfigurieren, dass es Skripte beim Herunterfahren ausführen soll (und auch warten, bis die VM heruntergefahren ist).

    Jaja, klar war mir alles vorher schon bewusst! Im ersten Post habe ich ja auch so einen cmd-Schnipsel gepostet! Ein Skript beim Herunterfahren hätte den Nachteil, dass es für jede VM, die ich so steuern möchte, einen Statuscheck macht und dann ggf. die VM herunterfährt. Alternative zum Stauscheck wären krumme Config-Dateien, die beim Starten der VM angelegt werden und beim Herunterfahren der VM gelöscht werden. Das ist aber nicht wirklich schön, Fehleranfällig und umständlich einzurichten-

    Ich will auch keine Sammlung von Bausteinen. Wenn ich das nicht zusammenfasse, habe ich:

    • ein Skript zum hochfahren
    • ein Skript zum Status checken
    • ein Skript zum runterfahren
    • einen Windows-Job zum herunterfahren, der jedes Mal den Status erst abfragen muss.
    • Putty und die Hoffnung, die IP im Kopf zu haben

    Und das einmal für jede VM, die ich so steuern möchte.

    Und das ist doch ziemlich unkomfortabel!