The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Опубликована первая экспериментальная сборка Debian/Ubuntu для архитектуры ARM64

27.02.2013 21:21

Один из разработчиков проекта Debian, используя наработки компании ARM и консорциума Linaro, сформировал первую сборку Ubuntu 13.04 для 64-разрядной архитектуры ARM64 (ARMv8/AArch64). Процесс формирования сборки также обеспечен и для Debian Unstable. Так как первые процессоры с набором команд ARM64 ещё не поступили в продажу, оценить работу ARM64-сборки дистрибутива можно только с использованием эмулятора. Таким образом Debian и Ubuntu стали первыми операционными системами, поддерживающими работу на платформе ARM64. В разработке находится создание порта дистрибутива Fedora для ARM64, но работа ещё не достигла стадии подготовки загрузочного образа rootfs.

Для тестирования подготовлен загрузочный образ Rootfs, позволяющий загрузить ОС с использованием системы инициализации upstart для работы в консольном режиме. В 64-разрядной сборке также обеспечена возможность бесшовного запуска 32-разрядных приложений для архитектуры ARM-hf и сосуществования в одной системе 64- и 32-разрядных приложений. В сборке задействовано 140 пакетов, введён в строй репозиторий пакетов. Средства для кросс-компиляции и формирования сборок одновременно развиваются для Debian и Ubuntu Linux. Сборки могут быть сформированы как на основе Ubuntu 13.04, так и Debian Unstable.

Напомним, что поддержка ARM64 ранее была добавлена в состав ядра Linux 3.7, системной библиотеки Glibc 2.17 и экспериментальной ветки GCC. 64-разрядная архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON, такими как инструкции для ускорения работы алгоритмов шифрования AES и SHA-1/SHA-256.

  1. Главная ссылка к новости (https://lists.debian.org/debia...)
  2. OpenNews: Началась адаптация Fedora Linux для архитектуры ARMv8/AArch64
  3. OpenNews: Порт OpenJDK для архитектуры ARM64 и патчи для поддержки ARM в системе виртуализации KVM
  4. OpenNews: Релиз ядра Linux 3.7. Обзор новшеств
  5. OpenNews: Компания ARM представила патчи для ядра Linux с поддержкой 64-битной архитектуры ARMv8
  6. OpenNews: Релиз Linaro 13.01, включающий последние достижения по развитию Linux-решений для ARM-платформ
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/36244-arm
Ключевые слова: arm, arm64, aarch64, debian, linux
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (37) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Xasd (ok), 22:05, 27/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    в спецификации для AArch64 -- уже стандартизировали загрузку как через UEFI ?  (или всё ещё требуются костыли?)
     
     
  • 2.2, Аноним (-), 22:19, 27/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нафиг-нафиг такую "стандартизацию". Там к счастью MS'ом и интелем не все зохавано, так что к счастью PE EXE и их парсеров таки не будет. Что к лучшему.
     
     
  • 3.5, Xasd (ok), 22:26, 27/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а в чём притензии к UEFI? и почему его плохо на Arm ?

    не уж-то существуют интерфейсы более стандартизированные и расширяемые?

    # P.S.: только не упомянайте пожалуйста SecureBoot. не нужен тут этот холивар.. :)

     
     
  • 4.6, Аноним (-), 22:30, 27/02/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    в эпопеи вокруг ядра линукс и подписыванием pe стаба, читать в рассылке, линукс всем навешал
     
     
  • 5.7, Xasd (ok), 22:34, 27/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    зачем подписывать что-то?
     
     
  • 6.9, YetAnotherOnanym (ok), 23:12, 27/02/2013 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Бесполезно. UEFI и Secure Boot для них - тождественные понятия, как партия и Ленин,
     
     
  • 7.20, erera22 (ok), 14:15, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вопрос про UEFI давно перерос в годную тему для троллинга, нежели желание обсудить что-либо.
     
  • 4.23, ZloySergant (ok), 19:37, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В качестве моего стандартного троллинна:
    >а в чём притензии к UEFI? и почему его плохо на Arm ?

    Таки подлодки (U-boot) хватает для геморроя головного мозга. Нафига нам новые сущности?
    >На счет вышеуказанного PE EXE:

    http://www.2-spyware.com/file-pe-exe.html

     
  • 2.3, sasa (??), 22:21, 27/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в спецификации для AArch64 -- уже стандартизировали загрузку как через UEFI ?

    Кто о чем а вшивый о бане. Дайте-ка угадаю - вы пользуетесь дистрибутивом RH/MS ?

     
     
  • 3.8, Xasd (ok), 22:35, 27/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто о чем а вшивый о бане. Дайте-ка угадаю - вы пользуетесь
    > дистрибутивом RH/MS ?

    полигон для RH.

    тоесть почти угадал :)

     
  • 3.12, Crazy Alex (ok), 04:15, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да ладно, стандартизация загрузки (и работы с устройствами) там давно не помешала бы. А что ни устройство - своя фирмварь. Маразм.
     
  • 2.13, бедный буратино (ok), 07:58, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Когда деревья были большими, опции загрузки ядра записывали прямо в само ядро. Этот навык ещё не утерян? А уж подгрузить само ядро, вроде бы, проблем нет - подсовывай да ешь.

    initrd? А он нужен? И, вроде бы, initrd уже тоже научились прямо в ядро засовывать.

    Это детские болезни "игла - в яйце, яйцо - в ларце, а загрузчик в первых 512 байтах первого раздела первого диска, на котором надпись СОЛЬ" были свойствены другим ОС. А тут - вот ОС, вот знакомая ФС, вот ядро, загружай его по имени файла с носителя, без всяких бут-блоков и специальных установок загрузчиков. Красота?

    По мне, так и uboot только усложняет всё, из прозрачной схемы. Или я чего-то не понимаю?

     
     
  • 3.16, sasa (??), 10:41, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  тут - вот ОС, вот знакомая ФС, вот ядро, загружай его по имени файла с носителя, без
    > всяких бут-блоков и специальных установок загрузчиков. Красота?

    Не совсем - при такой схеме нужно встроенной SRAM метров 8-10 и стоить это будет недешево. На данный момент загрузка у всех SoC более-менее одинакова - начальный загрузчик считывается с внешнего носителя в IRAM (SRAM) и ему передается управление, он инициализирует контроллер внешней памяти и подгружает вторичный загрузчик во внешнюю память и передает ему управление или делает релокацию, вторичный загрузчик в свою очередь загружает ядро ФС с любого доступного носителя. В принципе можно расположить XIP ядро в параллельной NOR-флеш и сразу стартовать его, но оно тогда должно уметь настроить контроллер внешней памяти, поэтому часто там располагают загрузчик и пропускают первый этап в описанной схеме. Теперь замени слово загрузчик на BIOS и получишь то что было когда-то на PC.

     
     
  • 4.25, Аноним (-), 03:40, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Некоторые SoC имеют небольшой объем памяти на борту, чтобы была возможность записать туда загрузчик. А дальше уже дело самого загрузчика, как он понимает и управляет периферией на борту данного SoC. Хотите от загрузчика больше возможностей научите его это понимать.

     

  • 1.11, Аноним (-), 03:35, 28/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Касательно новости, то новость банальная, сейчас все дистрибутивы это делают.

    А вот касательно нового процессора тоже мало нового и интересного, хотя бы, потому что на данный момент уже существуют хорошие SoC которые многое умеют, но конечные устройства часто стоят столько же сколько стоит такое же устройство но на x86 процессоре. Что в свою очередь понижает интерес к устройствам на arm, и это даже несмотря на то что ARM64 планируется применять в сервером секторе.

     
     
  • 2.15, NikolayV81 (?), 09:31, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я так понимаю, что в серверах ARM 64 будут использовать как сейчас gpu ускорители в серверах ( по крайней мере интерес AMD был в этом ), только не для тяжелых вычислений а для виртуализации, т.е. сервер виртуализации x86 и сами машины на сотне другой армов воткнутых в слоты расширения, со своей памятью и возможно частью ввода вывода.

    А в обычных устройствах х64 даёт приемущество в памяти, можно будет делать видеоприставки, с большим объёмом оперативки, что позволит на них запусткать всякие JS операционки, ввиду их жадности до памяти, и ещё более упростит прцесс разработки софта ( сейчас тенденция к тому что проще и дешевле память и проц помощнее чем программиста поумнее ;) )

     
     
  • 3.18, Константавр (ok), 11:55, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают для того чтобы они могли вообще не отлаживать и не оптимизировать свой код. А в вэбе считают что мощности и пропускные способности увеличивают для того чтобы можно было больше рекламмы всунуть.
    Может они правы? Может мы вообще существуем для того чтобы есть всё что подают? Может скоро издадут закон по которому пассивные пользователи (не так часто покупающие новые компы и не кликающие по рекламме) будут преследоваться по закону?

     
     
  • 4.22, Аноним (-), 18:14, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают
    > для того чтобы они могли вообще не отлаживать и не оптимизировать
    > свой код. А в вэбе считают что мощности и пропускные способности
    > увеличивают для того чтобы можно было больше рекламмы всунуть.

    Не могу, не согласится, так как во времена, когда компьютеры были слабее все старались оптимизировать код для максимального быстродействия. А теперь недостатки проектирования кода, компенсируют дополнительные ресурсы железа, для обеспечения быстродействия.

     
     
  • 5.26, nn (??), 10:00, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Не могу, не согласится, так как во времена, когда компьютеры были слабее все старались оптимизировать код для максимального быстродействия.

    Сейчас тоже.

    >А теперь недостатки проектирования кода, компенсируют дополнительные ресурсы железа, для обеспечения быстродействия.

    Во всем нужна мера, если оптимизация стоит больше чем железо, то я выбираю железо.
    У реальных программистов (а не сферических в вакууме) есть дедлайны, у них нет в запасе пары лет на оптимизацию, им нужно показать работающий код точно в срок. Нет кода -- нет еды.  

     
     
  • 6.31, NikolayV81 (?), 10:27, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>Не могу, не согласится, так как во времена, когда компьютеры были слабее все старались оптимизировать код для максимального быстродействия.
    > Сейчас тоже.
    >>А теперь недостатки проектирования кода, компенсируют дополнительные ресурсы железа, для обеспечения быстродействия.
    > Во всем нужна мера, если оптимизация стоит больше чем железо, то я
    > выбираю железо.
    > У реальных программистов (а не сферических в вакууме) есть дедлайны, у них
    > нет в запасе пары лет на оптимизацию, им нужно показать работающий
    > код точно в срок. Нет кода -- нет еды.

    Абсолютно верно, с радостью бы вылизывали каждый запрос и каждую процедуру, и считали каждый байт переданный по сети, но за это не везде готовы платить :)

     
  • 6.32, kurokaze (ok), 10:27, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > У реальных программистов (а не сферических в вакууме) есть дедлайны, у них
    > нет в запасе пары лет на оптимизацию, им нужно показать работающий
    > код точно в срок. Нет кода -- нет еды.

    Ага, а потом приложение на твоем смартфоне вылетает по OutOfMemory
    Не стоит обобщать.

     
  • 6.37, Michael Shigorin (ok), 13:34, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > им нужно показать работающий код точно в срок. Нет кода -- нет еды.

    Ну не все ж за еду работают и с манагерами, которые верят в дедлайн превыше всего (вот такие обычно их и срывают, кстати).

     
     
  • 7.39, nn (??), 22:33, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну не все ж за еду работают и с манагерами

    За еду работают все. Не все с манагерами. Если у Вас лично есть доходы позволяющие не работать, но есть идеи и время на их реализацию, то это уже не работа, а творчество. Хорошо в этом плане некоторым ученным, удовлетворяют собственное любопытство за чужой счет, но не всем так повезло.

    >которые верят в дедлайн превыше всего (вот такие обычно их и срывают, кстати).

    Дедлайн необходим для разработки. Единственный безотказно действующий на всю команду стимул забыть про все и начать работать.

     
     
  • 8.40, Michael Shigorin (ok), 02:28, 02/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    С 2004 получается зарабатывать на хлеб творчеством Вот прийти к пониманию тог... текст свёрнут, показать
     
     
  • 9.41, nn (??), 11:54, 02/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Рад за вас Только зарабатывать на хлеб и работать за еду , практически сино... текст свёрнут, показать
     
  • 4.27, nn (??), 10:07, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают
    > для того чтобы они могли вообще не отлаживать и не оптимизировать
    > свой код. А в вэбе считают что мощности и пропускные способности
    > увеличивают для того чтобы можно было больше рекламмы всунуть.

    А вы покрутите видео fullhd на стареньком компе, много нового узнаете.  
    Технологии не стоят на месте. Требуется все большая вычислительная мощность и при этом меньшие размеры и меньшее энергопотребление. Веб 10 лет назад и сейчас это разный веб.
    Игры 10 лет назад и сейчас это разные игры. Мобильники сейчас и 10 лет назад это разные устройства.  

     
  • 4.29, NikolayV81 (?), 10:25, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают
    > для того чтобы они могли вообще не отлаживать и не оптимизировать
    > свой код. А в вэбе считают что мощности и пропускные способности
    > увеличивают для того чтобы можно было больше рекламмы всунуть.
    > Может они правы? Может мы вообще существуем для того чтобы есть всё
    > что подают? Может скоро издадут закон по которому пассивные пользователи (не
    > так часто покупающие новые компы и не кликающие по рекламме) будут
    > преследоваться по закону?

    Вы путаете программистов с работодателями... :)

     
  • 4.30, kurokaze (ok), 10:25, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают для того чтобы они могли вообще не отлаживать и не оптимизировать

    Хе, попрогал бы ты под iOS/Android, такого не писал бы.

     
  • 4.38, Ordu (ok), 17:50, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да, программисты всё меньше хотят думать. Они считают что мощности компьютера
    > увеличивают для того чтобы они могли вообще не отлаживать и не оптимизировать свой код.
    > А в вэбе считают что мощности и пропускные способности увеличивают для того чтобы можно
    > было больше рекламмы всунуть.

    Об этом ещё Вирт писал в какие-то пархатые годы.

    Когда UNIX появился, деды смеялись над ним и считали юниксойдов чем-то типа скрипткиддисов: ядро написанное не на ассемблере? ха-ха-ха!

    То есть я не к тому, что переход от C/C++ на javascript -- это хорошо. Не знаю. Тучи факторов, которые свести воедино и оценить я не могу. Я к тому это говорю, что ситуация до боли напоминает ту ситуацию со входом C в системное программирование. А уж эти скорбные высказывания о том, что программист всё меньше и меньше заботится об оптимизации программы, что программы всё толще и толще, я полагаю, звучат с тех пор как следом за первым компьютером появился второй.

     
  • 3.21, etw (??), 14:59, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    То, что вы описали, не является виртуализацией. обычный такой AMP (Asymmetric Multiprocessing).
     
     
  • 4.34, NikolayV81 (?), 10:30, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > То, что вы описали, не является виртуализацией. обычный такой AMP (Asymmetric Multiprocessing).

    по терминологии согласен, но по сути смысловой разницы особо не вижу.

     
  • 3.28, kurokaze (ok), 10:24, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >на сотне другой армов воткнутых в слоты расширения

    Эх молодежь и не в курсе что было такое время когда на транспьютеры возлагались большие надежды.
    Не выстрелило.

     
     
  • 4.35, NikolayV81 (?), 10:32, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>на сотне другой армов воткнутых в слоты расширения
    > Эх молодежь и не в курсе что было такое время когда на
    > транспьютеры возлагались большие надежды.
    > Не выстрелило.

    просто технологии были не на том уровне, а так "всё новое это хорошо забытое старое"

     

  • 1.17, Led (ok), 10:45, 28/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Новость можно было бы назвать скучной, если бы автор не упомянул "плавающую запятую":)
     
     
  • 2.19, Аноним (-), 12:42, 28/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Новость можно было бы назвать скучной, если бы автор не упомянул "плавающую запятую":)

    http://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81

     

  • 1.24, Аноним (-), 20:48, 28/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Процессоров ещё нет, а сборки уже есть?! А Linux и правда впереди планеты всей...
     
     
  • 2.33, kurokaze (ok), 10:29, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Процессоров ещё нет, а сборки уже есть?! А Linux и правда впереди
    > планеты всей...

    Типа с тем же USB 3.0 не так было.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру