Jump to content

chwe

Members
  • Posts

    1432
  • Joined

  • Last visited

Reputation Activity

  1. Like
    chwe got a reaction from gounthar in Where to build Armbian in the cloud?   
    doesn't need to be an i7..  i5-2500k, 8GB DDR3 ram and a decent SSD (samsung evo).. besides the SSD, this system is around 6-7 years old and builds images in 10-20mins (depending on 'cachelevel'). Even on my 5 years old i5 notebook (i5-3317U with 4gb ram) I'm able to build an image in 20-30min. Both machines work obviously with native ubuntu without doker etc. (not recommended)
     
    Edit: the first build on my shitty notebook will take a way longer... probably 2 hours.. 
  2. Like
    chwe got a reaction from JMCC in Next major upgrade v5.60   
    Fork it now and then stabilize it..  
     
    Actually I would prefer to get all RK SoCs under one hood. So, when we're able to get RK3399/RK3328 and RK3288 properly working with Ayufans kernel. Well then there's simply no reason to stay with the RK kernel. Okay there's no ISP1 driver  but this thingie doesn't work properly anyway (as soon as we think about DTBOs , I keep my rk default branch 'as is' in case we try it once again to get the ISP working without break everything else). 
     
    Reducing 'supported kernels' without dropping boards sounds good.  Might make sense to move this discussion to here? 
     
    Let me know when you want things from here moved to it.  
  3. Like
    chwe got a reaction from gounthar in What about Google Home   
    So the easiest way for me (others might do it differently) is:
    Fork the project on github clone your fork create a new branch on top of master for the stuff you want change switch to your branch in config-default.conf e.g. for my BPi R2 development  LIB_TAG="bpi"  
    Set create patches to yes:  CREATE_PATCHES="yes"  
    During build the buildscript says you when you've to make the changes. Test your new image and when it works as expected copy the generated patch to the corresponding patchfolder and rename it meaningful Test if it still works there and doesn't break any other patch (for your patch this will be unlikely but just make sure to follow 'good practices' from the beginning, it saves you and the maintainers time as soon as you create patches which may have the potential to break something). Push your new branch to your fork and create a Pullrequest against Armbians master branch where you describe what your patch does, the output of armbianmonitor -u (they may see stuff errors which came up with your patch which you didn't recognize). Why do I create branches on top of master and don't change things directly in master?
    Simply due to lazyness... In case my PR doesn't get accepted I don't have to play the git-ninja  I just remove the branch and sync my masters branch with armbians repo. As long as my master doesn't have any changes to armbians, sync is everytime fast forward means I don't create useless 'sync commits' which then confuse the armbian maintainers when I create a PR. For sure, when I'need longer for patching something (e.g. the BPi branch), I may have some sync commits in it but not for 'the short ones'.
     
    Why test two times?
    Just to make sure it doesn't break things. Armbian for sunxi has a bunch of patches this enhances the chance that your patch can break something, so better try your best to avoid it. You can't test everything, but test what you can test.
     
    Why use "create patch"?:
    You could also create patches in a different way.. But this way is known to work mostly without issues. Armbians current patches are applied before yours get applied so you work 'on top' of armbians patched kernel. So if you've to find a proper name for your patch you might check which patches touch the files you touch with your patch and make sure that your patch gets applied after them. Sometimes it also works the other way around but it's IMO not 'good practices'. 
     
    FYI: You may also switch to EXPERT="yes"  in default-config cause you'll build a dev image.  It may be also worth to just build an image without any changes before you start. Just to ensure that the build works as expected on the board. Saves you some headache if your changes don't boot anymore and you realize after its that the build was anyway broken at the moment... 
  4. Like
    chwe got a reaction from gounthar in Burn ISO Image to Micro SD Card   
    That's why the four (five) questions:
    Did you test the SD-Card with h2testw/f3? Did you use etcher? Describe us the powering situation? please report 'sudo armbianmonitor -u'? (show us the serial output during boot) come up on more or less every question which sounds a bit fishy. 
    Feelings and beliefs is the way people solve ~90% of their problems (90% was randomly chosen by feelings )... Similar to 'works for me' and 'I do *random thing* since 20 years so don't say that my approach is outdated since 19 years!!!' 
     
     
    I would suggest it with every hardware. It's just a question of time. Do you figure out immediately that your problem is related to 'faulty SD-Card' when it happens? When not, what needs more time? The few seconds each time to start up etcher for burning an image or the time to figure out that your card was corrupted since beginning (including the time you wasted to set up your system on top of an error you could avoid by using an appropriate tool)? If yes, fine do it. But don't expect that others are willing to look into problems you have when you don't follow the recommendations. 
    My SD-Cards for development aren't perfect (e.g. I use some old slow 4GB cards during testing). Mostly cause my best SD-Cards (SanDisk A1, known fast EVOs) are in the SBCs which run productive. My 'feelings' say that the BPi-R2 isn't that picky when it comes to SD-Cards. It 'seems' that the board works fine with them. Obviously, this can go wrong and then I have to blame my self for wasting my time. But cause this is during development and it would mostly waste my time and not others I'm fine with. During development, I burn a bunch of images but even then it's IMO not worth to switch to an alternative writer than Etcher (even when it uses more time due to crappy old SD-Cards), simply cause my development is also driven by 'feelings'. So, when a test-image doesn't work due to 'burn image went wrong' I may come to the wrong conclusion. This might drive my development in the wrong direction only cause I saved 2-3mins by burning an Image. Armbian shrinks the image to an appropriate size, you don't have those 8GB garbage Images as other 'distributions' have. So burning and validating took anyway less time. Is it worth to save some minutes more by use a 'dumb' image writer? IMO no. 
    I've a dumb bash script which checks my SD-Cards on a OPi Zero connected via a USB card reader. What it does is simple: It mounts my card, formates it, tests it with F3 and when it succeeds the GPIO with the green LED is toggled if it fails, the GPIO with the red LED is toggled. So I don't even need 'a real computer' during development to check my SD cards regularly to 'ensure' they're still okay... 
     
    'Everybody' believes that he doesn't use crappy hardware...   Read through this one: https://forum.armbian.com/forum/31-sd-card-and-power-supply/
    Most of them thought in the beginning their hardware was appropriate.. Sometimes hours of nailing down the problem showed that they were wrong. 
     
    That's what bug reports are for.  I don't know how the etcher.io team reacts (simply cause I never had a reason to report a bug in their repo). But if you can show them that the same setup (e.g. same Image, same SD-Card, same card writer etc.) writes a working Image with win32DiskImager but not with etcher, they may be interested in knowing that.
     
    BTW @tkaiser etcher also provides a CLI tool, at the moment marked as experimental (https://etcher.io/cli/). Do you have any experience with it? Is it worth a try? I've some automated buildstuff in mind (e.g. that my freshly compiled image gets written to an SD-Card automatically after build and I can go for a coffee and everything is prepared to test when I come back). 
  5. Like
    chwe got a reaction from gounthar in What about Google Home   
    the router is still questionable..  Due to shitty performance. There are some ideas to 'solve it' but all of them seems to be hacky... and not really wanted. But when you're driven by a need, this board might be fun.. 
     
    Why not? The board is basically here: https://github.com/armbian/build/blob/master/config/boards/orangepioneplus.wip
    E.g. The OPi One Plus has the same RTL8211E PHY attached as the PineH64. @Icenowy added support for this PHY for the pineH64: https://github.com/Icenowy/linux/commit/66ae9ca01bd3d7f111952ff60f8eef782e6151c1
    I'm not sure if just adding the DT-Nodes in 'sun50i-h6-orangepi-one-plus.dts' is sufficient to get it working.. But could be fun to get Ethernet working on this board, would make the board a way more usable. 
     
    FYI: this patch was added for the pine H64, but I don't know if and how well it works there (as said, I don't follow H6 development close enough): https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/board-pine-h6-pine-h6-0035-arm64-allwinner-h6-add-support-for-the-Ethernet-on-P.patch
     
     
     
  6. Like
    chwe got a reaction from gounthar in What about Google Home   
    Now you've to decide which 'pet project' you choose.  
    Personally, I don't think you should buy the SBC which needs most testing.. You should buy one in which you're interested. Debug & testing can be boring so at least the product you test should be interesting (for you). Therefore I don't recommend a specific SBC, maybe SoCs which (I think) are interesting makes more sense.
    RK3399, a bunch of boards are coming up, armbian just starts to support those boards. The 'overall' sources situation seems to be good in terms of documentation for the SoC and kernel sources. I'm not fully familiar how evolved u-boot (e.g. ram initialization, spl etc.) is. Drawback, they aren't that cheap (you've probably add a bit of money to the money you get from your colleague). RK3328, relatively cheap and powerful IO (e.g. USB3). Overall more evolved as the rk3399 but for sure still work to do. Just for fun: MT7623 - only cause I'm working on it . Only me works (sometimes) on this SoC, at the moment, only one board is widely available (BPi-R2) rumors are ongoing that other boards will show up, but I don't have much information here. Kernel is pure mainline and u-boot is very outdated (v2014). But as @tkaiser pointed out, this might also be one of these boards which don 't make that much sense, mostly cause there's only one board with the SoC available at the moment. In case more boards show up, it might get more interesting due to its decent mainline support.  Allwinner H6. Bloody edge, seems that after @Igors first commits there aren't many people interested in contribute to the related boards (I don't follow it close enough for a proper statement here).  
    It probably makes more sense when a developer presents one of his ideas/projects for armbian and you decide if this is interesting for you and if you want to join it. Some of these projects might be hardware depended others might be more generic. Your skills and/or topics you might want to dive in should also be considered (when I started with the MT7623 I had neither 'much' knowledge in the buildscript, kernel and u-boot but you'll learn things partly on the fly as long as you've a high frustration barrier  don't expect that you make everything right in the beginning ).
    Not to forget, documentation and/or tutorials are also always welcome. Show one of your project you deployed on top of armbian. 
  7. Like
    chwe got a reaction from gounthar in What about Google Home   
    I agree that the board is boring.. Most thingies with only one dedicated job are boring. They need to do one job good but not more. In this case, get more information from the user for googles databases.. 
     
    I partly disagree on your second point due the following reasons:
    Starting motivation is mostly driven by personal needs/abilities. I want to achieve something or I have this hardware and want to step into this 'low level stuff'. Starting with a boring board may save you from 'pressure to deliver'. Nobody cares when you fail with a 'boring board' whereas people can be really annoying when it's a board of interest. Why, why, why does *random feature* not work. From my own experience: The BPi R2 was/is mostly fun cause nobody cares.  The tinkercam was/is annoying cause people ask on a monthly base why this shitty thing doesn't work (in fact it would work but it breaks to much stuff to implement it at the moment).  'We' horrible fail in giving 'easy tasks' to beginners. There's a bunch of stuff which can be enhanced in armbian but a beginner may need some 'guidance' either to identify such a task nor guide/help them during this problem solving of such a task. I think this is mostly related to lack of time. Guide someone in the beginning will cost more time than do it on your own. Sometimes it's worth the efforts cause the one you guide will contribute after its on his own, sometimes it's not worth the efforts cause she/he will disappear after one 'sub-project' and you have to deal with code you've only reviewed, not written on your own.  Funnily we help a lot of people building their own 'pet project' or solve issues they have 'on top of Armbian'. But in the gray area between maintainers and end-users we somehow suck in supporting those people which may contribute more than one PR in the future. That's why I encourage people to try things even on 'boring board'. It may not help armbian in the beginning but hopefully the one or the other will learn some stuff to contribute after its to more interesting boards and/or more important tasks. Will it work? Is it worth? I've no idea...  Fact is, we support to many platforms/SoCs/boards for the current 'team of devs'. So we can either step down and support less boards or we try to encourage more people to contribute to the project. I'm not sure if this approach will work, but at least @JMCC could benefit from my experience with u-boot when he started to play with the renegade, wasn't IMO that a bad deal for the armbian project to help him with some basics in the beginning (u-boot is painful when you deal with it the first time). 
  8. Like
    chwe got a reaction from gounthar in What about Google Home   
    It was clear enough..  I just see it more from a use-case side. Those 'google home boards' have IMO one interesting feature, microphone arrays. The interesting feature of a microphone array is voice to text applications. From what I know, such voice to text stuff is a way harder than things like image detection stuff. Mozilla has an opensource project (https://voice.mozilla.org/en and https://github.com/mozilla/DeepSpeech/) in this field but most others are closed. IMO, I don't see a reason to support google by buying their thingie just to put something opensource on it. But everyone is free to decide if it's worth or not. We don't live in an opinion dictatorship. 
    If you see it as a learning experience, why not? It can be fun (and pain) to get things working on a new platform. You learn a lot of stuff during such a 'pet project'. But as @tkaiser said, the Armada 1500 family is spread on a bunch of different SoCs, so the next problem you'll run into it will be to educate 'your testers/users' on which google thingie your Image will work and on which it doesn't. And the same that Armbian suffers from: why does *random feature* not work properly? Try it, write about your progress and your questions. I'm sure there are people here who will give you some hints when you fail.  
     
  9. Like
    chwe reacted to trebor in Nanopi K2 and a Waveshare 7 LCD HDMI (C) display   
    Thank you for your help. It will take a lot of time. But I'm not giving up yet.
  10. Like
    chwe reacted to tkaiser in Librecomputer Renegade RK3328   
    The latter. That's the main difference between @ayufan's attempt and mine. And no, haven't had a look at the patch failures and am currently away from any build host... or to be more precise from the SSD carrying the VM and all the cached stuff:


  11. Like
    chwe got a reaction from WarHawk_AVG in Powering through micro USB   
    Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
    Basics:
    It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

    The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

    Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
    Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
    How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

    Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

    Illustration 1: AWG print on cable
    Example:
    If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
    *this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
     
    Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

    Figure 2: Voltage drop of a copper cable at various thiknesses
    If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
     
    Case Study:
    Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

    Illustration 2: Setup vor measurement
    FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
    Table 1: Specification of the tested chargers

    Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
    Table 2: Tested micro USB cables

    Results:
    After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

    Figure 3: Voltage drop at delivered current of all chargers
    Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
    All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

    Figure 4: Voltage without load, with load and on output and @powerbank
    .
    Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
    Conclusion:
    What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

    Illustration 3: Recommended powersource
     
     
  12. Like
    chwe reacted to mboehmer in Thanks for the fish!   
    Hi guys,
    some months ago I implemented an Odroid C2 as readout controller for a scientific instrument.
    Lot of people were kind and helped me with some problems with Armbian, especially eMMC and PWM.
     
    Today, finally, we managed to have our instrument (two strings with several Odroid C2 and other stuff) deployed.
    It is sitting now at 2628m depth in the Pacific Ocean, and will go operational the next days.
     
    Here we are... I think I can announce the deepest Odroid so far (cry loud if I'm wrong :) )
    In the picture you just can see the Titanium housing with two glass covers attached to the string.
     
    Again, thanks for the fish :)
     
    Michael

  13. Like
    chwe reacted to tkaiser in ODROID N1 -- not a review (yet)   
    Today nobody (outside Hardkernel) knows for sure whether they use S922 (other SoC vendors like HiSilicon exist also) and nobody (outside Amlogic) knows for sure which CPU cores are inside S922
  14. Like
    chwe reacted to jernej in NanoPi K1 Plus + Armbian   
    I just tested 1080p on my development linux branch which consist of linux-next at next-20180515 tag and R40 HDMI patches and it works fine (startx gives normal xfce desktop). However, rootfs is pretty old (year or so old Armbian), so it might not be representative.
     
    I don't have 4K screen...
     
    Coincidentaly, I just received a notification 5 minutes back, that WIP A64 HDMI patches breaks HDMI on H3. Please note that those patches miss some important things and please don't consider them if you don't want complaints from users (it works in some cases). I know what needs to be fixed, but since Jagan started on that, I will just provide reviews.
  15. Like
    chwe reacted to hjc in RockPro64   
    RK3399 is supported by mainline u-boot.
     
    I changed BOOTSOURCE to https://github.com/u-boot/u-boot.git and checked it on Firefly-RK3399. It runs pretty well, even better than Rockchip u-boot (2017.x). It's running with good USB & ethernet support, booting OS flawlessly.
    I'm already running some heavy services on NanoPC-T4 so not rebooting them, but I assume it works basically the same.
     
    Playing around with u-boot:
    DDR Version 1.12 20180518 In Channel 0: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB Channel 1: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA17AA1, stride = 0xD OUT Boot1: 2018-04-08, version: 1.12 CPUId = 0x0 ChipType = 0x10, 217 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=29820MB FwPartOffset=2000 , 100000 mmc0:cmd5,32 SdmmcInit=0 0 BootCapSize=0 UserCapSize=15193MB FwPartOffset=2000 , 0 StorageInit ok = 80087 LoadTrustBL No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0x90f40 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 19:40:58, Jun 11 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 U-Boot 2018.07-rc1-armbian (Jun 19 2018 - 00:14:04 +0800) Model: Firefly-RK3399 Board DRAM: 3.9 GiB MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... OK In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Firefly-RK3399 Board Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 => => => usb start starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Hub, USB Revision 2.0 - USB 2.0 Hub [MTT] - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x1a40 Product 0x0201 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 100mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms 3: Mass Storage, USB Revision 2.10 - SanDisk Ultra USB 3.0 4C530001240422114145 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5595 Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered 224mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 => dhcp ethernet@fe300000 Waiting for PHY auto negotiation to complete........ done Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 Abort =>  
  16. Like
    chwe reacted to gprovost in Helios4 Support   
    @nemo19 Ok no need to look any further, you found the issue. There should be a thermal pad between the CPU and the Heatsink as shown below. Without the thermal pad no proper heat transfer can happen, therefore the CPU might have reached above Maximum Junction Temperature (115C) resulting by it to get unstable and crash. I'm really sorry about this missing thermal pad, this should definitively not have happened, I will report / complain to the company that handled the board assembly for us.
     
    FYI the thermal pad dimension we are using is 20x20x1mm.
     
    Please provide me by private message your complete shipping address. I will send you this missing thermal pad. In the meantime you can try using thermal paste, even though the gap between CPU and Heatsink is a bit too big for thermal paste.
     

  17. Like
    chwe got a reaction from hjc in Firefly RK3399 support efforts (potential csc board?)   
    small hint:
    by disable https://github.com/hjc4869/armbian-build/blob/58af252c2b7c3acb6160f7ea456c56ef8f7412b6/config/kernel/linux-firefly-dev.config#L50
    you should get rid of the 'g42568f34-dirty' in your kernel naming. 
  18. Like
    chwe reacted to AndiH in Next major upgrade v5.60   
    Hello,
     
    I did again some testing with the actual Nightly builds on an Odroid HC1, and detected an issue - the DNS name resolution doesn't work properly.

    Reason is that the configuration file "/etc/NetworkManager/NetworkManager.conf" now contains a line "dns=None".  After just deleting this line from NetworkManager.conf, it works fine - and NetworkManager is updating "/etc/resolv.conf" accordingly.

    (Note: with "dns=none", the DHCP client ("dhclient" resp. "dhclient-script" would have to take care of the "resolv.conf" update - but that script gets never called, as "dhclient" is started with the -sf option, and will instead invoke the NetworkManage "nm-dhcp-helper" component).

    I found the issue trying the following images:
    5.46.180602_Odroidxu4_Debian_stretch_next_4.9.103
    5.46.180602_Odroidxu4_Debian_stretch_dev_4.14.47
    5.46.180530_Odroidxu4_Debian_stretch_dev_4.14.44
     
    It was fine (i.e. "NetworkManager.conf" does not contain the "dns=none" line) in:
    5.44.180506_Odroidxu4_Debian_stretch_next_4.14.39
    5.45_Odroidxu4_Debian_stretch_next_4.9.99 
     
    So must happened somewhere in between ...
     
    Andi.
     
  19. Like
    chwe reacted to zador.blood.stained in Armbian-Stretch and IR-Remote?   
    If we are talking about connecting IR receiver to any GPIO (and not using a dedicated GPIO pin and an in-SoC CIR decoding HW) then it should be enough to use this which requires the appropriate kernel drivers, RC keymaps and DT modifications (since we don't have overlays support there yet).
  20. Like
    chwe reacted to Igor in Daily (tech related) news diet   
  21. Like
    chwe reacted to TonyMac32 in How do I use the camera on tinkerboard?   
    Current list of things to fix before I'm looking at Tinker cameras:
     
    -Mali
    -Touchscreen
    -device tree overlays
    -Tinker S hardware monitoring (voltage and headphone plug, eMMC availability with the jumper in recovery mode)
    -Meson64 stuff for other boards that I also help maintain.
    -something that will certainly require attention before now and then
    -cameras that only work with 1 board.
  22. Like
    chwe reacted to TonyMac32 in How do I use the camera on tinkerboard?   
    Well, we're not a free resource for other people's projects in this specific of a context.  What you're proposing would easily double the workload I put into a side project that does not pay my bills, simply so you can have something for nothing, so they say.  I'm not trying to be rude, but I don't have time for every user's pet project, Once I get the latest Rockchip updates stabilized I may spend some time on getting the ISP driver working, or I may not, but that will be the limit, is to get the hardware to a functional level.  Any special or new functionality is outside of the scope of what I have time, resources, and in some cases knowledge.
     
     
    And you think a loosely affiliated group of programmers doing this for their uses and enjoyment can?
  23. Like
    chwe reacted to Igor in Orange Pi Zero, dev kernel does not see expansion USB ports   
    When it is done is done. Armbian is not a professional service and we have no particular interest nor resources to deal with this function. A project is open and if this is your pain, you are welcome to join and try to move patches from NEXT to DEVelopment "today". 

    Next kernel is planned when upstream 4.17.y - 4.18.y changes in the area of particular interests are significant enough to move forward. Anything else is unpaid education or throwing resources straight into the trash bin.

    Perhaps 2-3 months?
  24. Like
    chwe reacted to JMCC in Exynos 5422 (Odroid XU4, HC1, HC2) Media Testing Script   
    The UN-official, UN-supported, UN-timely, UN-derrated...
    Exynos 5422 MEDIA TESTING SCRIPT
     
    Yes, the script is somewhat untimely, because it comes when including kernel 4.14 in Armbian next images is getting troublesome. And underrated, because this old SoC seems to be losing the focus of attention in favor of some more modern powerful ones. But it is still a great SoC, and it is worth trying to get the best out of it.
     
    The script will provide the installation of all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL,VPU decoding/encoding acceleration through MFC, and GLES 3.1 / OpenCL 1.1 support.
    It will also install two media players (MPV and Kodi stable) and FFmpeg, all of them using VPU acceleration.
    Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple).
    Two additional small packages, that have no big interest from the developer prospective, but I find them interesting to play with: Support libraries for commercial web video streaming (tested with Netflix), and a simple Pulseaudio GTK equalizer using LADSPA.
     
    Since all the features require the 4.14 kernel to work, the script will also give the option to install an archived 4.14.43 Armbian kernel, in case some other version is detected in the system. Of course, the best option is to use armbian-config to perform a kernel upgrade, but we are providing the archived version just in case the 4.14 packages disappear temporarily from Armbian repos.
     
    Also, this script can be tailored for desktop or headless installation, by selecting the appropriate options in the main menu.
     
    Here is a more thorough documentation:
    >>> DOWNLOAD LINK <<<
    Instructions:
    Download the file above
    Untar it: tar xvf media-exynos5422_1.0.tar.xz
    cd exynos5422
    ./media-exynos5422.sh
     
    Notes:
    This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
    Enjoy!
  25. Like
    chwe reacted to Igor in Stale packages on apt.armbian.com (sunxi-next)   
    No, that is not possible.

    When you install your own kernel, you have to freeze kernel updates in armbian-config to prevent updating from our repository.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines