arm atag retrieval problem

[Gedare Bloom]

On Mon, Jul 13, 2015 at 12:17 PM, 桥 杨 <yangqiao0505 at me.com> wrote:
>
>
>> 在 2015年7月13日，17:40，Gedare Bloom <gedare at rtems.org> 写道：
>>
>>> On Sat, Jul 11, 2015 at 11:29 AM, QIAO YANG <yangqiao0505 at me.com> wrote:
>>> Hi,
>>>
>>> I tried to retrieve atag command lines but I've got wired problems:
>>> I ran a quick scan for atags, start from 0x100, and I've got an output like
>>> :
>>>
>>> [ATAG_CORE] flags: 0, pagesize: 0, rootdev: 0
>>> [ATAG_MEM] size: 8000000, start: 0
>>> [ATAG_CMDLINE] found:
>>> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
>>> bcm2708.boardrev=0xf bcm2708.serial=0x8247b4bb smsc95xx.macaddr=B8s
>>> start addr:12C
>>> size : 2E616D64
>>> didn't find [ATAG_NONE]
>>>
>>> which told me that:
>>> 1. The start address of atag cmdline is 0x12C
>>> 2. The size of this tag is 0x2E616D64
>>> The size of the tag is abnormal.
>>> From the output, it seems that I only retrieved part of the cmdline.
>> Perhaps you have messed up the field layout or somehow gotten the
>> wrong field offsets?
>
> I've verified that.
>
>
>>
>>>
>>> I've also tried to use the mailbox interface to get the cmdline. what I've
>>> got is exactly the same part of string without error reponse. Even if I
>>> tried to print the following characters, they are all empty.
>>> I think that the atags area maybe rewritten in some way but I didn't managed
>>> to figure out. What bothers me most is the length of the tag, because the
>>> tag id is correct, part of the value is readable, there's no reason that the
>>> data between them is incorrect. The atag area should be written by
>>> videocore, who load the cmdline.txt where we can add additional lines.
>>>
>>>
>>> Besides I've also got a question that how can I get the value of r2 that
>>> passed by bootloader to kernel image? It should store the value of start
>>> address of ATAG or the magic of device tree. What I've found in linux is
>>> that there is a function like init( *param), which is called when loading
>>> the kernel, and the function get the value of r2 as the parameter passed to
>>> it.  I wonder how can I get this value, though by default the atag starts
>>> from 0x100.
>> Check in the BSP boot-up code (usually in the bsp subdirectory, start.S file).
>
> I've found it. It use the default startup code. Is there a possibility that the default arm start.S messed up something?  This might also explain why it bugged when using uboot to load it?
>
The default may not preserve the r2 register?

>>
>>>
>>> If it takes too long to implement the feature (atag, device tree ....), I've
>>> got other ways to detect if a hdmi device is present and then disable/enable
>>> the graphic console. If I'm allowed to pass the atag/device tree
>>> implementation.
>> Can you clarify this statement? What "other ways" do you mean?
>>
>
> If no display is connected , when we query the display size , vc will return 656*416.  I'm not sure if it's acceptable to be used as a probe.
>
If the return value without a display is a constant value, then this
should be ok to use temporarily at least. But you should continue to
work on getting the atag/dt working correctly, while you can work on
other parts of your project in parallel (Porting the graphics toolkit
to RSB).

>
>>>
>>> Best wishes.
>>>
>>>