[meta-xilinx] Kernel Command Line problem

Martin Townsend martin.townsend at xsilon.com
Wed Dec 4 07:23:22 PST 2013


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);
>




More information about the meta-xilinx mailing list