[RPI BSP] cleaned up and reqest for review
gedare at gwu.edu
Mon Jun 15 15:14:37 UTC 2015
On Mon, Jun 15, 2015 at 10:57 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello Joel and Qiao Yang,
> On Monday 15 of June 2015 15:39:15 Joel Sherrill wrote:
>> On 6/14/2015 5:31 AM, QIAO YANG wrote:
>> > 1. Will rpi bsp has any kernel command line setup like i386? This would
>> > let us to choose fb console port or serial console port . Or maybe we
>> > just use compiler macro to enable/disable graphic console output?
>> How does the Linux kernel get its boot arguments? The pc386 BSP gets its
>> arguments the same way. Then there are some bsp command line methods to
>> access the parameters. The start code passes a string pointer to boot_card
>> for this to happen.
> Linux kernel on ARM can use two mechanism to obtain command line
> options from boot-loader
> The first is ATAGs mechanisms. This mechanism generally provides
> machine specific code to the kernel and sequence of 32-bit
> size and tag/data type blocks. ATAGS structure usually starts
> at memory address 0x100.
> The second, preferred now method, is to copy to RAM or prepare
> flattened device tree data (FDT) structure to the RAM from bootloader.
> This mechanism allows to describe all (allmost) machine parameters
> and peripherals connection to different non-enumerated busses.
> (Runtime detection is used for devices connected to enumerated busses).
> Older Videocore boot firmware did not provide FDT method nor
> merging but actual version is able to prepare device tree data
> in memory, merge commandline and optional specified device
> tree fragments and start kernel
> The short overview is placed on slide 13 and 14 of my presentation
> Complete Videocore firmware options are described there
> Description of Linux kernel booting on ARM is described
> in Linux kernel sources documentation
> The mainline U-boot switched to FDT based method long time ago
> and RPi branch provides FDT support now as well. I have build
> such U-boot and use FDT configured kernel on RPi with U-boot
> and direct boot from firmware for some time already.
> It would be great to provide some basic device tree support
> to RTEMS because it would solve parameters parsing and
> device recognition/base addresses etc. on all U-boot supported
> ARM platforms in future. Searching for nodes in device
> tree binary structure is quite easy. Knowledge how to interpret
> the names and hierarchy can be sometimes more complex but
> it is described in Linux kernel sources.
Chris Johns had an FDT implementation floating around, I think.
> Pointers to many FDT documents can be found there
> and I would help with testing, ideas and may it be with some
> code if time allows.
> But it is probably task for separate GSoC or major project.
>> > Something waiting to be done:
>> > 1. graphic console need the keyboard implementation . I would like to
>> > know the status of keyboard implementation.
> Most common is USB keyboard on RPi so it depends on USB support project.
> But for graphic output is is not so critical and for real embedded
> systems small keyboard on SPI can be usable as well.
> SPI on RPi is not/should not be a problem. I can provide examples
> of SPI based keyboard support for RTEMS and even HW implementation
> used on our other systems.
> Best wishes,
> Pavel Pisa
> devel mailing list
> devel at rtems.org
More information about the devel