Hi everyone,
I'd like to share with you information that finally I've managed to find out what was the reason of problems with networking on rpi 3b+ which I implemented (with help mostly from Stefan) during Hack'n'Hike.
The important thing that we didn't notice during Hack'n'Hike was that packages that we were able to receive only broadcast messages, so only arp packets were received. That led me to debugging code that was supposed to set MAC address in the driver and after some digging I found in [1] information about a bug (later fixed) in this linux driver that caused not setting MAC address properly in some situations. Applying a change from this patch allowed to have usb_net test working.
In the meantime I've checked that usb_block test also works (although seems to be quite slow) so I think I have generally working the most important devices to start again from the start and polish my work and try to prepare it for inclusion Genode repositories (probably I'll wait for a release).
My current plan is to work on supporting with base-hw:
- rpi3b+ 32bit - as 64bit support is not yet ready and 32bit version does not restrict using of this device
- rpi2b - this one is armv7 so 32bit architecture and with regard to devices it is somewhere between rpi1 and rpi3b+
After discussion with Stefan during Hack'n'Hike I plan to move as much as possible of support for above versions to genode-world repository as Genode Labs plans to support in main genode repository and test: old rpi and new rpi3b (without +) 64bit.
One thing I'd like to get some acceptance is a naming scheme for those SOCs/configurations. Especially for the 32 and 64 bit versions for one SOC. Will it be ok to have following naming for boards?
- rpi3bplus32 (running 32 bit) - rpi3bplus (later; running native for armv8 64 bit instructions) - rpi2b - rpi3b - version that you have and plan to support
Cheers Tomasz
Hi Tomasz,
thank you for giving us an update regarding your efforts.
On Wed, May 22, 2019 at 12:15:17AM +0200, Tomasz Gajewski wrote:
Hi everyone,
I'd like to share with you information that finally I've managed to find out what was the reason of problems with networking on rpi 3b+ which I implemented (with help mostly from Stefan) during Hack'n'Hike.
The important thing that we didn't notice during Hack'n'Hike was that packages that we were able to receive only broadcast messages, so only arp packets were received. That led me to debugging code that was supposed to set MAC address in the driver and after some digging I found in [1] information about a bug (later fixed) in this linux driver that caused not setting MAC address properly in some situations. Applying a change from this patch allowed to have usb_net test working.
In the meantime I've checked that usb_block test also works (although seems to be quite slow) so I think I have generally working the most important devices to start again from the start and polish my work and try to prepare it for inclusion Genode repositories (probably I'll wait for a release).
Wow, that is impressive. You worked tough to enable this tricky USB host controller, congratulations!
My current plan is to work on supporting with base-hw:
rpi3b+ 32bit - as 64bit support is not yet ready and 32bit version does not restrict using of this device
rpi2b - this one is armv7 so 32bit architecture and with regard to devices it is somewhere between rpi1 and rpi3b+
After discussion with Stefan during Hack'n'Hike I plan to move as much as possible of support for above versions to genode-world repository as Genode Labs plans to support in main genode repository and test: old rpi and new rpi3b (without +) 64bit.
that sounds reasonable.
One thing I'd like to get some acceptance is a naming scheme for those SOCs/configurations. Especially for the 32 and 64 bit versions for one SOC. Will it be ok to have following naming for boards?
- rpi3bplus32 (running 32 bit)
- rpi3bplus (later; running native for armv8 64 bit instructions)
- rpi2b
- rpi3b - version that you have and plan to support
I'm fine with your naming scheme. I'll adhere to it when working on rpi3b.
Best regards Stefan
PS: Are you fine when I merge the mini-uart header that you provided via your rpi3bplus branch already to re-use it for rpi3b?
Cheers Tomasz
[1] https://lkml.org/lkml/2018/11/7/860
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Stefan Kalkowski stefan.kalkowski@genode-labs.com writes:
PS: Are you fine when I merge the mini-uart header that you provided via your rpi3bplus branch already to re-use it for rpi3b?
Hi Stefan, yes, of course I'm fine with it.
There are some minor things that probably should be fixed, though. I see at least:
- license header update - some minor formatting issues: indentation and some old commented code - I'm not sure if _wait_until_ready() is ok - busy loop in kernel code? (sometimes I suspected that some exceptions and hangs I had were connected with this function, although I'm not sure)
I would address those isseus before proposing merge but if you need it now then go ahead and make changes you think are suitable.
Regards Tomasz
Tomasz Gajewski tomga@wp.pl writes:
There are some minor things that probably should be fixed, though. I see at least:
- license header update
- some minor formatting issues: indentation and some old commented code
- I'm not sure if _wait_until_ready() is ok - busy loop in kernel code? (sometimes I suspected that some exceptions and hangs I had were connected with this function, although I'm not sure)
I would address those isseus before proposing merge but if you need it now then go ahead and make changes you think are suitable.
Stefan, I've seen you made a commit which renames this mini uart driver in your branch. I've started the cleanup of commits and I'd like to incorporate this rename into my branch to avoid merge conflicts later.
Do you have any objections that I merge this into my one commit for uart driver, or would you like to have it separate (as three: my original, your rename, and my cleanup)?
Additionally - do you have any changes to this driver that you did not push yet that could cause merge conflicts?
I also have one more general question about further processing of getting my changes to genode repositories. I'll cleanup the code and split commits into parts that contain specific features but should I open different issues on github for each of them or one for all changes I made for rpi is enough? I think it would be better to process them individually but as they depend on each other I want to hear your opinion.
Regards Tomasz
Hello Tomasz,
On Mon, Jun 10, 2019 at 12:54:46AM +0200, Tomasz Gajewski wrote:
Tomasz Gajewski tomga@wp.pl writes:
There are some minor things that probably should be fixed, though. I see at least:
- license header update
- some minor formatting issues: indentation and some old commented code
- I'm not sure if _wait_until_ready() is ok - busy loop in kernel code? (sometimes I suspected that some exceptions and hangs I had were connected with this function, although I'm not sure)
I would address those isseus before proposing merge but if you need it now then go ahead and make changes you think are suitable.
Stefan, I've seen you made a commit which renames this mini uart driver in your branch. I've started the cleanup of commits and I'd like to incorporate this rename into my branch to avoid merge conflicts later.
Do you have any objections that I merge this into my one commit for uart driver, or would you like to have it separate (as three: my original, your rename, and my cleanup)?
Additionally - do you have any changes to this driver that you did not push yet that could cause merge conflicts?
I've no objections at all. Please proceed with either your original commit, and mine to be separate or merged. I only did this separate fixup commit, so that it is transparent to you. In the final version on staging resp. master it will be merged anyway.
I do not have additional changes.
I also have one more general question about further processing of getting my changes to genode repositories. I'll cleanup the code and split commits into parts that contain specific features but should I open different issues on github for each of them or one for all changes I made for rpi is enough? I think it would be better to process them individually but as they depend on each other I want to hear your opinion.
I would say: it depends. In general, it is surely better to have separate issues for different features. But if there is a small fix in some let's say irq controller driver, which enables to use the same driver for rpi 1 and 3, it is ok to put the corresponding commit into the same issue here.
Please, feel free to go ahead and incorporate what you want to. If we hit any collaboration problems thereby, we will find a solution together :-)
Best regards Stefan
Regards Tomasz
-
Stefan Kalkowski -
Tomasz Gajewski