All of lore.kernel.org
 help / color / mirror / Atom feed
* TFTP boot using DNS
@ 2022-12-15  9:27 Valerio Nappi
  2022-12-15 12:55 ` Harald Seiler
  0 siblings, 1 reply; 3+ messages in thread
From: Valerio Nappi @ 2022-12-15  9:27 UTC (permalink / raw)
  To: u-boot

Hello everyone,

Context:
I'm new to the u-boot project. I am trying to boot a Zynq SoC from an internal TFTP server, but i have no guarantee that the IP of the server is going to stay the same. A DNS service is offered, and kept updated.

When i try to update the serverip variable using the dns <myserver> serverip command, the variable seems updated (in the sense that I can print the new value) but it is not. Apparently this is ignored on purpose at this line of the source [1]. Commit fd3056337 that introduced this change, mentions "Don't update the variables when the source was programmatic, since the variables were the source of the new value.", that is not true in this case, in fact the source of the new value is the DNS service.

Is there a particular reason why this usecase was not forseen?

Best,
Valerio

[1]: https://github.com/u-boot/u-boot/blob/c917865c7fd14420d25388bb3c8c24cb03911caf/net/net.c#L251


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: TFTP boot using DNS
  2022-12-15  9:27 TFTP boot using DNS Valerio Nappi
@ 2022-12-15 12:55 ` Harald Seiler
  2022-12-15 14:42   ` Valerio Nappi
  0 siblings, 1 reply; 3+ messages in thread
From: Harald Seiler @ 2022-12-15 12:55 UTC (permalink / raw)
  To: Valerio Nappi, u-boot; +Cc: Joe Hershberger

Hi Valerio,

On Thu, 2022-12-15 at 10:27 +0100, Valerio Nappi wrote:
> Hello everyone,
> 
> Context:
> I'm new to the u-boot project. I am trying to boot a Zynq SoC from an
> internal TFTP server, but i have no guarantee that the IP of the
> server is going to stay the same. A DNS service is offered, and kept
> updated.
> 
> When i try to update the serverip variable using the dns <myserver>
> serverip command, the variable seems updated (in the sense that I can
> print the new value) but it is not. Apparently this is ignored on
> purpose at this line of the source [1]. Commit fd3056337 that
> introduced this change, mentions "Don't update the variables when the
> source was programmatic, since the variables were the source of the
> new value.", that is not true in this case, in fact the source of the
> new value is the DNS service.
> 
> Is there a particular reason why this usecase was not forseen?

Unrelated to your point about proper support for this usecase, but maybe
you can use the following as a workaround in the meantime?

	tftp ${loadaddr} ${serverip}:path/to/file

Also adding Joe on CC as he authored the commit you mentioned.

-- 
Harald

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: TFTP boot using DNS
  2022-12-15 12:55 ` Harald Seiler
@ 2022-12-15 14:42   ` Valerio Nappi
  0 siblings, 0 replies; 3+ messages in thread
From: Valerio Nappi @ 2022-12-15 14:42 UTC (permalink / raw)
  To: Harald Seiler, u-boot; +Cc: Joe Hershberger

Hi Harald,

Thank you for your reply.

As a workaround right now I'm using a patched version that comments out the check for the serverip handler, and it is working.

Nevertheless, let's see if we can understand how this should be handled.

Best,
Valerio

On 12/15/22 13:55, Harald Seiler wrote:
> Hi Valerio,
>
> On Thu, 2022-12-15 at 10:27 +0100, Valerio Nappi wrote:
>> Hello everyone,
>>
>> Context:
>> I'm new to the u-boot project. I am trying to boot a Zynq SoC from an
>> internal TFTP server, but i have no guarantee that the IP of the
>> server is going to stay the same. A DNS service is offered, and kept
>> updated.
>>
>> When i try to update the serverip variable using the dns <myserver>
>> serverip command, the variable seems updated (in the sense that I can
>> print the new value) but it is not. Apparently this is ignored on
>> purpose at this line of the source [1]. Commit fd3056337 that
>> introduced this change, mentions "Don't update the variables when the
>> source was programmatic, since the variables were the source of the
>> new value.", that is not true in this case, in fact the source of the
>> new value is the DNS service.
>>
>> Is there a particular reason why this usecase was not forseen?
> Unrelated to your point about proper support for this usecase, but maybe
> you can use the following as a workaround in the meantime?
>
> 	tftp ${loadaddr} ${serverip}:path/to/file
>
> Also adding Joe on CC as he authored the commit you mentioned.
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-12-15 21:25 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-15  9:27 TFTP boot using DNS Valerio Nappi
2022-12-15 12:55 ` Harald Seiler
2022-12-15 14:42   ` Valerio Nappi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.