LinuxBIOS/lang-ko

From OLPC
< LinuxBIOS
Revision as of 18:48, 18 April 2007 by Xavi (talk | contribs) (deprecating translated page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
  번역근원 LinuxBIOS 원문  
  english | 한국어   +/- 차이  
Stop hand.png WARNING:
The content of this section is considered
DEPRECATED and OBSOLETE
It is preserved for historical or documenting reasons.
OLPC now uses Open Firmware for the bootloader
  • 참고: 기술적인 자료의 번역을 위해 여러분의 도움을 기대합니다. www.laptop.org 사이트와 이 사이트의 메인 페이지들은 대부분 번역되었으나, 나머지는 한글 요약만을 제공하고 있습니다. 어느 페이지든 추가 번역이 필요하면, XO Korea의 번역 섹션에 메시지를 남겨 주시기 바라며, 모자라는 번역 부분을 채워주실 손길을 기다리고 있습니다.
  • Note: Some core pages have been fully translated, and others are provided with summaries. If you need more translation, please leave a message onto the discussion page of this, or that of XO Korea.


개요

우리는 사설 바이오스 대신에 리눅스 바이오스와 리눅스를 이 노트북의 부트로더로 이용하고 있는데, 그 이유는;

  1. 기능. 우리 노트북의 특성으로 인해 커뮤니티와 리눅스 바이오스만이 제공할 수 있는 기능들
  2. 투명성.
  3. 견고함과 스피드
  4. 비용
  5. 자유

We are using LinuxBIOS and Linux as a bootloader in place of a proprietary BIOS on the Laptop board. We're doing this for a number of reasons:

  1. Functionality. Some parts of the design scenarios listed below are unique to this laptop. We would only be able to do this with the community and LinuxBIOS. In particular, we need to be able to resume the hardware very quickly; many BIOS's impose long delays on power on, and this reason, by itself, makes a commercial BIOS questionable.
  2. Transparency. We want kids to be able to get all the way down to the bare metal on these machines. The transparency that LinuxBIOS gives us is matched by no others.
  3. Robustness and speed. By leveraging Linux drivers rather than hand-crafted drivers in BIOS's we get well tested drivers for a wider variety of devices than any other system. And these drivers have been tuned for speed, as they are identical to that used in production Linux systems.
  4. Cost. Per-machine royalties add to the cost of the laptop. Every cent we have to spend for each machine means some number of kids that don't get laptops. In our case, the cost to use LinuxBIOS and Linux as Bootloader is approximately equal to what the cost would have been using a commercial BIOS. Regardless, LinuxBIOS remains an attractive solution for the other reasons given.
  5. Freedom. Free Software allows us to do what we need, independent of any proprietary software vendor.

On other systems, for example ones on which one can write protect main flash pages, one might put the Linux image being used as a bootloader into such write protected pages. The NAND flash on our system lacks page level write protect bits, and therefore for robustness sake, we decided we want Linux as bootloader to also fit into the the ROM with LinuxBIOS (and the embedded controller code). The actual cost turned out to be almost identical to using a commercial BIOS.

OLPC에서 리눅스 바이오스 부트 비디오

Here's a video of LinuxBIOS booting Linux on a rev a board. The movie

하드웨어 제약성

OLPC 보드에는 1MB의 시리얼 플레시만 가용하며, 이 공간에 다음 코드들을 압축해서 담아야 합니다.

  1. 리눅스 바이오스 코드
  2. VSA(Virtual System Architecture code)
  3. 임베디드 컨트롤러를 위한 64k
  4. USB 스택을 포함한 리눅스 커널
  5. 설치를 위한 busybox와 스크립트와 더불어 메모리 파일 시스템 내의 initrd
  6. 설치를 위한 모든 아이콘
EC가 사용하는 코드 64kb가 손상되면 잘못 플래시된 보드의 복구가 굉장히 어려우므로, 시리얼 넘버, 키보드 타입 그리고 유사한 정보를 보관한 추가 공간이 필요합니다.
  1. 필드에서 결코 업데이트 되지 않을 것으로 보이는 바로 이 64kb
  2. 아마도 업데이트 될 시리얼 플래시의 나머지

EC 코드가 시리얼 플래시의 write-enable을 위한 라인 컨트롤을 가지므로, write-enable이 assert되기 전에 어떤 키를 누르게 함으로써, 바이러스가 시리얼 플래시를 파괴하고, 기계 작동을 멈추게 하는 일을 방지할 수 있습니다.

We are limited to the 1MB of serial flash that's available in the OLPC board. Into this space (mostly compressed) must fit:

  1. the LinuxBIOS code that sets up the basic hardware.
  2. the VSA (Virtual System Architecture code) that emulates many of the legacy devices on the Geode.
  3. 64kb of code for the embedded controller, used for keyboard and power management functions.
  4. A Linux kernel (configured to be small), that includes a USB stack. It now appears likely we'll also be able to fit a full networking stack into the serial flash as well, when work is completed on converting to LZMA compression. If the networking stack cannot fit into the serial flash, we'll put the stack as a module in a partition on the NAND flash, but this is less robust and more prone to corruption than the serial flash. In order to complete functionality sooner rather than later, we will take this route until the compression work can be merged.
  5. An initrd (in memory file system) with busybox and scripts for installation.
  6. Any icons we use for installation, which may avoid localization headaches.

Since recovery of a board that has been mis-flashed can be extremely difficult if the 64kb of code the EC uses is damaged, and we need some place to store a serial number, keyboard type, and similar information, we are going to write the serial flash in two independent pieces:

  1. this 64kb region, which we hope will never be updated in the field
  2. the rest of the serial flash, which might have to be updated in the field.

Since the EC code has control of the line for write-enable of the serial flash, we will enforce that a key be held down before write-enable can be asserted, so that any virus or worm cannot easily destroy the serial flash, which would render the machine unusuable.

디자인 목표

원격지 아이들이 노트북을 리플래시할 수 있도록 바이오스를 통한 재 설치 시나리오가 필요합니다.

We have some pretty specific design goals with LinuxBIOS on the Laptop hardware. We need to support a few re-install scenarios via the BIOS to enable kids in remote areas to be able to reflash their machines. The scenarios are outlined below.

낸드 플래시에서 부트

일반적인 방법입니다.

This is the normal case for the laptop. Simply loading a kernel off the NAND flash and then using kexec() to load that new kernel into memory and jump to it. This requires having a driver for the NAND flash and being able to locate the kernel on the internal NAND flash.

USB 저장 장치에서 부트

플래시 드라이브와 하드 드라이브를 위한 적절한 USB 드라이버가 있어야 합니다. 그런데, 많은 USB 저장장치들에 접근하기 위해서는 딜레이 (delay)가 발생합니다.

Another common system for booting the machine to recover it is to use a USB Flash Drive or use a USB Hard Drive to start an install process. This requires having decent USB drivers for flash drives and hard drives. One of the headaches is that many USB storage devices claim they are ready, but actually are not ready and require a delay before accessing the device.

이더넷에서 부트

공장에서 플래시를 로드하는 가장 쉬운 방법은 이더넷입니다. USB 저장장치에서 설치하는 것도 가능하지만, USB 저장장치가 라인 상에서 사용될 필요가 없을 때는, 공장 생산 흐름이 가장 쉽고 유연하지만, 우리는 단지네트워크에 연결된 USB 무선 동글을 꽂기만 하면 됩니다. 무선은 이러한 생산율에 적합하지 않습니다 (아마도, 하루 20,000세트 이상 0.5기가바이트). 추가적으로, 공장 플로어는 특정 머신에 개별 이미지를 로드하길 원할 것이며, 적어도, 시리얼넘버를 포함한 64kb, 생산일자, 생산자 등이 포함됩니다. 이러한 이미지를 플라이 (fly) 상에 생성하는 것은 서버 시스템에서 간단한데, 그것은 또한 각 빌트 머신을 위한 MAC 주소를 기록할 수 있습니다.

By far the easiest way to load the flash in the factory will be via ethernet. While installing from USB storage devices is possible, factory

production flow will be easiest and most flexible if USB storage devices do not have to be used on the line, but we can simply plug in a USB wireless dongle connected to a network. Wireless is not feasible at these production rates (potentially .5 gigabytes by 20,000 or more machines/day).

Additionally, the factory floor will want to load individual images onto particular machines, at least the 64kb of the serial flash including a serial number, date of manufacture, manufacturer, etc. Generating these images on the fly is simple on a server system, which can also record the MAC address for each machine built.

리눅스 바이오스 이미지

사람들

리눅스 바이오스 프로젝트에 참여하는 사람들입니다. The following people are heavily involved with the LinuxBIOS project. Please contact them on the devel@laptop.org mailing list.

  • Ronald Minnich
  • Marcelo Tosatti
  • Ray Tseng
  • Roger Huang
  • Morse Chen
  • Jordan Crouse
  • Michael Lin
  • Richard Smith

외부 링크

FSF Campaign for a Free BIOS

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=LinuxBIOS/lang-ko&oldid=34349"