-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardware support from mtda for nanopi R1 #105
Comments
The Debian kernel does not seem to be shipping |
It does not seem to exist in 5.10 but may be there in 5.11 (see https://elixir.bootlin.com/linux/v5.11/source/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts) |
so maybe we could pull the kernel from bullseye-backports so we get 5.14 |
@chombourger I just made it to install FriendlyWRT on the device. Since I have now root login I may scan the hardware for you (possibly). This is what I see at a first glance
|
Closes: siemens#105 Signed-off-by: Cedric Hombourger <[email protected]>
Hallo @GuBi34, See if #112 helps The image I built still boots on the nanopi NEO but it now comes with a 5.14 kernel and has the following dtb files:
The u-boot environment of your r1 should have I can provide the image I have built if you'd like. |
Closes: siemens#105 Signed-off-by: Cedric Hombourger <[email protected]>
assigned this issue to 0.15 since we do not have this hardware yet. We will check if we can purchase some in January (hardware donations are always an option and appreciated, simply reach out if you would like to donate to the project). |
issue #40 will become relevant as soon as we have support for the NanoPI R1. The agent would receive APIs to control the Wi-Fi interface: e.g. make ourselves an Access Point |
Various logs provided by Gunther Boot
|
looked suspicious but the error message turns out to be misleading since these are optional IRQ lines |
More concerning is
|
That was the issue. was able to boot a MTDA image on the r1:
will now prepare the pull request |
Closes: siemens#105 Signed-off-by: Cedric Hombourger <[email protected]>
initial support with #123 (thanks @GuBi34 for the board you sent me!) the image was booted from SD. Need to check if patches are needed to support distro_boot (see https://marcin.juszkiewicz.com.pl/2021/03/14/u-boot-and-generic-distro-boot/): this would let us use the same image for either SD or eMMC boot several packages to be added to support BT/Wi-Fi |
2nd ethernet port is also working:
|
Ah. So the device tree is the issue. I also received my R1. Will look into WiFi tonight. |
linux-firmware package is not present. We would need that. |
Wifi module based on broadcom. So brcmfmac driver should ideally be sufficient with the right firmware. I see the driver. Let me put the linux-firmware package and check. |
I would suggest we add BT/Wi-Fi support in a separate PR but yes we probably need to add several packages (we also need the package that ships regulatory.db) |
right. the u-boot binary from Debian does not recognize the R1 and somehow thinks it is a NEO. That's how we got the DT for the NEO loaded :( |
Agreed. I have not decoded the dtb yet. Maybe there is wifi entry. Maybe not. |
Closes: siemens#105 Signed-off-by: Cedric Hombourger <[email protected]>
Modified the wks to boot Linux with |
Programmed the eMMC as follows:
|
@chombourger thanks for the ultra quick support!!! |
Can mtda support the FriendlyArm NanoPi R1?
Rational:
It would be benificial for us to instrument the test device as well with the network environment (dhcp / fixed IP / gateway / proxy ...). This will allow us to call some device APIs from the test dispatcher as well without the need to have a parallel configuration of switches and routers.
As well more than one USB port would be helpful to avoid USB HUBs.
Looking for WiFi devices a local Hot Spot will be a help.
The nanopi R1 seems to fit well. It is thought as minirouter and comes with nice housing options.
https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=248
The text was updated successfully, but these errors were encountered: