[meta-xilinx] Kernel Command Line problem

[Mike Looijmans]

Sorry, I hadn't noticed you were using a microblaze. It could be that they got 
it wrong there, as this is all machine-specific code.

Mike.

On 12/04/2013 04:23 PM, Martin Townsend wrote:
> Hi Mike,
>
> Thanks for the swift reply.
> I've checked my configuration and in Processor type and features I have
> [ ] Default bootloader kernel arguments
> Which I assume is correct as I don't want default kernel arguments as U-Boot
> is providing them, I couldn't find any other options.
>
> I stepped through the code where it switches from U-Boot to the Kernel
> (head.S) and I see it grabbing the kernel command line.  Then in prom.c,
> function void __init early_init_devtree(void *params) it calls
> of_scan_flat_dt(early_init_dt_scan_chosen, cmd_line); which then overwrites
> cmd_line with what's in chosen.
>
> Are you passing in the device tree using U-Boot?
>
> Best Regards,
> Martin.
>
>
> On 04/12/13 15:09, Mike Looijmans wrote:
>> My experience so far has been that the u-boot provided commandline prevails
>> over the one in the devicetree. I also use the commandline to switch between
>> rootfs locations (e.g. SD or internal flash via UBI) and have never
>> encountered any problems. In my case, the devicetree sets up rootfs in
>> flash, while the commandline will override this to boot from SD card.
>>
>> I think you should check the kernel configuration, there are configuration
>> items that allow overriding this behavior.
>>
>> In addition, check that u-boot is properly passing the commandline along,
>> maybe the kernel isn't getting what it expects.
>>
>> Mike.
>>
>> On 12/04/2013 03:57 PM, Martin Townsend wrote:
>>> Hi,
>>>
>>> I now have the 3.10 Kernel booting.  I had an issue where my Kernel bootargs
>>> that I had setup in the U-Boot environment weren't being used by the Kernel.
>>> After some debugging I found that they were being overwritten by the ones in
>>> the 'chosen' section of the device tree.  My understanding (which may be
>>> wrong) is that the bootargs passed by the bootloader have a higher precedence
>>> than the one in the device tree so I hacked the prom.c file in
>>> arch/microblaze/kernel/prom.c so it doesn't process 'chosen' to get things
>>> working.  The reason I want to use U-Boot bootargs is that we are mounting the
>>> Root Filesystem using NFS and each board will have a different rootpath
>>> variable in the U-Boot env, we are also storing the unique MAC address here
>>> too.  It's easier to program a unique environment rather than regenerate the
>>> device tree.
>>>
>>> First am I right in assuming the bootloader should have higher precedence and
>>> if so I would appreciate if someone could look at this patch that I'm using as
>>> a hack and advise on the right way to do it :)
>>>
>>> Best Regards,
>>> Martin.
>>>
>>> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
>>> index 0a2c68f..bff2c75 100644
>>> --- a/arch/microblaze/kernel/prom.c
>>> +++ b/arch/microblaze/kernel/prom.c
>>> @@ -118,7 +118,8 @@ void __init early_init_devtree(void *params)
>>>        * device-tree, including the platform type, initrd location and
>>>        * size, TCE reserve, and more ...
>>>        */
>>> -    of_scan_flat_dt(early_init_dt_scan_chosen, cmd_line);
>>> +    if(cmd_line[0] == '\0')
>>> +        of_scan_flat_dt(early_init_dt_scan_chosen, cmd_line);
>>>
>>>       /* Scan memory nodes and rebuild MEMBLOCKs */
>>>       of_scan_flat_dt(early_init_dt_scan_root, NULL);
>>
>