Hey Guys and Gals,
So I recently acquired a Clusterboard and wanted to take it for a spin. But no luck so far...
When I tried to start it with a single SoPine inserted nothing happened, so - dismayed - I tried another one and got a response: The lights went on and I got approximately three seconds of Christmas Tree Action. After that: Nothing...
After reading on this Forum I tried a Xenial 3.10 Build and now I get at least a heartbeat on the SoPine I inserted! But still no lights on the switch. Not even a status light on the RJ45 Socket...
Now I am worried that the board might be fried.
Do you have any ideas?
(I'm still waiting for a USB/UART Adapter. Tried it with a DIY Arduino Thingy but that did not work. No UART Signal so far, or none detectable by the Arduino.)
(05-05-2019, 03:32 PM)WhiteDragon Wrote: Hey Guys and Gals,
So I recently acquired a Clusterboard and wanted to take it for a spin. But no luck so far...
When I tried to start it with a single SoPine inserted nothing happened, so - dismayed - I tried another one and got a response: The lights went on and I got approximately three seconds of Christmas Tree Action. After that: Nothing...
After reading on this Forum I tried a Xenial 3.10 Build and now I get at least a heartbeat on the SoPine I inserted! But still no lights on the switch. Not even a status light on the RJ45 Socket...
Now I am worried that the board might be fried.
Do you have any ideas?
(I'm still waiting for a USB/UART Adapter. Tried it with a DIY Arduino Thingy but that did not work. No UART Signal so far, or none detectable by the Arduino.) Alright. It seemed to have bean the network issue described here: https://forum.armbian.com/topic/9402-eth...ne-module/
Logged in via a USB-Network Dongle and applied the fix. Didn't work then though. But the switch switched on the moment I pulled the USB-Network Dongle out of the socket.
(05-06-2019, 06:10 AM)WhiteDragon Wrote: (05-05-2019, 03:32 PM)WhiteDragon Wrote: Hey Guys and Gals,
So I recently acquired a Clusterboard and wanted to take it for a spin. But no luck so far...
When I tried to start it with a single SoPine inserted nothing happened, so - dismayed - I tried another one and got a response: The lights went on and I got approximately three seconds of Christmas Tree Action. After that: Nothing...
After reading on this Forum I tried a Xenial 3.10 Build and now I get at least a heartbeat on the SoPine I inserted! But still no lights on the switch. Not even a status light on the RJ45 Socket...
Now I am worried that the board might be fried.
Do you have any ideas?
(I'm still waiting for a USB/UART Adapter. Tried it with a DIY Arduino Thingy but that did not work. No UART Signal so far, or none detectable by the Arduino.) Alright. It seemed to have bean the network issue described here: https://forum.armbian.com/topic/9402-eth...ne-module/
Logged in via a USB-Network Dongle and applied the fix. Didn't work then though. But the switch switched on the moment I pulled the USB-Network Dongle out of the socket.
What version of Armbian are you using?
(05-06-2019, 11:36 AM)AZClusterboard Wrote: (05-06-2019, 06:10 AM)WhiteDragon Wrote: (05-05-2019, 03:32 PM)WhiteDragon Wrote: Hey Guys and Gals,
So I recently acquired a Clusterboard and wanted to take it for a spin. But no luck so far...
When I tried to start it with a single SoPine inserted nothing happened, so - dismayed - I tried another one and got a response: The lights went on and I got approximately three seconds of Christmas Tree Action. After that: Nothing...
After reading on this Forum I tried a Xenial 3.10 Build and now I get at least a heartbeat on the SoPine I inserted! But still no lights on the switch. Not even a status light on the RJ45 Socket...
Now I am worried that the board might be fried.
Do you have any ideas?
(I'm still waiting for a USB/UART Adapter. Tried it with a DIY Arduino Thingy but that did not work. No UART Signal so far, or none detectable by the Arduino.) Alright. It seemed to have bean the network issue described here: https://forum.armbian.com/topic/9402-eth...ne-module/
Logged in via a USB-Network Dongle and applied the fix. Didn't work then though. But the switch switched on the moment I pulled the USB-Network Dongle out of the socket.
What version of Armbian are you using?
At the moment I'm using Armbian 5.84 Debian Stretch with a 4.19.38 Kernel I built from source. It didn't work out of the box though.
I had to apply this fix described in the Armbian forums linked above.
I figure that the USB Network Dongle was mapped to a lower Hardware ID and the SoPine can only maintain a single network connection, thus the onboard NIC on the SoPine Module was deactivated. I figured furthermore that the switch on the Clusterboard is only powered, when at least one of the NICs on the SoPine Modules tries to communicate with it (I guess some sort of XOR gate controlling V_in or somesuch nonsense).
Since that did not happen due to the network bug the switch stayed "dark".
05-08-2019, 12:13 PM
(This post was last modified: 05-08-2019, 12:41 PM by AZClusterboard.)
(05-07-2019, 02:45 PM)WhiteDragon Wrote: At the moment I'm using Armbian 5.84 Debian Stretch with a 4.19.38 Kernel I built from source. It didn't work out of the box though.
I had to apply this fix described in the Armbian forums linked above.
I figure that the USB Network Dongle was mapped to a lower Hardware ID and the SoPine can only maintain a single network connection, thus the onboard NIC on the SoPine Module was deactivated. I figured furthermore that the switch on the Clusterboard is only powered, when at least one of the NICs on the SoPine Modules tries to communicate with it (I guess some sort of XOR gate controlling V_in or somesuch nonsense).
Since that did not happen due to the network bug the switch stayed "dark".
When I wrote my guide, the LTS was the only one that worked. I've gotten them to fix it since and add nightly builds to the download page. I also see they built a new image as of 5/3 so I'll have to test it out. All the images were working as of 5/3 but I'll have to check the new ones.
I just got both of the 5/3 (Debain and Ubuntu) images to work. I cannot duplicate the problem you're having.
05-08-2019, 04:21 PM
(This post was last modified: 05-08-2019, 04:27 PM by WhiteDragon.
Edit Reason: tenses... always a bother
)
(05-08-2019, 12:13 PM)AZClusterboard Wrote: (05-07-2019, 02:45 PM)WhiteDragon Wrote: At the moment I'm using Armbian 5.84 Debian Stretch with a 4.19.38 Kernel I built from source. It didn't work out of the box though.
I had to apply this fix described in the Armbian forums linked above.
I figure that the USB Network Dongle was mapped to a lower Hardware ID and the SoPine can only maintain a single network connection, thus the onboard NIC on the SoPine Module was deactivated. I figured furthermore that the switch on the Clusterboard is only powered, when at least one of the NICs on the SoPine Modules tries to communicate with it (I guess some sort of XOR gate controlling V_in or somesuch nonsense).
Since that did not happen due to the network bug the switch stayed "dark".
When I wrote my guide, the LTS was the only one that worked. I've gotten them to fix it since and add nightly builds to the download page. I also see they built a new image as of 5/3 so I'll have to test it out. All the images were working as of 5/3 but I'll have to check the new ones.
I just got both of the 5/3 (Debain and Ubuntu) images to work. I cannot duplicate the problem you're having.
That's strange indeed! I tried tried both the Xenial (3.x Kernel) and stable releases (Stretch and Bionic 4.x Kernel) before I built from source but to no avail. The only thing the Xenial (3.x Kernel) provided was a light on the built-in Heartbeat LED. However I did not try any of the precompiled releases with neither USB NIC nor UART (since I did not have a UART to USB dongle at hand as stated in the original post).
I only got the idea to try the USB NIC after I built a Kernel from scratch and reached a point of fair frustration and figured it might work as a last resort before I through the board out of a window, since there are USB NICs listed as working on the Armbian section on the SoPine board. (I can add the Apple USB NIC to that list for what it is worth...)
I never tried the nightly builds though. Maybe that would have worked as well, but I don't know. I try to stay away from nightlies; got some bad memories from Debian Etch on a Fujitsu Notebook back in the day...
When I read that a Kernel built from the master branch sources would work I was delighted, but unfortunately it did not do so for me. After I modified the the dtb file according to the the Armbian Forums thread (there was no line towards tx delay whatsoever in the unmodified version of the .dtb file) it started working, albeit after I pulled out the USB NIC. I cannot fathom if it would have worked if I just pulled out the USB NIC without modifying the dtb file, but I hightly doubt it.
I'm glad that you don't experience the same issues I did, but maybe it's due to a different revision of the board? Mine's a Rev. 2.3. What's yours? I don't have the foggiest as to why I was having these issues and would be glad if the root of the problem could be found, so others won't have to go through the hassle of modifying the dtb file after every update or freeze packages. But as of now I blame it on machine heuristics...
(05-08-2019, 04:21 PM)WhiteDragon Wrote: That's strange indeed! I tried tried both the Xenial (3.x Kernel) and stable releases (Stretch and Bionic 4.x Kernel) before I built from source but to no avail. The only thing the Xenial (3.x Kernel) provided was a light on the built-in Heartbeat LED. However I did not try any of the precompiled releases with neither USB NIC nor UART (since I did not have a UART to USB dongle at hand as stated in the original post).
I only got the idea to try the USB NIC after I built a Kernel from scratch and reached a point of fair frustration and figured it might work as a last resort before I through the board out of a window, since there are USB NICs listed as working on the Armbian section on the SoPine board. (I can add the Apple USB NIC to that list for what it is worth...)
I never tried the nightly builds though. Maybe that would have worked as well, but I don't know. I try to stay away from nightlies; got some bad memories from Debian Etch on a Fujitsu Notebook back in the day...
When I read that a Kernel built from the master branch sources would work I was delighted, but unfortunately it did not do so for me. After I modified the the dtb file according to the the Armbian Forums thread (there was no line towards tx delay whatsoever in the unmodified version of the .dtb file) it started working, albeit after I pulled out the USB NIC. I cannot fathom if it would have worked if I just pulled out the USB NIC without modifying the dtb file, but I hightly doubt it.
I'm glad that you don't experience the same issues I did, but maybe it's due to a different revision of the board? Mine's a Rev. 2.3. What's yours? I don't have the foggiest as to why I was having these issues and would be glad if the root of the problem could be found, so others won't have to go through the hassle of modifying the dtb file after every update or freeze packages. But as of now I blame it on machine heuristics...
The nightly builds are just like building from scratch and won't be much different from the releases mentioned. My board is mounted in a case. I can't see the rev number. I took apart the dtb and it does not look like the delay is in there. I think they might have fixed it upstream. I'm going to rebuild my system within the next couple of days. As far as I know, as of right now, everything should work "out of the box" with the images downloaded from Armbian.
(05-08-2019, 05:46 PM)AZClusterboard Wrote: (05-08-2019, 04:21 PM)WhiteDragon Wrote: That's strange indeed! I tried tried both the Xenial (3.x Kernel) and stable releases (Stretch and Bionic 4.x Kernel) before I built from source but to no avail. The only thing the Xenial (3.x Kernel) provided was a light on the built-in Heartbeat LED. However I did not try any of the precompiled releases with neither USB NIC nor UART (since I did not have a UART to USB dongle at hand as stated in the original post).
I only got the idea to try the USB NIC after I built a Kernel from scratch and reached a point of fair frustration and figured it might work as a last resort before I through the board out of a window, since there are USB NICs listed as working on the Armbian section on the SoPine board. (I can add the Apple USB NIC to that list for what it is worth...)
I never tried the nightly builds though. Maybe that would have worked as well, but I don't know. I try to stay away from nightlies; got some bad memories from Debian Etch on a Fujitsu Notebook back in the day...
When I read that a Kernel built from the master branch sources would work I was delighted, but unfortunately it did not do so for me. After I modified the the dtb file according to the the Armbian Forums thread (there was no line towards tx delay whatsoever in the unmodified version of the .dtb file) it started working, albeit after I pulled out the USB NIC. I cannot fathom if it would have worked if I just pulled out the USB NIC without modifying the dtb file, but I hightly doubt it.
I'm glad that you don't experience the same issues I did, but maybe it's due to a different revision of the board? Mine's a Rev. 2.3. What's yours? I don't have the foggiest as to why I was having these issues and would be glad if the root of the problem could be found, so others won't have to go through the hassle of modifying the dtb file after every update or freeze packages. But as of now I blame it on machine heuristics...
The nightly builds are just like building from scratch and won't be much different from the releases mentioned. My board is mounted in a case. I can't see the rev number. I took apart the dtb and it does not look like the delay is in there. I think they might have fixed it upstream. I'm going to rebuild my system within the next couple of days. As far as I know, as of right now, everything should work "out of the box" with the images downloaded from Armbian.
Can confirm it seems to be a case of machine heuristics... I got a second board and tried to boot it with the "Fix" applied. Does boot, Network works with the USB-Dongle but the switch stays dead when I try to run onboard network.
I've got a UART-Dongle now and if I try to obtain an IP-Adress from within the u-boot console I get this:
Code: ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
[...]
Retry time exceeded; starting again
Any leads? I'm bloody exasperated now...
(05-09-2019, 06:07 AM)WhiteDragon Wrote: Any leads? I'm bloody exasperated now...
I got my system up and running last night. Can confirm everything works out of the box. Something is either broken or not connected correctly. The only advice I have is to try every image here and find one that works:
https://dl.armbian.com/pine64so/
(05-09-2019, 12:29 PM)AZClusterboard Wrote: (05-09-2019, 06:07 AM)WhiteDragon Wrote: Any leads? I'm bloody exasperated now...
I got my system up and running last night. Can confirm everything works out of the box. Something is either broken or not connected correctly. The only advice I have is to try every image here and find one that works:
https://dl.armbian.com/pine64so/
Thanks for your effort. I tried to configure another SoPine Module on the working board and the switch is dead again... it's a brand new board for Pete's sake, so it's either very poor quality or something else is amiss...
|
