Wolfgang Denk wrote:
Thanks. Just to be clear, do you expect fdt_fw_addr always to point to a
FIT-wrapped firmware binary?
Please re-read the IRC log. Kumar explicitly stated he was trying to
avoid making FIT images mandatory, at least for now.
And he proposed a board-specific function
Dear Timur Tabi,
In message 4bfd3a39.4090...@freescale.com you wrote:
Please re-read the IRC log. Kumar explicitly stated he was trying to
avoid making FIT images mandatory, at least for now.
And he proposed a board-specific function that would allow this to work, but
you rejected it.
Wolfgang Denk wrote:
And he proposed a board-specific function that would allow this to work, but
you rejected it. So I don't still know how to implement what you want.
Well, in a way that may be image-type dependent, but that is not
board-specific.
Technically, that's true, but in most
On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
I believe we should have a board-specific function that figures out how much
extra space is needed, and just returns a single integer that the
boot_relocate_fdt() uses to pad the FDT when it relocates it.
Why don't we just grow the
Scott Wood wrote:
On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
I believe we should have a board-specific function that figures out how much
extra space is needed, and just returns a single integer that the
boot_relocate_fdt() uses to pad the FDT when it relocates it.
Why
On 05/26/2010 12:56 PM, Timur Tabi wrote:
Scott Wood wrote:
On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
I believe we should have a board-specific function that figures out how much
extra space is needed, and just returns a single integer that the
boot_relocate_fdt() uses to
Scott Wood wrote:
But you can reasonably allocate significantly more than you'll need
without actually causing the fdt to get that big. The actual cap could
be a board specific magic number (like CONFIG_SYS_MALLOC_LEN), or we
could cap it at something based on the amount of RAM.
We have
Dear Timur Tabi,
In message 4bfd4e83.2080...@freescale.com you wrote:
Well, in a way that may be image-type dependent, but that is not
board-specific.
Technically, that's true, but in most cases the function that returns the
address/size of the firmware would exist in board code.
For
Dear Timur Tabi,
In message 4bfd6704.2040...@freescale.com you wrote:
We have something like that already:
#ifndef CONFIG_SYS_FDT_PAD
#define CONFIG_SYS_FDT_PAD 0x3000
#endif
And Wolfgang doesn't like it.
Because nobody can explain where this magic number 0x3000 is coming
from or why
On Thu, May 20, 2010 at 3:28 AM, Wolfgang Denk w...@denx.de wrote:
Instead of implementing this feature in a way that makes it restricted
to your current use case only we can as well make it generic enough so
others can use it as well.
Wolfgang, can you tell me what method you would like me to
Dear Timur Tabi,
In message aanlktikguhbxqzywcup04c2scub6uof75zdoh-boz...@mail.gmail.com you
wrote:
On Thu, May 20, 2010 at 3:28 AM, Wolfgang Denk w...@denx.de wrote:
Instead of implementing this feature in a way that makes it restricted
to your current use case only we can as well make it
Wolfgang Denk wrote:
But as this seems obvious I feel you might have something else in
mind, yet I cannot figure out what it might be.
How would you prefer the user to be able to specify the address of the
firmware FIT image, when he wants to boot Linux? I think I remember Kumar
saying
Dear Timur Tabi,
In message 4bfc1075.5010...@freescale.com you wrote:
But as this seems obvious I feel you might have something else in
mind, yet I cannot figure out what it might be.
How would you prefer the user to be able to specify the address of the
firmware FIT image, when he
Wolfgang Denk wrote:
That was on IRC; here the relevant snippet:
Thanks. Just to be clear, do you expect fdt_fw_addr always to point to a
FIT-wrapped firmware binary?
(17:40:56) TimurTabi: also, the binding says that the qe firmware
node should be located inside the first qe node
Dear Timur Tabi,
In message 4bfc24db.8070...@freescale.com you wrote:
Wolfgang Denk wrote:
That was on IRC; here the relevant snippet:
Thanks. Just to be clear, do you expect fdt_fw_addr always to point to a
FIT-wrapped firmware binary?
Please re-read the IRC log. Kumar explicitly
Dear Timur Tabi,
In message 4bf4623b.1080...@freescale.com you wrote:
Why would this in any way be a board specific implementation? This
makes no sense to me. The feature to include some binary data into the
DTB is IMO in no way dependent on or specific to a certain board.
The data I'm
On Thu, May 20, 2010 at 3:28 AM, Wolfgang Denk w...@denx.de wrote:
Dear Timur Tabi,
In message 4bf4623b.1080...@freescale.com you wrote:
Why would this in any way be a board specific implementation? This
makes no sense to me. The feature to include some binary data into the
DTB is IMO in
Kumar Gala wrote:
int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
char **of_flat_tree, ulong *of_size)
{
...
if ((fdt_blob + *of_size + fdt_board_size()) =
((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
relocate
On May 19, 2010, at 5:06 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 52e9d06a-e721-4907-9024-11bdc8d00...@kernel.crashing.org you
wrote:
So I tried to read this whole thread and got lost in the discussion.
I'm wondering of something along the following lines would address your
Dear Timur Tabi,
In message aanlktimff-mm8jlicndervkwwrvpmqeeeuvd_rntm...@mail.gmail.com you
wrote:
And again, the point *I* am trying to make is that it's okay to put the
onus
of that check on the *caller* of fdt_increase_size(), and not on
fdt_increase_size() itself.
OK. I have
Wolfgang Denk wrote:
I reject your patch because it introduces the risk of crashing the
system and it appears you do not want to be bothered fixing this.
But I believe I have already fixed it by stating that any users of
fdt_increase_size() must ensure that the new size fits in the allocated
Wolfgang Denk wrote:
I think the places where strcat() is used actually try and make sure
to have enough room in the target buffer; also, almost all of themn
appent static strigs with well-known sizes only.
You talked about inserting user-supplied data of unknown size.
Yes and no. The
Dear Timur Tabi,
In message 4bf4051a.1090...@freescale.com you wrote:
You make a lot of statements saying that I can do this and I can do
that, but you provide no examples. Have you even looked at the code
to see what such a change would require?
No, I haven't. I don't have to look at that
So I tried to read this whole thread and got lost in the discussion. I'm
wondering of something along the following lines would address your concerns:
#define CONFIG_SYS_FDT_PAD 0x3000
/* Allow for arch specific config before we boot */
int __fdt_board_size(void)
{
return
Dear Kumar Gala,
In message 52e9d06a-e721-4907-9024-11bdc8d00...@kernel.crashing.org you wrote:
So I tried to read this whole thread and got lost in the discussion.
I'm wondering of something along the following lines would address your
concerns:
My concerns are simple: if we need to increase
Wolfgang Denk wrote:
Why would this in any way be a board specific implementation? This
makes no sense to me. The feature to include some binary data into the
DTB is IMO in no way dependent on or specific to a certain board.
The data I'm trying to embed is firmware for various devices on some
Dear Timur Tabi,
In message 4bf29fe9.1070...@freescale.com you wrote:
Wolfgang Denk wrote:
Assume the case that the DTB is stored in NOR flash, and I pass the
NOR flash address to the bootm command...
I'm not sure if there is any guarantee for free room behind the DTB in
this case.
Wolfgang Denk wrote:
We can never guarantee this. The code that calls fdt_increase_size() will
just have to ensure that there is enough room.
Such an ensure that there is enough room is exactly what I'm asking
for.
Maybe I don't understand what you're getting at. My point is that,
Dear Timur Tabi,
In message 4bf2b302.2030...@freescale.com you wrote:
We can never guarantee this. The code that calls fdt_increase_size() will
just have to ensure that there is enough room.
Such an ensure that there is enough room is exactly what I'm asking
for.
Maybe I don't
On Tue, May 18, 2010 at 5:20 PM, Wolfgang Denk w...@denx.de wrote:
And again, the point *I* am trying to make is that it's okay to put the onus
of that check on the *caller* of fdt_increase_size(), and not on
fdt_increase_size() itself.
OK. I have no problem with that. I am just missing this
Timur Tabi wrote:
On Sat, May 15, 2010 at 9:11 PM, Gerald Van Baren gvb.ub...@gmail.com wrote:
The code has one pre-existing weakness that bothers me: if there is
something following the FDT blob, it will get overwritten by the
increased blob. One way around this would be to malloc() a new
Dear Timur Tabi,
In message aanlktilprgpuwl630lzsmzkt5bbxfiq6zdpiir3pq...@mail.gmail.com you
wrote:
I've added this to your patch, but have *NOT* execution tested it. Does
this addition (a) make sense and (b) work?
I was expecting the caller of fdt_increase_size() to know that the
space
Wolfgang Denk wrote:
I was expecting the caller of fdt_increase_size() to know that the
space after the fdt is available.
So where is the code that makes sure that there is sufficient space
available?
Well, if I load the fdt to address c, and it's 10KB in size, I'm pretty
sure I can
Dear Timur Tabi,
In message 4bf14fbf.3040...@freescale.com you wrote:
So where is the code that makes sure that there is sufficient space
available?
Well, if I load the fdt to address c, and it's 10KB in size, I'm pretty
sure I can expand it to 16KB if I know that there's nothing
The function fdt_increase_size() increases the size of the device tree by
the given amount. This is useful for any code that wants to add a node
or large property, to avoid the possibility of running out of space.
It's much smarter to have U-Boot increase the size of device tree when
it knows
On Sat, May 15, 2010 at 9:11 PM, Gerald Van Baren gvb.ub...@gmail.com wrote:
The code has one pre-existing weakness that bothers me: if there is
something following the FDT blob, it will get overwritten by the
increased blob. One way around this would be to malloc() a new memory
space and
36 matches
Mail list logo
