chwe

I prepared (last weekend? - don't remember anymore) a first step towards a merge of rk3399 (currently nanopi boards) with rockchip64 (more or less all the rest) so that both can be covered fully under one boardfamily (rockchip64). Patches are adjusted and dts support for nanopis in ayufans kernel is done as well. https://github.com/chwe17/build/tree/rk3399merge I would happily give it into 'someone others' hands cause time in the next month might be really rare. Basically it needs testing on the boards which got newly merged into rockchip64 (don't own any nanopi *4 board so I can't test it). And probably a small helper script to adjust the 'living' boards config so that they'll get updates in the future from their new boardfamily (this might be tricky and needs for sure a lot of testing, to ensure we don't break them) Would be nice if someone can review it and test it on the nanopis

it is, the difference is.. You don't have to think about outdated compilers on your base system.. There was a time when I compiled a few u-boot/ kernels without the buildscript for the BPi R2 (during the time.. this thing actually produced more headache than output) wasn't 5.0 back then.. but well.. it's been a while since.. that's a starter for the manual patching (and a few follow up posts): otherwise for those being lazy.. you can download patches from github (in fact every commit).. Just add '.patch' to the commit in the link... e.g.: https://github.com/Icenowy/linux/commit/716da86219368781107a5c4fcf205b7973d3dba5.patch then keep in mind that our kernel/u-boot sources are git repositories as well so you can just git apply blablabla.patch (sometimes force - doing this during build with create patch = yes) and then fix the rejections and armbian will take care that a new patch is created after its which is hopefully without any rejections at all. In case it doesn't have any rejections from the beginning, just place it in the right patchfolder and you don't even have to care...

hmm okay this one got a bit more political than I thought.. Take it with a grain of salt well it was more in the context of the link below: https://www.vpnmentor.com/blog/report-millions-homes-exposed/ always reminds me about Clive: we don't even master oil derricks.. So probably humans are the wrong species to handle the amount of this 'new oil' as we currently do..

well.. you probably get answers which are in favor of armbian on armbians forum.. I would go for Debian and install omv. either via armbian-config or directly download the OMV image (which is based on armbian): https://sourceforge.net/projects/openmediavault/files/OMV 4.x for Single Board Computers/ I use it on my HC1 since beginning with it and it works quite well. Never tried Hardkernels images.. so I can't say much about them. Kernelwise both are based on HKs 4.14 kernel.. except a few patches, there won't be much a difference.. Userspace might differ.. don't know how HK crafts their images.

and it will never go ready as long as there's no 'starter'.. VW needed dieselgate to take a 'serious' engagement towards e-cars.. And I'm not a 100% sure if you're right here: you don't here any characteristic two-stroke engine sound anymore here... So it somehow works.. not in europe not in the US.. but somewhere else. ______________________________________________________________________________________________________ https://www.vpnmentor.com/blog/report-millions-homes-exposed/ I guess we'll see this more and more..

from: https://www.friendlyarm.com/index.php?route=product/product&product_id=254 I don't see where you get here the 'desktop PSU.. You just need a decent 12V PSU with the right barrel plug..

well soldering doesn't look that bad.. once I figure out where my PSU for the w2 is I can provide you a bootlog... might need some time.

did you check it's not a cable issue (maybe your rockpro64 usb3 isn't as tight as the one on your notebook. It can be a software issue.. just check the hardware possibilities as well.

@Mathias, congrats to your new role.. somehow similar I got mod here.. Well, my interest in your project is minor.. and just to be clear. I don't claim that there aren't any software bugs for USB3 on those boards (I simply don't know it). But a driver/DTS issue might be hard to debug (depending on your kernel experience - at least for me it would be). Whereas troubleshooting hardware related bugs might be easier. I assume it's the one provided by pine in their store? From what I heard (and this is mostly @tkaiser review of it) It should be one of the better choices. looking into schematics.. USB should allow at least 5V/1A on each port as long as the PSU can deliver it (http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf p3). Did you check dmesg if there's some obvious errors. E.g. losing link multiple times during heavy load or try the same adapter on an USB2 of the RockPro this would nail it down to USB3 (software or hardware - cause powering for those are the same on the RockPro).

that's why it's a good starter.. we had even issues in getting the board booting with upstream u-boot. are you sure it's an software issue? Could also be bad SATA-USB enclosure (assuming that's what you connect to USB3) and or bad powering..

If you read through the topics in which @tkaiser did those optimizations, you hopefully got that you need to monitor power-consumption after adjustments to see if your changes have an impact or not (best practice here is then to check consumption with PSU, not after PSU). IMO I don't think that the overall mainline support is ready to yet for such tweaks cause H6 is wip, but feel free to spend your time with it. What's the goal. reduce consumption but it will be anyways 'wall powered' or do you try to make a battery powered solution? is set by u-boot see as far as I remember.. you would have to recompile a custom uboot and freeze it. depends on used PMIC (so which H6 board you have) would need proper testing to ensure it's working reliable. Further not 100% failsafe that every H6 SoC behaves the same (e.g. I assume there aren't many people around knowing how constant the h6 SoCs are in their capability to lower cpu voltage --> should be in the DT so you can test it). Not sure if the GPU nodes already landed in DT, check it. HDMI is porbably there.. but you may have to check if it makes a difference, (e.g. test if https://github.com/armbian/build/blob/c8319a2740146e3106051f9206b5ba1a45306752/patch/kernel/sunxi-dev/board-h6-add-orangepi-one-plus-and-lite2.patch#L137 =disabled is already sufficient). If it's for educational purposes (e.g. learning a bit about u-boot, kernel & DT), go for it.. if you really want to optimize stuff I would wait until kernel support is more mature). Make sure that for your use-case it actually has an positive impact (e.g. monitoring consumption over time and compare).

going through the links spotted something for @martinayotte (and maybe @TonyMac32) https://github.com/archlinuxarm/PKGBUILDs/pull/1691/commits/dfe2881b2eaf32a5b2289005c675888345684fd7#diff-2347b909a334e35e45d31e5bb4961a3f there's a a patchset for upstream u-boot for the ram part.. as OP says it's not running stable.. but at least they got upstream u-boot up.. maybe worth a look as well.. to clean the rk u-boot mess asap.

Never used a suite for that.. mostly tools.. and those depending on what I want to test.. (e.g. simple cpu-burn isn't a bad thermal tester). Are you currently on RCs for your rockpro? Didn't this guy just hit mainline? http://lists.infradead.org/pipermail/linux-rockchip/2019-April/023867.html ram on rk3399 is a painful story and the main reason why we have two boardfamilies here.. one based on upstream u-boot (rk3399), and one based on bsp u-boot (rockchip64). Yours is part of the second.. [off-topic] @Igor you need something to laugh..

well.. there are some 'nice words' in swiss-german I think there's not really a good translation for it.. but basically.. No way in hell that I would study applied mathematics.. But if he likes it.. go for it... I don't think that we have to many good mathematicians around.. you would laugh how often I see solitaire open on one of the open access machines for some analytical chemistry devices... Problem here.. there's no decent structure editor opensource.. and most software for using other devices is either windows or for a few cases unix (well they also compile you a linux version now.).

well I think the extra bucks for 16gb in my small notebook was worth it.. And normally projects I load aren't that heavy so that it works decent... But for most of the stuff I do, Notepad++ is sufficient.. Well since I don't do in tech but in science.. It's not really 'as inclusive' here.. Most people here in biology or chemistry do bachelors, masters followed by 4years PhD (and if you want to be in a 'big company' in research + 2 years post doc). Means roughly 10-12 years after high-school.. Being pregnant and you won't enter a lab anymore (it's also an insurance thing).. Assuming that you don't want to start your working (after university) career with getting pregnant in the first year.. don't plan to have kids before being ~33.. Or take a break in your PhD or postdoc.. and lab-work is often not really compatible with a normal work day (e.g. experiments/reaction which should be monitored but having a duration of 10-16hours.. including set-up such a reaction, you can easy spend 'a bit longer' in the lab..) Assuming we want to make it more inclusive. Do we organize a kindergarden which has 'enlarged opening hours' or stop such experiments at all.. Or is it no longer expected that 'besides your normal working day' you should spend some extra hours.. As a famous example: Is this really an issue or not? Actually it would be an interesting topic to discuss, but one wrong word and you got the jackpot of being a shitbag across the whole internet..

well I'll have a look into why it happens and if we can avoid it. But maybe it had some rational behind it you never know. I don't want atom as root.. as smart as I am I would probably kill somehow my entire ubuntu partition.. and since I don't follow recommendations.. it's not a virtual one.. with other productive stuff on it.. Do what I say not what I do.. Cause it's the news diet chat.. Remember the guy from google they fired cause he said something like women and men are different? (well that's a bit buzz-wordish, in fact he wrote a document about biases which somehow leaked...) Well now microsoft has also employees which may think different compared to their employee.. https://qz.com/1598345/microsoft-staff-are-openly-questioning-the-value-of-diversity/ Things get complicated now.. cause it's not a men, it's a women sharing her opinions. She has some rather taff comments there: I'm curious how this one is going for her assuming that it's kept in the news for a while..

well is it really cheaper? Assuming the 2gb ram is really a requirement: Board: 35$ Reliable USB-Sata bridge: 10$ you save roughly 5$.. Depending on other requirements, the HC1/HC2 has a lot more horse power and a proper casing solution which is still missing if you opt for the rock64.. If encryption is important maybe a ARMv8 might be a better choice. But then I would probably opt for a RK3399 (support not 100% mature yet) but decent mainline support and more options to bring up SATA than with a RK3328 (and the price for the cheaper RK3399 are quite okay)..

notepad ++ for windows and atom for armbian (on ubuntu).. problem is.. when creating patches.. the whole kernel repositories are root:root which makes editing in it uncomfortable.. @Igor a rational behind it?

well.. that's one which you can solder without trouble.. @TonyMac32 would probably say I'm wrong.. but I would tin the first pad, press the SPI nor on it and remelt it.. once you have an anchor pad.. the rest is easy..

maybe the one soldered on the BPi W2? It's a winbond 25q128jvsq from the few pictures I found online there seems to be a reference design part (likely some sort of pmic related stuff) where it should be possible.

hmm interesting https://github.com/torvalds/linux/blob/e53f31bffe1d552f496b674cd1733658a268e177/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi#L58-L65 seems to be not default in mainline as well as in megous: https://github.com/megous/linux/blob/e22caec8c77183c5a54d332d55d9af53283ebb68/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi#L58-L65 going quickly through our patches doesn't show an obvious one here as well.. Just add @martinayotte

The point of the discussion is to ascertain whether the board is truly dead - which I believe it is and that's the point.. using a volt-meter to see if power is still on the important powerlines lines with your normal powering setup.. in case yes.. connect the UART and look if you get an output.. in case the main powerrails are dead.. the board is for sure dead as well..

That's my point - nothing makes it work - it's dead  and what's the exact point of this discussion? so, reason behind using uart instead of HDMI etc. is that uart is 'a way more talky' in case things don't work properly anymore.. whereas initialization of HDMI needs more things properly working.

normally just power it the normal way and only connect GND, RX and TX works quite well for accessing the debug UART...

there's your first point to check if your board is still alive (there should be also an debug uart on the m4).