chwe

there you go.

some combination just don't like each other... Sometimes for no reason.

@ayufans u-boot doesn't have RAM defined in DT (compared to other RK3399 boards). I don't think this kicks in that early, but it was the first thing I saw by compare it with others... Notebook died today, so I'm out for a few days... Looks you're still in 'ATF world' but ATF is still a mistery to me.. 😂 did you check/compare atf sources as well?

As far as I can see, the BSP doesn't look that bad actually.. DT is a bit messy opi.dts --> rk3399-excavator-sapphire.dtsi --> rk3399-sapphire.dtsi --> rk3399.dtsi so linked through a bunch of DTS to sport everything populated on the board.. the u-boot opi_defconfig is in fact a .config not a defconfig.. but you can extract the few bits you actually need (e.g. UART for debug, the rest looks mostly generic). The images are built with Rockchips build script, as far as I can see with their generic binary blobs for ram and their u-boot fork. Not really polished but ok-ish. They have a bunch of wifi/bluetooth binaries maybe they're crap, who knows.. Same chip as firefly.. so we could likely reuse those drivers.. and crappy GbE sounds likely like bad RX/TX settings in DT. cause they came untouched from the rk3399-sapphire.dtsi so, this would me my first bet to fix the problems.. But still don't get my board booting.. (the tv box, not that people think own a OPi Rk3399)

does it end somewhere here? RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 19:47:19, Sep 13 2018 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: plat_rockchip_pmu_init(1089): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 so shortly before it enters u-boot?

I assume still the same box as in the french thread you which was hidden? So it should be this one: HooYL Smart TV BOX Amlogic S905X Box Android 6.0 Quad Core 2G / 8G Ultra HD 4K

cause all boards are still wip. and a polite remember pinned on top what development sub-forum means.

looks like the same one I use mostly.. Never had issues with it.. (be aware, there are a bunch of fake FTDIs, actually mine was to cheap to be an original one but it works.. ) check if it's set to 3.3V (I don't know if 5V can fry it but I wouldn't test it) replace the wires (unlikely but who knows) from the wiring it looks correct but check it again connect RX to TX on the FDTI (without a board) start putty and type some chars.. if both LEDs blink up every-time the FDTI should work. (then it messes somewhere else) sounds like an SD/powering card issue, even when you verified that the cards aren't corrupted if boot/no boot isn't reliable... can be used for adding code into a post.. you don't need to make print-screens, just copy paste the the console output.. and it looks 'mostly' well formated.

shouldn't vlan exactly solve such issues/concerns? I think it needs a vlan capable switch as well.. No idea, never spent much attention to VLANs. do those MT7621 boards get regular kernel updates? Otherwise this would IMO be a bigger security issue. I've no experience in MIPS world.. Only an old ASUS router and it was just the wrong device.. Isn't it a kickstarter board? or the company goes bankrupt and a new one tries it.. Or the cut support for a board which doesn't sell well.. Try and error? until you find a board which sells good. Or it's not needed to make profit in the first years/months. I think the R1 had issues with the switch (never owned one, you may ask other or use the search engine)? R2, never saw someone who reached GbE speed with mainline.. at least I didn't. W2 no idea, it sits there since a few weeks but I didn't have enough time to dive into the adventure (there are still a bunch of open questions for the board/SoC - mainline is more or less non existing, let's give it some time to see where it ends). you've a x86 2GbE server vor <50$? or just reuse an old one? Power-consumption for a 24/7 system should also be considered. Thought about a ARMADA A388 based one? e.g. ClearFog Base? Funnily complaining about software/hardware support but then setting a price-tag which is IMO a way to low.. Support is only for free when people waste their spare-time.. Otherwise it's part of a support contract or gets added at initial board-price.

@TonyMac32 and I worked on a odroid2meson (on my fork) branch to merge those families and drop odroid c2 3.1x kernel, unfortunately we both haven't a odroid to test it.. I would prefer a 'before drop' release tag. the idea is, if somebody wants a board kept alive he can drop in before all the patches related to a board are outdated ('forced' contribution). Cause IMO board-related patches (for eol, csc) which fail should be sorted out in a 'cold folder' (so that the information doesn't get lost, but it reduces also the amount of patches we have to maintain) off topic yes, but not unimportant IMO.

as far as I can see, the same wifi chip as for the firefly is populated on this board.. so by using the same drivers, and ensure it's properly defined in DT chances are high(er) that it should work 'as expected'. Using the same kernel as @hjc used for the firefly.. GbE is also the same, then it should be just adjustments in case DT definition changed slightly.. And if it performs badly: https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test well you've to be in case you want to give it a try.. I'll only help you.. build and test is then up to you... I prefer to mess with DT rather than fixing then broken things after the image is created.. From the sources, this is mostly a reference board with a few additional stuff populated (http://vamrs.com/sapphire-excavator).. There's not much an reason why things should not work. doesn't need years, DT is good enough described in the documentation to learn it..

If your OPi RK3399 is still there and you want to build an Image with armbians Buildscript, I may give you some hints what's needed to bring it up.. Doesn't mean the board gets ever 'official' armbian support. I had a quick look into the sources.. I don't think it's that hard to build an image based on it. Cause I've a RK3399 based TV-box which 'boots with Xunlongs Android' I've a look into the sources anyway.. The sources provided by Xunlong aren't that bad actually.. They create a Image based on rockchips buildscript, so sorting out the missing bits to transfer this to Armbians buildscript looks not that hard. You would still have to build the images on your own and do the testing (no guarantee it works reliable).. But I assume one kernel and one u-boot patch will be sufficient for some testing.

doesn't need FEL, bootorder for H3 is SD-->NAND-->SPI if I've it right in mind.. The print-screens from the opi-zero image show clearly that he's booting armbians 2018 u-boot.. But without the 16GB 'ROM' the most interesting part of this board IMO disappears.. A 16GB eMMC 2GB RAM box with an acceptable wifi chips for 30 bucks in an nice looking case could be interesting. NAND and XR819 makes it rather uninteresting (at least for me)..

not sure.. I'm doing in science.. My normal workplace looks like that: messing with u-boot and kernel is 'just a hobby to waste time'.. quite a lot, see: I learned a lot with it.. I don't get the point here.. lets sort out 3 a-c a) you flash their provided image without even thinking about but you think this differ from they flashing the image? They don't create a special image for you.. they just flash their stock os but if they do it, they can ensure that everything is done correctly. So where is the security issue here? It's yet their image and if they flash it it will be their image as well b) why not? If the description how to flash an image is correct you can simply download it as well and flash it.. If this doesn't work, it's either you doing it wrong or b there are software/hardware issues with the board/image. But if they burn the same image and it works then without issues, then chances are high that it is an operator issue.. c) see b but I don't see a bigger security issue if they flash it or you flash it.. If you don't trust in their images well.. then it doesn't matter if it's they or you who flashes it.. that's how trade inside the EU works.. As said not en expert here.. but chances are high that such return agreements with countries outside the EU aren't covered by this law. That's why I'm buying all my SD-Cards locally even if they're ~2-3x the price compared to online, I simply don't want to deal with refund in case they don't deliver what they should (e.g. A1 rated cards). An aliexpress pro tip: if you cover issues with your product, open proactive an dispute it can be closed if your problem gets resolved but then you're in the power-position. Now you can't open an dispute anymore and it's not as easy to get an refund.. A clear NO here (it's not my job to study European law - and the 'do your research'-trend you get from everyone online is something I simply ignore, I can be wrong on the law part that's why I'm clearly point out: I'm not an expert on this, but if you want to convince me then show it, otherwise I'm quite confident that this law doesn't involve import from outside the Union). I don't complain, if you think you're right there you go: https://ec.europa.eu/info/live-work-travel-eu/consumers/resolve-your-consumer-complaint/european-consumer-centres-network_en Is it annoying when a board doesn't do what it should? Indeed it is.. But the review thread is the wrong place for complaining about refund issues, it's the correct thread to share your experience with badly working wifi or GbE, the rest is just ranting towards the seller and has not much to to with the board. 'LEAVE FEEDBACK' on aliexpress or a short annotation here would be IMO okay. I tend to ignore sentences which start with 'in my x years..' sorry for that, but it worked better for me. So a free offer from my side.. If you still have the board (or did you send it back?), and you don't care to waste a few other hours with it, I happily waste a bit of time trying to get familiar with the buildscript to build your own image with armbians buildscript, doesn't involve any sort of 'official armbian support'. It's just me giving you some hints here and there. Obviously you need an x86_64 buildmachine running ubuntu (or a virtual box) on it. No guarantee it will work better after its.. well the RPi3B+ and its add-ons is probably the wrong example: they had to lower throttling temperature cause some boards didn't run stable 'GbE over USB2' was such a nightmare that @tkaiser set them all to fast ethernet for OMV images the PoE Hat seems to be a nightmare too: https://www.theregister.co.uk/2018/09/11/raspberry_pi_poe_hat_issue/ undervoltage without the special 'RPi microUSB charger' must be considered as default not as exception but that's me being cynical..

this statement is in conflict with: so what else can they offer in terms of 'bringing up' your device, as far as I understand European law (and I'm not a lawyer nor really interested in it) a 'free refund' is 2 weeks, actually the same time you can open a dispute on aliexpress (not sure anymore I mostly order garbage there where a refund isn't worth the efforts ).. The board has no hardware defect so it's either a users fault or a software issue right (if software is covered as well good night for cisco )? I can understand that they don't take responsibility that it works properly if you flash the image on your own.. we do it neither and it ends quite often here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ or should end there cause 'issues magically disappears after change the SD-Card'. you don't trust that they flash an Image but you trust in their Images? cause you would anyway flash one that they provide.. So where's the difference? Expect a shady add-on only for you? It's up to you how you call them, but don't expect that such posts don't get recognized by the boardmakers some of them read here as well threads related to their products and this might have an impact on their goodwill. If and that's a big if (cause I've no clue here) the Union has regulations for international (outside EU) purchasing and warranty then you're free to do so.. well if returned already then it's to late to have fun with a board bring up.. @hjc pointed you back in august what's needed bring it up.. from back then: you'll learn it trust me. And if it's only copy pasting together a DT for your boards u-boot, then it's not much efforts to learn it.. DT in kernel and u-boot are similar mostly just wipe out everything not needed.

interesting that they want to dive into the Intel world.. Well I assume it's less work to maintain (e.g. just fire up a recent ubuntu and you're done no hacky arm digging in u-boot or kernel ). CPU reminds me to the old AMDs 10/15 years ago where you always had to be afraid to kill it by mounting the cooler (kill one of those small caps on it and silver thermal paste was the standard so shorting was also an option ). A nice homeserver/NAS thingie for those who don't want to deal with arm. They planed funny cases.. e.g 'iteration iv': but consumption looks IMO impressive (I've to admit, I've no clue how much recent intel low-level CPUs normally need - my last intel was a 7'' atom tablet with 16GB ram and a crappy display for 40$ on discount the tablet collects dust and the USB charger is used to power an OPi Zero - they sent it with a good powering cable )

@pbies this is a review thread for the board, not a 'rant thread' towards your refund problems with the seller. I assume you bought it over Aliexpress? They have a button called 'OPEN DISPUTE' that's where such stuff should be solved. Then you can mention that you're not happy with the refund policy of Xunlong. For the software side, understandable that they're not willing to solve your issues if you go with your own/custom rom. Similar to routers/smartphones/*fill in random device* they normally refuse any support as soon as you touch "the firmware". Indeed you're right that wifi and GbE should work 'as promised' with the stock "firmware". If this would be true for all SBCs Armbian would be a much smaller project. Towards Ubuntu 16.04 is outdated, LTS Ubuntus get updates so at least for the userspace related part this shouldn't be much an issue as long as the repositories are properly configured. For the kernel, different story, keep them updated is a bunch of work keep them updated is a bunch of work. Doesn't happen for most of your android phones (at least the cheap ones), doesn't happen (often) for SBCs cause it's a support nightmare (every-time Armbian breaks boards from users due to kernel/u-boot update everyone shows up here to complain). You need infrastructure (e.g. your own repository) and a lot of testing (and even then it fails sometimes). If you don't trust the boardmakers software at all, you shouldn't buy hardware from them... I don't know if any distributions currently support this board, but if they don't build and maintain the kernels, chances are high that they simply use the kernel, uboot, atf provided by the boardmaker and stick over their rootfs. As a shady hacker I would likely hide in the kernel where I can hide such stuff a way easier than in userspace.. Armbian differs here, you see where our sources came from, and if you don't trust us you can clone the repo check the code and build it on your own (then you only have to trust the debian/ubuntu package maintainers - and if this isn't an option as well you can build them on your own as well gonna be a lot of sourcecode checking then).. As far as I've experienced RK3399 is failsave (you can mess um eMMC and simply re-flash it with RockChips flashing tools - xunlongs manual mentions this too in the documentation for their board) - nevertheless no guarantee from my side that this works, my experience with RK3399 is rather low at the moment, it's up to you if you brick it.. They also provide a 'Linux 4.4 SDK' so I assume most of the things needed will be there (e.g. DT). ATF, ram binaries used etc. then follow @hjc's firefly thread to get a clue how to bring up an RK3399: They even share the same wifi GbE chips (just a quick look), so this stuff should be possible as long as there aren't any hardware flaws which can't be fixed. So the situation for firing this thingie up is actually not that bad.. It's just nobody interested in doing the work. Likely cause nobody has it.. IMO it's a weired mix of a evaluation board/SBC but that's my personal opinion here.. I'm sure you can make something interesting out of it (e.g. fire up the TC358749XBG and make a nice little opensource HDMI recording box out of it.. last time I had a look into RKs kernelsources the needed drivers were there.. even with DT description how to achieve it but not my field nor of interest to me). So you can either complain more and let it collect dust or you make something useful out of it cause: at least they're honest.. I assume you didn't bought it in the Union and therefore they simply don't care (and don't have to) - but I'm not familiar with EU's law - we're not part of it..

https://github.com/Icenowy/h3-arisc-shutdown untested and no experience on it.. I think even @Icenowy gave up? 24/7 works fine fore me.. I think it idles lower than 700mA (actually I should check it)...

mhmm no.. the picture of your dmesg output shows it get's recognized.. I assume @martinayotte uses those CP thingies too.. And somewhre there should also be a CP one here.. but it's like your house keys, once you've more than one they get lost.. well voltage drop can happen over the cable you use (it looks thick.. but who knows if it's just a bunch plastic or some thick wires inside.. You can connect a 'small consumer' (e.g. wifi stick, mouse, whatever you have ) to your powermeter and connect it on your OPi Zero's USB port.. this should also give you some insights how much 'juice' is available on your board.

full card was tested? seems it gots recognized in ubuntu so, there you go: the wiring looks correct. 'should' work. Cause I burned and booted this image multiple times on my orange pi zero. if you own a multimeter, measure voltage between GND and 5V on the pin-header. The RPi can throttle if voltage isn't sufficient, the OPi Zero doesn't recognize it.

Do you really achieve it in productive? The few iperf tests I did in the past were rather annoying and sometimes confusing.. See results in this thread.. I would be interested in some 'real' numbers here. Crypto 'should' be there with 4.14 but at least with 4.19 there should be an LTS which doesn't need any many backports (except wifi, which I'm not willing to patch in, there's a mPCI slot for those who want wifi on this board and I've a 3T3R wifi card which should run with the brcmsmac driver --> not tested yet!). That's why I decided to drop 4.14 fully. It simply didn't make much sense for me to stick to 4.14 as long as nobody uses it productive (I can fix my mistakes on my own board, so as long as I'm the only user, I don't need an LTS Kernel). I planed to stick stick next to 4.19 and Dev to mainline (cause the kernel isn't patched heavily this is possible, it's unlikely that patches will break that often) in the future. never had problems with SD-Cards.. I normally go for the qualitative ones and my SBCs don't get that much hammered (Armbians defaults help here as well). But yeah, It's simply not done yet. Need to be done but it wasn't of high priority yet. depends on your skills.. (e.g. bash, kernel, u-boot) Let me know in which topics you want to dive in and we will find some nice topics to solve. Currently 'under construction': upstream u-boot (boots, but not yet automatically fires up the kernel - some parts of armbians buildscript are here in conflict), a recent bootscript is missing after the change to upstream - it worked back then with the 2014 u-boot but it was just a quick and dirty hack - upstream u-boot should be a good point to solve this properly. 'nand-sata-install' (not touched yet, I assume it will need some tweaking with the boot binaries) thermals & opp (they look rather conservative and go down to 98MHz, first trip starts at 47°C). some testing would be needed if this can be enhanced. testing, testing & testing. I simply have not the time (and spare equipment) to do it on my own (e.g. USB3 is only tested to the point it works, performance is untested, SATA worked back then but the SSD for those tests in now used productive and I don't have them spare just for testing). And I only own a 1.2 board, no idea how they differ. kernelconfig is 'it works' probably a bunch of stuff is missing yet (crypto stuff 'should' be there) You've to build images on your own. Armbian doesn't offer Images nor do we offer kernel-updates over the repository (e.g. apt upgrade will only update ubuntu/debian related stuff, no u-boot, no kernel). This won't change in the near future until the bigger issues are solved. I don't prepare a PR of my fork into armbians Repo until I'm confident that the board isn't a 'troublemaker' (e.g. the support efforts for H6 are a nightmare cause it's IMO simply 'not ready yet' - this won't happen with mt7623 ). Even when everything is solved I don't guarantee official armbian-support, it's not only my decision and the fact that this is the only board with this SoC makes it a bit 'problematic' as well (support vs. effort to maintain it). But even when not, maintaining it 'out of tree' shouldn't be that hard (e.g. armbians buildscript allows to pack debs for kernel packages - fire up your own aptly or install them with dpkg -i works fine). My mt7623 branch exists since June and it looks like the first time I've a merge-conflict, quite sure it's a trivial one and it will be fixed over the weekend (without even looking at it, there are only ~2 files where it can be.. ). For sure it will be more fun if it's not longer a 'one man show'..

command used for iozone?

https://forum.armbian.com/forum/29-reviews/ https://forum.armbian.com/forum/10-general-chit-chat/ (e.g. those containing nanopi and a 4 in their name) (not 100% up to date) and: may help you. storage can also be attached via USB3 so you might reconsider this opinion..

If Gozard anyway has a look into the DL page, we may want the Testing flag more obvious. Something like if kernel=testing then second supporting flag color = orange. Which is then in conflict with WIP I know.. For 'us' dealing with support since long time it's obvious It may not be as obvious for a first time visitor.

hmm the numbers looking for me like a magnitude to high.. (at least).. Sure you didn't benchmark your SSD (even then, apple must have nice SSDs in their notebooks )? and/or there's some caching still active (but even then it looks to high for me).