retrack Posted January 6, 2021 Posted January 6, 2021 I know that WOL is currently not supported from the thread in kernel 5.x However, the specs of Helios64 showed and still shows that the interfaces have WOL support: * https://wiki.kobol.io/helios64/intro/#board * https://kobol.io under Multi-Gigabit Ethernet section What is missing ? How can we help ?
gprovost Posted January 7, 2021 Posted January 7, 2021 @aprayoga will help answer in details @retrack question on what is the blocker right now to have WoL working on Heliso64. But in a nutshell is because suspend mode is not supported yet properly. I think we all understood that the question is addressed to us Kobol team, no one was expecting the core Armbian team to follow up on this. So let's move on and not hold any grudge against each other...we are only one to blame to not have answer quickly enough this thread. @Igor Maybe we could delete this exchange above, put that being us. 2
retrack Posted January 7, 2021 Author Posted January 7, 2021 Hello, not expecting this, but could have been a bit more clearer in my question. Do we have a * Kobol issue: hardware (like the missing IC connection on the 2.5Gbps for it to work at 1Gbps) or firmware * or an Armbian issue with the linux distribution. I was really just trying to get info if someone has looked into this already and might have been missled by the fact that Kobol/Armbian formed this "club" and this is where we can ask questions on both aspects hardware and software. Now regarding Armbian maintenance work and the cost, a few comments on this: * I do not have a pro usage of Arm (and by extension Armbian or any other distro) yet, currently just playing around and exploring capabilities on a personal basis so "help" also means here filing a proper PR if it is something I can fix. * I have issues with the recent fundraising Armbian did for the build server, and have not participated to it (but also did not debate as I am new here) because to me this is old school and border line regarding governance. Oldschool because a single server somewhere cause a lot of issues and hides the rest of the costs (electricity, internet access,...). A contrario my company today is providing the whole build capacity of OpenBSD ports (10+ servers). It is a shared access to a group of developers, professionally hosted in a secure DC,... It is a win/win situation we offer compute and bandwidth and the community gets better quality. * While I understand the money part of the "help" you are seeking, the page I am being referred to and the 3k/day mention while totally plausible need more transparency in such a community project. Again new here, so maybe I am missing information. For the tone, I will disregard, maybe my question triggered this level of response because of other threads I am not aware of within the forum and impolite users that are asking and never giving back. I hope my answer above brings everything back to a collaborative mode and again happy to look at any options I can provide help at my level.
Igor Posted January 7, 2021 Posted January 7, 2021 23 minutes ago, retrack said: * Kobol issue: hardware (like the missing IC connection on the 2.5Gbps for it to work at 1Gbps) or firmware * or an Armbian issue with the linux distribution. Armbian is all about "Kobol issue", kernel, low level support. I am not saying or judging how big role we are playing in this particular case, but we are supporting them, they are supporting us. In this "Kobol" issue. And Kobol do support us in - I believe - best possible way they can. Armbian is not yet another Linux distribution like Debian, like Ubuntu, like Arch, like Manjaro and many small ones ... which are just using low level support and distribute their distribution. We provide Debian / Ubuntu userland, slightly modified, improved and fixed. But core of the project is build engine. A lightweight "Yocto" / "buildroot" which gives you opportunity to build your own Linux distro. We are focused to ARM single board computers, so you can only build it for those. For hardware that is supported, but its relatively easy to add another supported hardware - if supported in u-boot / kernel. It's just a matter of few config files. But the problem is maintenance - if you don't have it, things surely starts to break down. We tag boards with "supported", where we pay attention and maintain them vs. others, mainly community, random person or vendor only supported builds. They are a part of Armbian Linux as unofficial builds. 32 minutes ago, retrack said: and this is where we can ask questions on both aspects hardware and software. Things are mixed very much but I rather back down. I have enough of other troubles. I only answer on "how to help". We are asking for help - money is not the biggest issue since we are actually having our own jobs and are the core sponsor, but working on common goals. I would like to help with this interesting issue, if you help us with the boring ones and help us to hire help to relieve overloaded and overstressed volunteers or to tell you to just give us a break and stop asking for more ... That's my primary motive of speaking up. 37 minutes ago, retrack said: I have issues with the recent fundraising Armbian did for the build server, and have not participated to it (but also did not debate as I am new here) because to me this is old school and border line regarding governance. Oldschool because a single server somewhere cause a lot of issues and hides the rest of the costs (electricity, internet access,...). A contrario my company today is providing the whole build capacity of OpenBSD ports (10+ servers). It is a shared access to a group of developers, professionally hosted in a secure DC,... It is a win/win situation we offer compute and bandwidth and the community gets better quality. It is a drop-in replacement for one server only. Same internet access, same power consumption. Network access upgrade is also planned, but not an urgent issue. We have several servers around, mainly donated, bare metal and virtualized, but so far nobody provided us better alternative to have dedicated machinery to build lets say 500 images really really fast. And once again and again when things fails ... Thredripper is still the cheapest way. You are welcome to become engaged in https://armbian.atlassian.net/browse/AR-444 We still need to design and maintain our infrastructure and talk with partners in this area. Developing and maintaining this is already a full time position, but currently covered by a few people on a side. 51 minutes ago, retrack said: While I understand the money part of the "help" you are seeking, the page I am being referred to and the 3k/day mention while totally plausible need more transparency in such a community project. Again new here, so maybe I am missing information. It's a sum of unavoidable costs and our work which needs to be done to keep this system running. This is estimated on 50-80 working hours every day. Responding on this is included even I usually would skip sticking my nose into. I can easily blow whole day every day if I react on emails, PMs and few forum posts. Sometimes I actually do ... 57 minutes ago, retrack said: I hope my answer above brings everything back to a collaborative mode and again happy to look at any options I can provide help at my level. No hard feelings, but I have life to catch up and many other problems are on the list so can't deal with this problem, even its appealing from the technical perspective. I am actually a bit frustrated that I am unable to help. 1
aprayoga Posted January 7, 2021 Posted January 7, 2021 @retrack as mentioned by @gprovost, the main issue is suspend is not supported yet. then there is no wol support on realtek PHY driver (1G ethernet). on 2.5G ethernet, the firmware does not trigger interrupt pin. even if it does, it won't work due to the interrupt line pulled by 1G PHY. The interrupt line is shared between 1G and 2.5G ethernet. so it still need Realtek PHY changes. There is another way to use WoL on 2.5G, by using USB suspend mechanism / LPM. but unfortunately RK3399 does not support this.
tionebrr Posted January 8, 2021 Posted January 8, 2021 Thanks a lot@aprayoga Quote on 2.5G ethernet, the firmware does not trigger interrupt pin. even if it does, it won't work due to the interrupt line pulled by 1G PHY. I'm not sure I understand which firmware you are talking about. Is this the firmware on the 2.5Gbit chip? If I understand correctly, the 1G Phy interrupt is not opendrain and is actively pushing up the shared interrupt pin preventing the 2.5G Phy to pull down? Can you share the manufacturer ref of both phys? I would love to take a look at the datasheets out of curiosity. A quick fix might be to scratch the 1G PHY int trace on the board XD
aprayoga Posted January 8, 2021 Posted January 8, 2021 (edited) @tionebrr yes, the firmware on 2.5G chip. The 1G PHY interrupt is open drain but default state after reset the pin is pulled low, i guess there is an interrupt event nack by phy driver. You could disconnect 1G PHY interrupt line by removing D31 but i don't think it would help since the 2.5G firmware does not use the pin. Spoiler Simplified schematic D31 location The interrupt pin connected to GPIO0_B0 on RK3399 Edited January 8, 2021 by aprayoga
tionebrr Posted January 8, 2021 Posted January 8, 2021 Thanks for the answer @aprayoga. Quote the 2.5G firmware does not use the pin Alright this I understand. Too bad for the 2.5G chips... Quote event nack by phy driver This is interesting... I'm a hardware guy so I have no clue about how the interrupt control registers are un-masked by the kernel, and what the suspend procedure looks like. But there is several scenarios possible if the Phy is acting weird with its interrupt pin: The 1G Phy is reset before suspend, which pulls INTB low, which triggers the event, and the driver clears the interrupt before suspending? Is this possible guys?
aprayoga Posted January 14, 2021 Posted January 14, 2021 On 1/8/2021 at 5:53 PM, tionebrr said: Alright this I understand. Too bad for the 2.5G chips... We still trying to get the proper firmware for the chip. On 1/8/2021 at 5:53 PM, tionebrr said: he 1G Phy is reset before suspend, which pulls INTB low, which triggers the event, and the driver clears the interrupt before suspending? Is this possible guys? It is possible but as i mentioned previously, the main problem is the system could not enter suspend, then next problem is no wol support in PHY driver and if i'm not mistaken, there is no support for interrupt mode in PHY driver.
Recommended Posts