TonyMac32

473 should be 47k. The reason for the high value is the parallel nature of the bus. 2 in parallel now have a pull-up of 23.5k. 4 is 11.75k, etc. The lower that number goes, the more current the device asserting the output has to sink, and the slower the falling edge slew rate is. [edit] I answered this from my phone, those pictures you have are 472's so yes, 4k7.

I wouldn't call it dead. ;-). I have purchased one for my personal uses, I haven't gotten it yet, so we'll see.

Well, I think not. As an example, I disagree with most VW design choices, and think their philosophy is quite flawed and would never open a garage to work on them, but I will not refuse to help a friend or acquaintance who owns one of the extremely service-hungry machines.

I had a 10 MB wifi patch going into Tinker with the old kernel, so... Sent from my Pixel using Tapatalk

Well, the images I build won't boot, so that's an issue. Sent from my Pixel using Tapatalk

Building a dev image to test as well, anything in particular I should look for?

It looks like DTB's for m201 exist in @balbes150's work. There will most likely be some more work needed on your side, so read through the thread carefully.

hmmm, that's why I'm a bit confused, as yes, they should have it. Now, if the pullup is too weak the current draw becomes an issue. If you can identify the pullup that might tell the story.

National instruments??????? http://www.ti.com/lit/an/slva704/slva704.pdf I've never met an NI rep older than me. That makes me suspicious. ;-)

Firstly, why on earth pull the heat spreader off? Secondly, Yeah, I agree we wrecked the thread, but cases only serve the functions of "protect sensitive parts" "facilitate operation" and "look good" The last one is preference, the other two important. For me I like the solid aluminum ones with the SoC contact best, but they are impossible to find for every board, so talking thermal is a good place to go.

All images are built in roughly the same way using the same script. I am not aware of any packages missing from Rock64, I believe most of the work is in the kernel itself, not in the rootfs. Now, obviously, everything you personally may desire might not be included, but we use the standard repositories, so if the distro has it for the architecture then it should be available.

That would be helpful, there are hundreds of different sticks out there, the folks who keep the TV box threads going will need that. If it happens to be the same as some other stick someone has hacked, your task becomes much easier. Sent from my Pixel using Tapatalk

Hmm, so they appear to be at different addresses, and due to the nature of I2C I don't think you need to do any particular wiring tricks. Which one shows up when you have them both attached? http://www.i2c-bus.org/i2c-primer/

I don't think that will push them. The s905x destroys the Pi 3. The RK3288 destroys the Pi 3. The RK3328 destroys the Pi 3. The H5 destroys it as well. I've never seen a head to head with an H3, but if anything about USB or networking were involved I'm sure it would give the Pi a trouncing as well. In most conditions it's like putting a 4-function calculator up against a PC running Excel. Sent from my Pixel using Tapatalk

The reason you've not gotten help is that I don't have any of this hardware, and we don't support Stretch yet. Between those two things, we don't have support. A10 and A20 are SoC's from Allwinner. Linux support in general is per processor and board. Some vendors boards are using very old kernels, some a bit newer, most have some reduced functionality in mainline

Same SoC as Pi 3 clocked higher. The only thing interesting at all, but not enough. Same catastrophic design failure as every other Pi. Useless "upgrade" I could do this with any board I currently own, make a PoE board for it. Not at all special. Still goofy firmware nonsense. Well thank God since it was garbage before. Sadly the Pi 3 B+ brings nothing of interest to the table when it doesn't even match competing boards that have been released and available for months to years. Until they move away from the current series of SoC's they won't be of interest. And they won't do that because it would break their compatibility and destroy the only thing they have that is worth note: the homogenous community support situation.

This would best be posted under "tv boxes", and I would recommend you find out what you can about the device (SoC, etc).

That would be great, I'm afraid my script-fu is not up to it. :-/. This is very much a learning experience for me...

Because I like sometimes to do the ridiculous thing simply because I can, I have a NanoPi air thermal epoxied to a Pentium 3 north bridge heat sink. It never gets warm. ;-).

Well, if you go through the menu and create dev packages, that will be 4.16 rc kernel. That should be the "next" environment in coming weeks.

No, it's at 5.41, we're working on 5.42. The kernel/etc can be installed via "dpkg -i" regardless. You can also generate a full image from the build system.

docs.armbian.com lays out the build system requirements, https://github.com/armbian/build Is the repo. To work in development branch use LIB_TAG="development" when you run compile.sh

There's one on my desk, but I haven't officially tested/stressed it. I hooked a fan up to see when it thought it should be actively cooling, under load it still does so regularly.

Yikes. And let's be serious for a second, why wouldn't you use a big copper area you need anyway to move heat? I thought that was normal practice...

You should go back to the 4.14 kernel, 4.13 has a lot of bugs. I will look into the xfs module later today.