[U-Boot] Network based logging with U-Boot
Hello all,
Is U-Boot able to log its actives etc to a machine accessible via the network?
Desirable -> U-Boot being able to log all its boot up info and details regarding booting it's OS image etc (ie everything sent to stdout) to a file on a remote machine.
Scenario - multiple deployments all housed in sealed units on a LAN. Network based monitoring is the only option.
It would be extremely useful if each platform could provide its status over the network so that any problems regarding boot up could be easily seen.
I'm sure I read somewhere that UDP logging is available in U-Boot but information on this doesn't seem to be hugely available.
I've got netconsole running via netcat on a host pc but this is console only and is not ideal for a multi-platform deployment model. Although, saying that, I suppose that doing 'set ncip <server ip>' and 'set stdout nc' and running netcat on a host pc would provide some level of diagnostics.
Is anybody able to offer any advice or strategy here for similar requirements?
Much appreciated.
-- Matt
Dear Matthew Lear,
In message 4A896ED5.3010807@bubblegen.co.uk you wrote:
Is U-Boot able to log its actives etc to a machine accessible via the network?
U-Boot has support for netconsole, if that is what you are looking for.
Desirable -> U-Boot being able to log all its boot up info and details regarding booting it's OS image etc (ie everything sent to stdout) to a file on a remote machine.
Note that netconsole does not output _all_ of U-Boot boot messages; it takes a lot of initialization until the network interface becomes operational, but this is usually only an issue during the port of U-Boot to new hardware. For normal deployment of a known-to-be-working image it's OK.
Scenario - multiple deployments all housed in sealed units on a LAN. Network based monitoring is the only option.
No problem. Use netconsole.
I'm sure I read somewhere that UDP logging is available in U-Boot but information on this doesn't seem to be hugely available.
Well, it's documented. Just read doc/README.NetConsole
I've got netconsole running via netcat on a host pc but this is console only and is not ideal for a multi-platform deployment model. Although,
"not ideal"? What exactly are you missing?
saying that, I suppose that doing 'set ncip <server ip>' and 'set stdout nc' and running netcat on a host pc would provide some level of diagnostics.
Is anybody able to offer any advice or strategy here for similar requirements?
Try to explain what your exact problems with netconsole are.
Best regards,
Wolfgang Denk
Hi Wolfgang, Wolfgang Denk wrote:
Dear Matthew Lear,
In message 4A896ED5.3010807@bubblegen.co.uk you wrote:
[snip]
I've got netconsole running via netcat on a host pc but this is console only and is not ideal for a multi-platform deployment model. Although,
"not ideal"? What exactly are you missing?
saying that, I suppose that doing 'set ncip <server ip>' and 'set stdout nc' and running netcat on a host pc would provide some level of diagnostics.
Is anybody able to offer any advice or strategy here for similar requirements?
Try to explain what your exact problems with netconsole are.
Firstly, perhaps the problems I have with netcat and U-Boot netconsole are partly to do with the 'listener' software itself (ie netcat), running on <server ip>. AFAIK the 'mapping' of netcat to target ip address in order to utilise U-Boot's netconsole is one-to-one, ie netcat is unable to listen on an ip address range because it performs a lookup on the address and this obviously fails for an ip address range. I may be wrong here but from what I can tell, listening on an ip range with netcat is not possible. If it was, then this would solve part of my problem.
Of course, there may be other listeners which may be able to do this..?
Secondly, if there is a centralised logging machine (<server ip>), then ideally, the messages received from U-Boot's netconsole would be prefixed with an identifier in order to differentiate one device running U-Boot from another. The prefix could be a U-Boot env hostname, ip address, MAC address or some other identifier/variable. If this was possible then each platform could be differentiated easily at the server end.
I suppose my end goal is to have something akin or analogous to multiple platforms running Linux and logging over syslog to a server machine running syslogd.
Does that help?
Best regards, -- Matt
Dear Matthew Lear,
In message 4A8A7FA3.2090901@bubblegen.co.uk you wrote:
Firstly, perhaps the problems I have with netcat and U-Boot netconsole are partly to do with the 'listener' software itself (ie netcat), running on <server ip>. AFAIK the 'mapping' of netcat to target ip address in order to utilise U-Boot's netconsole is one-to-one, ie netcat is unable to listen on an ip address range because it performs a lookup on the address and this obviously fails for an ip address range. I may be wrong here but from what I can tell, listening on an ip range with netcat is not possible. If it was, then this would solve part of my problem.
Of course, there may be other listeners which may be able to do this..?
You got the source code. Feel free to implement a lsitener with all the features you need.
Secondly, if there is a centralised logging machine (<server ip>), then ideally, the messages received from U-Boot's netconsole would be prefixed with an identifier in order to differentiate one device running U-Boot from another. The prefix could be a U-Boot env hostname, ip address, MAC address or some other identifier/variable. If this was possible then each platform could be differentiated easily at the server end.
Again, this can be easily implemented on the listener side, as you know exactly where each packet is coming from.
I suppose my end goal is to have something akin or analogous to multiple platforms running Linux and logging over syslog to a server machine running syslogd.
Does that help?
Yes, as it defines your requirements. As it turns out, you need support for additional features on the listener side. From what you wrote I cannot see any changes needed for the U-Boot side.
Best regards,
Wolfgang Denk
participants (2)
-
Matthew Lear -
Wolfgang Denk