Dear Eric,
In message <513dde22.4090...@boundarydevices.com> you wrote:
>
> Would it help if we restrict the number of boards directly in
> boards.cfg?
Not really. Thi sjust papers over the problem, but does not solve it.
> We'll be happy to pursue the SPL route, but this won't be
> something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2013 10:30 AM, Stefano Babic wrote:
> On 11/03/2013 15:02, Eric Nelson wrote:
>> Thanks Stefano,
>>
>> On 03/11/2013 06:44 AM, Stefano Babic wrote:
>>> On 11/03/2013 14:18, Fabio Estevam wrote:
Hi Stefano,
On Mon, Mar 11, 2013
On 11/03/2013 15:02, Eric Nelson wrote:
> Thanks Stefano,
>
> On 03/11/2013 06:44 AM, Stefano Babic wrote:
>> On 11/03/2013 14:18, Fabio Estevam wrote:
>>> Hi Stefano,
>>>
>>> On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic wrote:
>>>
As set previously, my position is, since RFC patches were
Thanks Stefano,
On 03/11/2013 06:44 AM, Stefano Babic wrote:
On 11/03/2013 14:18, Fabio Estevam wrote:
Hi Stefano,
On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic wrote:
As set previously, my position is, since RFC patches were pushed in
January, that some kind of complexity can be well mana
On Mon, Mar 11, 2013 at 10:44 AM, Stefano Babic wrote:
> IMHO, yes. The long term solution is using SPL, as well as it is already
> used in other SOCs. But at the moment, I tend to not block the current
> series, taking into account that we have not yet a i.MX6 board with SPL.
Thanks, Stefano. S
On 11/03/2013 14:18, Fabio Estevam wrote:
> Hi Stefano,
>
> On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic wrote:
>
>> As set previously, my position is, since RFC patches were pushed in
>> January, that some kind of complexity can be well managed with SPL
>> instead of with very SOC specific co
Thanks Wolfgang,
On 03/11/2013 04:15 AM, Wolfgang Denk wrote:
Dear Eric,
In message <513d18f3.2010...@boundarydevices.com> you wrote:
I understand the point, but think the pain is manageable and
mostly ours.
When I say it doesn't scale, I'm not only thinking about yourown
efforts, and your
Hi Stefano,
On Mon, Mar 11, 2013 at 9:04 AM, Stefano Babic wrote:
> As set previously, my position is, since RFC patches were pushed in
> January, that some kind of complexity can be well managed with SPL
> instead of with very SOC specific code. However, in the meantime I said
> explicitely tha
On 11/03/2013 12:15, Wolfgang Denk wrote:
> Dear Eric,
>
Hi Wolfgang, hi Eric,
sorry to jump late in the discussion.
> In message <513d18f3.2010...@boundarydevices.com> you wrote:
>>
>> I understand the point, but think the pain is manageable and
>> mostly ours.
>
> When I say it doesn't scale
Dear Eric,
In message <513d18f3.2010...@boundarydevices.com> you wrote:
>
> I understand the point, but think the pain is manageable and
> mostly ours.
When I say it doesn't scale, I'm not only thinking about yourown
efforts, and your customers.
I also think about things like the increase of bu
Thanks Wolfgang,
On 03/10/2013 03:03 PM, Wolfgang Denk wrote:
Dear Eric,
In message <513cb3f2.6080...@boundarydevices.com> you wrote:
What we don't have is auto-detection and implementing this logic
requires that we execute code outside of DDR (i.e. through SPL
in internal RAM).
Correct.
Dear Eric,
In message <513cb3f2.6080...@boundarydevices.com> you wrote:
>
> What we don't have is auto-detection and implementing this logic
> requires that we execute code outside of DDR (i.e. through SPL
> in internal RAM).
Correct.
> There's no question that a (more) universal binary would be
Hi Wolfgang,
On 03/10/2013 08:45 AM, Wolfgang Denk wrote:
Dear Eric Nelson,
In message <513ca21e.1040...@boundarydevices.com> you wrote:
In this case it should be possible to configure U-Boot for the maximum
possible RAM size (2 GB here?), then have get_ram_size() detect the
actual available
Dear Eric Nelson,
In message <513ca21e.1040...@boundarydevices.com> you wrote:
>
> > In this case it should be possible to configure U-Boot for the maximum
> > possible RAM size (2 GB here?), then have get_ram_size() detect the
> > actual available amount, and then adjust settings as needed.
>
>
Hi Wolfgang,
On 03/10/2013 12:59 AM, Wolfgang Denk wrote:
Dear Eric,
In message <1362873856-14785-1-git-send-email-eric.nel...@boundarydevices.com>
you wrote:
+Eric Nelson
+ nitrogen6dl i.MX6DL 1GB
+ nitrogen6dl2g i.MX6DL 2GB
+ nitroge
Hi Troy,
On 03/09/2013 05:49 PM, Troy Kisky wrote:
On 3/9/2013 5:04 PM, Eric Nelson wrote:
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
new file mode 100644
index 000..147bd91
--- /dev/null
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -0,0
Dear Troy,
In message <513bd8aa.4060...@boundarydevices.com> you wrote:
> On 3/9/2013 5:04 PM, Eric Nelson wrote:
> > diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
> > b/board/boundary/nitrogen6x/nitrogen6x.c
> > new file mode 100644
> > index 000..147bd91
> > --- /dev/null
> > +++ b/bo
Dear Eric,
In message <1362873856-14785-1-git-send-email-eric.nel...@boundarydevices.com>
you wrote:
>
> +Eric Nelson
> + nitrogen6dl i.MX6DL 1GB
> + nitrogen6dl2g i.MX6DL 2GB
> + nitrogen6q i.MX6Q/6D 1GB
> + nitrogen6q2g
On 3/9/2013 5:04 PM, Eric Nelson wrote:
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
new file mode 100644
index 000..147bd91
--- /dev/null
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -0,0 +1,895 @@
+int dram_init(void)
+{
+ gd->ram_si
19 matches
Mail list logo
