Porting barebox (devicetree) to Variscite iMX6 SOM

[Michael Burkey]

Sascha, thanks for the advice on the stack unwinding and other
debugging aids. It was a huge help.

I have made progress and isolated and gotten past my earlier null
pointer problem -- it turned out to be an issue that you had already
fixed on the tip (the recent changes to armlinux_get_bootparams fixed
the null pointer issue).

That said, I'm still having issues booting with an older kernel. Which
brings me to my next question....

In the case where I am booting an old, non-devicetree, kernel with a
newer, devicetree, version of barebox, and then using "oftree -f" to
flush the devicetree before starting the kernel, what is the proper
way to have things like the boot parameters, the boot architecture,
etc. specified for passing to the older kernel? Just go back and add
them into the board files like they used to be in older versions of
barebox? Do you know if having stuff specified in both the old way and
in the oftree will cause any potential problems?

Basically, my goal is to have a version of barebox than can launch
either our current (old) kernel or a newer mainline version
interchangeably without having to upgrade barebox (basically, we will
probably initially be shipping an older kernel and then upgrading to a
newer one later -- and, if at all possible, I'd really rather not have
to incur the risk of having our users need to update barebox in the
field as well).

Thanks,
Michael Burkey


On 1/10/14, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Thu, Jan 09, 2014 at 02:20:33AM -0500, Michael Burkey wrote:
>> A few more comments & questions regarding getting the Variscite SOM up
>> and working (and it's pretty close to fully working at this point):
>>
>> First off, what works:
>>
>> 1) Booting from NAND, SD, etc to barebox
>> 2) Nand programming under barebox
>> 3) GPIO
>> 4) I2C
>> 5) USB
>> 6) RS232
>> etc.
>>
>> Basically, things are working pretty well....up to the point of
>> starting the Linux Kernel.
>>
>> Whenever I try to do a "bootm" of pretty much any image type, I run
>> into issues. I *think* I have everything setup properly on the Linux
>> command line in the way of bootargs (but I'm still checking a couple
>> of things). It doesn't matter whether I am launching the kernel from a
>> partition (NAND), USB, memory, etc. The result is the same regardless.
>> It *does* decode the kernel header properly, display the version, the
>> correct load address, etc -- so that's not the issue.
>>
>> One thing is that I am using an older kernel that is not setup for
>> devicetree -- which is hopefully not a major problem. Basically,
>> everything is specified "the old way" in the kernel platform/board
>> files (and it works fine from u-boot). And, at least for now, moving
>> to a newer kernel isn't an option.
>>
>> Under barebox, I either get a "launching kernel with devicetree" and
>> then it hangs,
>
> Ok, this is expected since your kernel does not have devicetree support
>
>> or, if I do an "oftree -f" and then do a bootm,
>
> That's the correct thing to do. With this it should work.
>
>> I get
>> an "unable to dereference NULL pointer" and a restart.
>
> You could enable:
>
> [*] enable arm exception handling support
> [*]   enable stack unwinding support
>
> and
>
> [*] kallsyms
>
> With this barebox prints a backtrace giving a clue where the NULL
> pointer deref happens.
>
>>
>> Any quick guesses, suggestions as to what I may be doing wrong?
>> Is there a proper way to tell barebox (when started with devicetree)
>> to NOT try to send the devicetree on to the kernel?
>>
>> Also, for the moment, I am using Kobs-NG under Linux to actually
>> program barebox itself into NAND. Once there, it works fine and I can
>> use barebox itself to program the other NAND partitions. Is adding
>> support for writing out the FCB/DBBT to the first NAND blocks anywhere
>> in the current (near-term) to do list for barebox? I noticed that it
>> looked like you had something similar to this already in barebox for a
>> couple of the other, earlier iMX cores.
>>
>>
>> Lastly, once I do get this semi-final issue fixed, what is the best
>> way to submit the code for the Variscite SOM to the main barebox tree
>> for everyone else to have access to?
>
> Just post the patches to the list. I'll include them then.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>