README 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101
  1. rpi-boot
  2. --------
  3. A simple second stage boot loader for the Raspberry Pi to assist in the
  4. development of hobby kernels.
  5. Features
  6. --------
  7. * Supports booting flat binary files, ELF executables and ELF and a.out
  8. executables with a Multiboot header. Linux kernels are currently not
  9. supported (but support is planned for a future version).
  10. * Supports FAT(16/32) and ext2 filesystems.
  11. * Supports loading additional modules when in Multiboot mode.
  12. * Proviedes functions to the loaded kernel to allow it to easily
  13. access the framebuffer (via a printf() interface) and the filesystem
  14. (via fopen/fread/fclose/opendir/readdir/closedir).
  15. Installation
  16. ------------
  17. Edit config.h to your needs to enable/disable certain functionality.
  18. Run make in the source directory and copy the kernel.img file to the SD card
  19. containing your Raspian distribution. You are recommended to backup your
  20. original kernel.img file first.
  21. Usage
  22. -----
  23. The rpi-boot bootloader will initially search for files called
  24. /boot/rpi_boot.cfg, /boot/rpi-boot.cfg and /boot/grub/grub.cfg (in that order)
  25. on the first partition of the SD card. If one is not found, it searches for
  26. those files on each filesystem known to the system.
  27. It understands the following commands:
  28. multiboot <kernel> [cmdline]
  29. - Load a multiboot compliant kernel
  30. module <file> [name]
  31. - Load an additional Multiboot module
  32. kernel <kernel>
  33. - Load a non-multiboot compliant kernel
  34. boot
  35. - Boot the kernel
  36. binary_load_addr <address>
  37. - Set the load address for a flat binary file subsequently loaded by the
  38. 'kernel' command
  39. entry_addr <address>
  40. - Set the entry point that is jumped to by a subsequent 'boot' command
  41. console_log <file>[+] [buffer_size]
  42. - Copy the console log to a file. If '+' is specified after the file name
  43. then append to the file instead of overwriting it. If 'buffer_size'
  44. is specified then it is the number of bytes to buffer before writing
  45. to the file. This prevents the log quickly using up all the write
  46. cycles on solid state media, but runs the risk of some messages being
  47. lost on a kernel crash. Call fflush(get_log_file()) from the guest
  48. OS to manually flush the buffer. Support for console_log requires
  49. that ENABLE_CONSOLE_LOGFILE be enabled in config.h
  50. System state on kernel start
  51. ----------------------------
  52. For Multiboot kernels, the system state is defined in MULTIBOOT-ARM, otherwise:
  53. r0 will be 0
  54. r1 will be the ARM machine type
  55. r2 will be the address of the ATAGs
  56. (the above 3 are identical to the ARM Linux boot protocol)
  57. r3 will be the address of the multiboot_arm_functions structure as defined in
  58. MULTIBOOT-ARM.
  59. See the test-kernel directory for an example.
  60. Caveats
  61. -------
  62. rpi-boot occupies the first 1 MiB of memory for itself. If you wish to make
  63. use of the multiboot_arm_functions functions you need to preserve this. If
  64. not you can overwrite it from within your kernel. If you do overwrite it,
  65. you should make sure you have already obtained all the information you need
  66. from the various Multiboot structures (or copied them elsewhere).
  67. Because of this, rpi-boot will not boot kernels which are linked below 1 MiB.