Pull to refresh

Comments 49

UFO just landed and posted this here
А Вы бы не могли уточнить особенности написания бутлодера для мобильных устройств (ARM)… хм… ну возможно в следующей статье… если можно?
Написанием ОС для ARM не занимался, но ковырял бутлодер смартфона. Чуть больше наберу информации — напишу. Да и вроде недавно была статья про армы
там все зависит от SoC, на котором будет бутаться и который нужно инициализировать — в арме начальный бут выполняет роль биоса.

соответственно «прерывание» для печати текста на экран там нет и все делается ручками через прямую работу с фреймбуфером.

а дальше уже просто — считал из NOR ядро, записал в RAM и пнул на него управление, делов-то.
да, закат солнца вручную :)
Качаете WinCE Platform Builder, устанавливаете, внимательно рассматриваете исходники ядра и примеры лоадеров.
Я как то в юности далёкой, делал подобное, хотел научится запускать exe файлы и ОС на Pascal-e написать. Наивный глупый мальчик.
Более того, «наивные мальчики» до сиз пор пишут пускалки exe файлов, правда не на Pascal. :)

winehq.org
Я сказал про Паскаль, не было слов Free или Object.
Помним помним. Курсовая по ассемблеру. Записать на дискету снимок экрана. Ой как я наматерился мучая этот FAT12
без DOS'a? Если без, то таки надо мучать фат, но тогда надо вообще много чего мучать и фат не самое страшное… А если из DOS-а, то фат мучать не надо, ибо INT 21h появляется, который все эти вопросы решает.
а чего там кроме фата мучать? читаем 80х25х2 байтов с 0xB800 (вроде там видеопамять начинается) и скидываем в файл
ну, собственно, загрузчик. Ну и какое-то действие после загрузки. Как я себе представляю задача не совсем в том, чтоб вставить диск, перегрузиться и на выходе получить копию экрана в файле.
Кстати, во-первых 0xB8000, во-вторых зависит от видео-режима и видео-адаптера.
посыпаю голову пеплом.
Да, DOS, но по заданию нужно было именно мучать FAT, просто не имея понятия что вообще такое FAT12 (а о том что это вообще FAT12 я узнал на второй день издевательств над кодом) разбирать таблицу размещения файлов, писать в неё цепочки, помнится очень долго мучался из-за необходимости разбивать данные на 2 куска если они проходили по границе сектора (кластера?) и весь этот Turbo Assembler после ставшего родным С++ — ужас и страх =) Считать смещения, прыгать по кластерам, думать а если он битый? А если что-нибудь куда-нибудь не туда записал? А как быть с остальными файлами на дискете?

Собственно про загрузчик там не было ни слова, но именно оттуда я узнал (похоже уже порядком забыл) Как оно работает изнутри и по какому смещению можно писать таинственный загрузчик :)
UFO just landed and posted this here
в инете полно этих статей про бутлоадеры, пошли бы дальше чтоли.
я бы написал про мини-операционку на асме (писал курсовик год назад, ок. 2000 строк), но не хватает кое-чего важного
ну так никто не просит писать статьи с исходниками целой оськи.
Пишите о том, что сами уже сделали, и можете показать
кармы нехватает :) естественно все 2000 строк я не стану в статью пихать, только ключевые моменты
UFO just landed and posted this here
Эээм… это ж вроде обращение Линуса, не?
UFO just landed and posted this here
Ну сколько можно переписывать один и тот же «бутлодер с FAT-дискеты»?
хоть бы раз кто-нибудь осветил загрузку с hdd, cd, usb flash — нет, вссе переписывают одно и то же про дискеты, которые практически ушли в прошлое.
UFO just landed and posted this here
нет, флеш работает ни с каким не с образом, а просто как винчестер или дискета, в зависимости от того, как отформатирована.
ax, dx… из какого века эта статья? На дворе давно 64-битные системы, а мы работаем с 16-битными регистрами.
Это не ко мне — не я заставил intel в свое время делать велосипед, при переходе от 16битного режима, к 32-битному. Собственно костыли и сейчас есть т.к. тот же 64 битный камень (не берем itanium, у них своя архитектура) сначала передает управление коду после загрузки в 16-битном режиме с доступом к 1 метру памяти. При переходе в защищенный уже получаешь все прелести процессора.
UFO just landed and posted this here
А давайте не так. Давайте знаете как, вот программа — примерно нужно посчитать 5+3-2. Ну такого плана значения. И тут конечно мы будет использовать только 128-битные SSE регистры (зачем нам 64-бит? маловато же, когда есть целочисленные xmm 128-битные!), при этом каждая команда пересылки в регистр у нас будет байт по 14+ (щаз лень смотреть, но вряд-ли меньше). Ну а чего, кеш-то уже большой, памяти тоже можно сразу по 16 байт отдавать для чисел типа 1..5, все равно ее много. Зато смотрите, модно, 128-ми разрядно и даже RISC как он есть.
PS: Не ведитесь на маркетинг, 64 бита нужно очень редко, фактически для десктопных задач не нужны.
PSS: Единственный плюс в x64 наборе команд — добавление 8 новых регистров общего назначения, которых от интеля ждали еще в 79-80 году. Свершилась батюшки, не прошло и 40 лет.
Если бы все были такими, как вы, 640 килобайт было бы достаточно каждому.

Слава Б-гу, что не все такие.
А что собственно плохого в том, чтобы использовать столько ресурсов, сколько необходимо, а не столько, сколько есть? )
Ты, наверное, тратишь столько же, сколько и зарабатываешь, да?
Я просто знаю о чем говорю, а вы судя по всему — нет. Поясню: MMX появилось в ~92 году и включало в себя восемь 64 битных регистров, с которыми можно было работать как с упакованными данными (байты/слова/двойные слова), так и с не упакованными данными — четверные слова. Итого, если кому-то ВНЕЗАПНО приспичивало все-таки считать числа навроде от 0 до 18 446 744 073 709 551 615, то это можно было сделать быстро, не используя эмуляцию 64-битного числа через два 32-битных регистра. Теперь припомните пожалуйста, в какой программе вы последней раз видели вышеупомянутое число (можно уменьшить на десяток миллиардов если от этого станет легче)? Может кол-во жизней в контре или такой бюджет считаете в экзеле или у вас столько свободного места на диске? Я ни разу такого в десктоп-приложениях не видел. А теперь давайте вспоминать, когда вы сами использовали в своей программе uint64 или int64? Ну хорошо, допустим даже и использовали, но скорее всего один-два раза в некритичном участке, когда в обычный int просто не влезал результат умножения на большое число. Тем не менее, никто вас аж с 92 года не ограничивал в возможности использовать для этого ассемблерную вставку с использованием MMX для быстрого перемножения 64-битных чисел. Всем все было доступно, манов в инете тонны. Однако ни кто из программистов этим не заморачивался и все использовали встроенную в компилятор эмуляцию через 32-битные регистры. Возможно потому, что как говорилось выше, такого рода числа в любой десктоп-программе встречаются не более 1%.
С приходом к нам на десктопы x64 фактически ничего не изменилось аж с 92 года для написания программ. То, что раньше программы могли оперировать с 64-битными регистрами через MMX сейчас доступно как для обычных регистров. Единственное поменяли в очередной раз модель памяти и теперь мы имеем доступ к более 4Гб. Как я уже говорил раньше, добавились 8 новых регистров общего назначения, и то стараниями AMD. Но момент упущен, добавь бы они их раньше, скажем с приходом 386 процессора, была бы бомба. Сейчас же все компиляторы придрачились использовать 1-2 регистра для элементарных операций, и переход я чувствую будет медленным к освоению 8 новых регистров вместо 1-2, так как нужно будет менять оптимизацию в корне.
UFO just landed and posted this here
UFO just landed and posted this here
Всё хорошо, но наш загрузчик может оказаться и на FAT16, и на FAT32-устройстве, формат цепочки кластеров в каждом случае свой.
Лучше прочитать сначала спецификацию FAT:
www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
Там много интересного.

Что касается размещения основного кода загрузчика в файле, в DOS применялось совершенно гениальное решение: у них файл IO.SYS начинался всегда с одного и того же, заранее известного номера сектора.
Sign up to leave a comment.

Articles