public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] Add a new protocol
@ 2012-08-21 16:27 EVS Hardware Dpt
  2012-08-25  5:16 ` Albert ARIBAUD
  0 siblings, 1 reply; 6+ messages in thread
From: EVS Hardware Dpt @ 2012-08-21 16:27 UTC (permalink / raw)
  To: u-boot

Hi,

I want to add a new network protocol to u-boot. However it seems that the
most straightforward way to add a new protocol is to add it to NetLoop's
supported protocols. Of course, I would create a .c/.h pair of files to
manage the protocol and use CONFIG_XXX to ensure it doesn't add unnecessary
code.

My problem is that the protocol is used for internal testing procedures to
make u-boot act as a command server allowing a host pc to read/write
memory, use i2c, program various data into flash (Mac Address, ID's, ...)
and so on. The protocol could be gpl'ed and documented, yet it still have
limited use outside our test procedure.

So what could be the best way to achieve that goal? Should I replicate the
whole NetLoop functionalities adapted to my protocol and put it on a .c/.h
pair of files (and still using CONFIG_XXX) and keep these files available
on request, or must I add that protocol to the "official" list of supported
protocols? The second option is not very valuable for the community I
think, but the first solution seems to be a very nasty hack.

What's your opinion ?

Regards,
Fred.

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

* [U-Boot] Add a new protocol
  2012-08-21 16:27 [U-Boot] Add a new protocol EVS Hardware Dpt
@ 2012-08-25  5:16 ` Albert ARIBAUD
  2012-08-27 15:07   ` EVS Hardware Dpt
  0 siblings, 1 reply; 6+ messages in thread
From: Albert ARIBAUD @ 2012-08-25  5:16 UTC (permalink / raw)
  To: u-boot

Hi Fred,

On Tue, 21 Aug 2012 18:27:02 +0200, EVS Hardware Dpt
<hardware.evs@gmail.com> wrote:

> Hi,
> 
> I want to add a new network protocol to u-boot. However it seems that
> the most straightforward way to add a new protocol is to add it to
> NetLoop's supported protocols. Of course, I would create a .c/.h pair
> of files to manage the protocol and use CONFIG_XXX to ensure it
> doesn't add unnecessary code.
> 
> My problem is that the protocol is used for internal testing
> procedures to make u-boot act as a command server allowing a host pc
> to read/write memory, use i2c, program various data into flash (Mac
> Address, ID's, ...) and so on. The protocol could be gpl'ed and
> documented, yet it still have limited use outside our test procedure.
> 
> So what could be the best way to achieve that goal? Should I
> replicate the whole NetLoop functionalities adapted to my protocol
> and put it on a .c/.h pair of files (and still using CONFIG_XXX) and
> keep these files available on request, or must I add that protocol to
> the "official" list of supported protocols? The second option is not
> very valuable for the community I think, but the first solution seems
> to be a very nasty hack.
> 
> What's your opinion ?

U-Boot has a network console (see doc/README.NetConsole). Can you not
use this for your tests?

> Regards,
> Fred.

Amicalement,
-- 
Albert.

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

* [U-Boot] Add a new protocol
  2012-08-25  5:16 ` Albert ARIBAUD
@ 2012-08-27 15:07   ` EVS Hardware Dpt
  2012-08-27 15:54     ` Albert ARIBAUD
  0 siblings, 1 reply; 6+ messages in thread
From: EVS Hardware Dpt @ 2012-08-27 15:07 UTC (permalink / raw)
  To: u-boot

Hi Albert,

Yes, I could, but the purpose of my protocol is to be software driven and
not human driven. Also error checking is extremely important when testing
boards.

Regards,
Fred.

2012/8/25 Albert ARIBAUD <albert.u.boot@aribaud.net>

> Hi Fred,
>
> On Tue, 21 Aug 2012 18:27:02 +0200, EVS Hardware Dpt
> <hardware.evs@gmail.com> wrote:
>
> > Hi,
> >
> > I want to add a new network protocol to u-boot. However it seems that
> > the most straightforward way to add a new protocol is to add it to
> > NetLoop's supported protocols. Of course, I would create a .c/.h pair
> > of files to manage the protocol and use CONFIG_XXX to ensure it
> > doesn't add unnecessary code.
> >
> > My problem is that the protocol is used for internal testing
> > procedures to make u-boot act as a command server allowing a host pc
> > to read/write memory, use i2c, program various data into flash (Mac
> > Address, ID's, ...) and so on. The protocol could be gpl'ed and
> > documented, yet it still have limited use outside our test procedure.
> >
> > So what could be the best way to achieve that goal? Should I
> > replicate the whole NetLoop functionalities adapted to my protocol
> > and put it on a .c/.h pair of files (and still using CONFIG_XXX) and
> > keep these files available on request, or must I add that protocol to
> > the "official" list of supported protocols? The second option is not
> > very valuable for the community I think, but the first solution seems
> > to be a very nasty hack.
> >
> > What's your opinion ?
>
> U-Boot has a network console (see doc/README.NetConsole). Can you not
> use this for your tests?
>
> > Regards,
> > Fred.
>
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

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

* [U-Boot] Add a new protocol
  2012-08-27 15:07   ` EVS Hardware Dpt
@ 2012-08-27 15:54     ` Albert ARIBAUD
  2012-08-27 16:35       ` EVS Hardware Dpt
  0 siblings, 1 reply; 6+ messages in thread
From: Albert ARIBAUD @ 2012-08-27 15:54 UTC (permalink / raw)
  To: u-boot

Hi EVS,

On Mon, 27 Aug 2012 17:07:42 +0200, EVS Hardware Dpt
<hardware.evs@gmail.com> wrote:

> Hi Albert,
> 
> Yes, I could, but the purpose of my protocol is to be software driven
> and not human driven. Also error checking is extremely important when
> testing boards.

Not sure I get you there. The netconsole is just a way to access the
U-Boot prompt from the network; commands can be input on this prompt,
and results from it can be processed, by a human or machine alike.

> Regards,
> Fred.

Amicalement,
-- 
Albert.

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

* [U-Boot] Add a new protocol
  2012-08-27 15:54     ` Albert ARIBAUD
@ 2012-08-27 16:35       ` EVS Hardware Dpt
  2012-09-01 21:36         ` Wolfgang Denk
  0 siblings, 1 reply; 6+ messages in thread
From: EVS Hardware Dpt @ 2012-08-27 16:35 UTC (permalink / raw)
  To: u-boot

Yes it could be software driven, but it's much more complex to manage and
error checking could be even more complex.

Anyway, I've implemented the protocol and it's working properly. As it's
used for internal testing, i'm not forced to make source code available, so
this issue is closed.

Thanks for your answers,
Fred.

2012/8/27 Albert ARIBAUD <albert.u.boot@aribaud.net>

> Hi EVS,
>
> On Mon, 27 Aug 2012 17:07:42 +0200, EVS Hardware Dpt
> <hardware.evs@gmail.com> wrote:
>
> > Hi Albert,
> >
> > Yes, I could, but the purpose of my protocol is to be software driven
> > and not human driven. Also error checking is extremely important when
> > testing boards.
>
> Not sure I get you there. The netconsole is just a way to access the
> U-Boot prompt from the network; commands can be input on this prompt,
> and results from it can be processed, by a human or machine alike.
>
> > Regards,
> > Fred.
>
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

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

* [U-Boot] Add a new protocol
  2012-08-27 16:35       ` EVS Hardware Dpt
@ 2012-09-01 21:36         ` Wolfgang Denk
  0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Denk @ 2012-09-01 21:36 UTC (permalink / raw)
  To: u-boot

Dear EVS Hardware Dpt,

In message <CAEDiaShw4=4PX98fq_z-fqezQTMX+kqWyDXjWkr=pdoaw1EfdA@mail.gmail.com> you wrote:
>
> Anyway, I've implemented the protocol and it's working properly. As it's
> used for internal testing, i'm not forced to make source code available, so
> this issue is closed.

GPL will hit as soon as you distribute any binary containing this
code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Too many people are ready to carry the stool when the piano needs  to
be moved.

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

end of thread, other threads:[~2012-09-01 21:36 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-21 16:27 [U-Boot] Add a new protocol EVS Hardware Dpt
2012-08-25  5:16 ` Albert ARIBAUD
2012-08-27 15:07   ` EVS Hardware Dpt
2012-08-27 15:54     ` Albert ARIBAUD
2012-08-27 16:35       ` EVS Hardware Dpt
2012-09-01 21:36         ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox