Pi zero development connectivity options

General discussion about anything related to Ultibo.
mark
Posts: 691
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Pi zero development connectivity options

Postby mark » Tue Apr 18, 2017 7:24 pm

I would like to review the log for networking activities and this has led to two points:

1. I made a sed script that removes the -- from all the {--$DEFINE ... DEBUG} lines. This of course covers all logging not just for the network, but I may as well dive deeply while I am here. The question is, is there already a mechanism for enabling all of these defines?

2. I'd like to revisit the idea of capturing all events from the very beginning (viewtopic.php?f=10&t=46&p=3017&hilit=logging#p3017). I intend to achieve this while I'm working on the TSLIPAdapter.

Mark
User avatar
Ultibo
Site Admin
Posts: 1320
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Pi zero development connectivity options

Postby Ultibo » Wed Apr 19, 2017 12:08 am

mark wrote:This of course covers all logging not just for the network, but I may as well dive deeply while I am here.

For two reasons simply don't bother trying to enable all logging.

The first is that is produces an enormous volume of log entries and it will very quickly overrun the buffers that are allocated to the logging thread (LOGGING_MESSAGESLOT_MAXIMUM is 8K by default) so any further log entries will be discarded until the logging thread clears some of the backlog.

The second (and more critical) reason is that logging itself causes code to be executed and you must ensure that no debug logging entries are generated by the logging itself or you end up with an endless loop. So if logging is being done via serial port then UART_DEBUG and SERIAL_DEBUG must be off, if logging is being done via SysLog then USB_DEBUG and NETWORK_DEBUG must be off and so on. Of course LOGGING_DEBUG also needs to be turned off except when explicitly trying to debug issues with the logging subsystem.

There are also some defines that change fundamental low level behavior, for example enabling IRQ_DEBUG, HEAP_DEBUG, THREAD_DEBUG or others will change the locking behavior of the heap manager in order to prevent deadlocks, most of these are only there for debugging low level issues with those subsystems when other options are not available

To debug a driver or single unit then it is best to enable just the specific logging options related to that unit in order to keep the amount of log output to a manageable volume, while developing new drivers I always put a temporary $DEFINE at the top of the file to enable debug logging for that driver, if I need to debug into the interactions with other units then I enable those as required in the GlobalDefines.inc file and rebuild the RTL.

mark wrote:The question is, is there already a mechanism for enabling all of these defines?

Not really, the idea is that if you need to enable one of them you do that in GlobalDefines.inc and then rebuild the RTL. Remember that these defines change the code generated (mostly by adding logging in many places) and therefore are not something that you would want enabled in normal operation.

mark wrote:I'd like to revisit the idea of capturing all events from the very beginning

Something we do need to make possible is to enable serial logging very early in the boot process, currently if I start serial logging as the very first item in the project file then the output will be from about the 300-400ms point which is ok but still misses the initialization of some devices. Because serial (UART) is normally a very simple device then it should be possible to support serial logging from quite early in the boot process.

Note that you can see the milliseconds timestamps in the log by enabling the new LOGGING_INCLUDE_TICKCOUNT option in your program.
Ultibo.org | Make the future
https://ultibo.org
Gavinmc42
Posts: 872
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Pi zero development connectivity options

Postby Gavinmc42 » Sun May 28, 2017 11:08 am

Oz Pi disty has sent me a Zero W, should arrive tmr.

That will give me a spare W, for a total of 4 x Zero's 1.3+
Decided it was time to learn these tricky little things.

Got this compiled and working on my Linux PC
https://github.com/raspberrypi/usbboot
It is doing stuff, finds the Zero and downloads bootload.bin, start.elf etc files to the Zero and then it just sits there doing ????
Not sure what it is doing, start.elf is a different size than the normal 2.8MB one.
It does look for an autostart.txt file, what ever that is.

Got a helloworld kernel.bin and stuck it, bootload.bin, start.elf (normal one) and put them on a SDcard and it booted fine.
So a Zero really only needs the three files.
The C source is there which helps, if you know Linux C coding :?

Use a Zero for I/O RT controller for other Pi's?

Got the Cluster Hat for a camera system but this Linux Zero USB stuff is very confusing.
Ultibo only needs the Kernel.bin so much easier to use to figure out this USB boot mode.
That's what I thought, but I'm doing something wrong.

Mark, did you figure it out?
viewtopic.php?f=10&t=308&p=1239&hilit=Zero#p1239
Further Zero stuff here
viewtopic.php?f=14&t=526&p=3303&hilit=Cluster#p3303

At the moment I want to get the normal Zero's working.
So I can use the Cluster hat for trying USB mode Zero's and using the Pi3 for the Ultibo IDE.
Gavinmc42
Posts: 872
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Pi zero development connectivity options

Postby Gavinmc42 » Mon May 29, 2017 7:17 am

https://www.raspberrypi.org/forums/view ... o#p1128941

Leads to this
https://github.com/raspberrypi/target_fs

InitramFS???? This is what in latest piCore config.txt for the Zero
initramfs 9.0.gz followkernel
kernel kernel4922.img
cmdline cmdline.txt


I think InitramFS is new in 4.9

Cluster Hat version of USBboot
https://github.com/burtyb/usbboot/blob/master/main.c

Really glad I'm moving to Ultibo, this Linux stuff is confusing :lol:

I think the USB boot start.elf must load and setup a compressed ram file system before loading kernel?
Gavinmc42
Posts: 872
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Pi zero development connectivity options

Postby Gavinmc42 » Mon May 29, 2017 9:01 am

mark
Posts: 691
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Pi zero development connectivity options

Postby mark » Mon May 29, 2017 11:28 am

Gavinmc42 wrote:...
Mark, did you figure it out?
viewtopic.php?f=10&t=308&p=1239&hilit=Zero#p1239
Further Zero stuff here
viewtopic.php?f=14&t=526&p=3303&hilit=Cluster#p3303
I haven't pursued rpi usb device mode since I split my app into host and device mode editions. The TSLIPAdapter is intended to give rpi0 a path over serial to the network. I haven't worked on that for several weeks. Right now my focus is on qemu, cloud, work flows for testing and also finding and isolating some ultibo anomalies.

For me, the next rpi0 specific work will probably be ultibo-pilot driving tests on an rpi0.

Mark
mark
Posts: 691
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Pi zero development connectivity options

Postby mark » Mon May 29, 2017 11:32 am

Gavinmc42 wrote:Got a helloworld kernel.bin and stuck it, bootload.bin, start.elf (normal one) and put them on a SDcard and it booted fine.
So a Zero really only needs the three files.
Are you sure there wasn't a fixup.dat file already on the sd card? I was under the impression that it was required. Mark.
Gavinmc42
Posts: 872
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Pi zero development connectivity options

Postby Gavinmc42 » Mon May 29, 2017 12:31 pm

It works :lol:
Not sure why it did not before, dodgy USB port on PC?

rpiboot needs a folder below it called msd, in that I put 3 files, the normal bootload.bin, start.elf and kernel.bin.
Run sudo ./rpiboot and it loads the files and Ultibo helloworld boots and runs.
Er it's slower than normal SDcard boot time.

I did it three time a row to make sure :D
4 times, 5 times :lol:
I get this message, then rpiboot shuts off and command line is back.

Waiting for BCM2835/6/7
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835/6/7
Second stage boot server
File read: start.elf
File read: kernel.img
Failed control transfer
Second stage boot server done


Next is to get Raspbian/Ultibo on a Pi 2/3 working.
Then cluster hat baremetal :ugeek:
Should be easy to make networked full Ultibo Cluster controller.
Now, how to convert rpiboot C code to pascal?

Bouncing boxes on a 1GHz Zero is smoking 8-)
Someone mention SLIP?
Gavinmc42
Posts: 872
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Pi zero development connectivity options

Postby Gavinmc42 » Tue May 30, 2017 12:20 pm

Moving Zero USB boot loading to Pi3 with Cluster hat

Need to use gpio to turn on power to the Zero, so wiring pi got installed on Raspbian
http://clusterhat.com/setup-control

Had x86-64 error when raspberry/usbboot was compiled then run on Raspbian.
So I grabbed this version and compiled on Raspbian
https://github.com/burtyb/usbboot
It's older so I might have to swap main.c and recompile, will do a diff first.
I do get some messages so it does find the Zero on the USB hub chip on the hat :P .

Ok, there was some difference but still got issues, might be USB related.
Will try using a hub back on Linux, tmr. Will also try without Cluster hat hub, tmr.
mark
Posts: 691
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Network device for SLIP over serial

Postby mark » Mon Jun 12, 2017 5:31 am

Garry, while studying loopback.pas I noticed this expression repeated:

Code: Select all

MAX_ETHERNET_PACKET - ETHERNET_HEADER_SIZE
Perhaps it could be written as a constant MTU?

Regards,
Mark

Return to “Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest