Xalius

Members
  • Content Count

    154
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Xalius got a reaction from infinity in ROCK64   
    That is an interesting question, I have one USB3 hub at home, maybe I'll get a second JMS bridge and find out...
  2. Like
    Xalius got a reaction from TonyMac32 in ROCK64   
    I just flashed the first 16MB from my sdcard on the SPI flash and well, it boots :-)
     
    DDR version 1.06 20170424 In SRX LPDDR3 786MHz Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB ddrconfig:7 OUT Boot1 Release Time: 2017-05-18, version: 2.43 ChipType = 0x11, 187 emmc reinit emmc reinit SdmmcInit=2 20 SdmmcInit=0 2 powerOn 702746 Usb re Boot. 6702743 Usb re Boot. 12702748 Usb re Boot. 18702750 SoftReset SoftReset, 19367264 us  
    Miniloader seems to run SPI at 12Mhz, but I guess now the boot image needs tweaking since I dont see any u-boot...
  3. Like
    Xalius got a reaction from tkaiser in Improve 'Support over Forum' situation   
    @chwe, that is a nice idea, I will help with reviewing, but maybe it is better to start a new thread for this?
  4. Like
    Xalius reacted to chwe in Improve 'Support over Forum' situation   
    If they want not read stuff, give them more stuff to read.  I did some tests with cheap USB chargers (bought two only for this test) and cables and thought I would publish it somewhere here in the forum. Cause I knew, that this would give a longer thread I collected all my data in Word (yeah, I'm normally a Windows user.  ) and thought to copy paste everything when I'm finished.  During the collection of data, I thought why shouldn't make something like a 'white paper' out of it? If I jump into a new topic I'm always interested  in application notes or white papers. 
    So, this is a draft (language has to cleaned up and some 'peer review' process should also been done before publishing it) about micro USB and what's to consider when using it. Maybe a set of such 'white papers' with common tasks, mistakes etc. about SBC could be something for armbian?
     
    BTW: I started this test with four USB chargers, the 0.60$ one from china didn't survive the test...

    Powering throught micro USB.pdf
  5. Like
    Xalius reacted to rodolfo in Board suggestion (split from Ethernet config issues)   
    Hi sniffyjaay,
     
    SBCs are not really the right choice for the "Standard things" ( kind of a WIN-$ type desktop with office, multimedia and some python stuff ) you'd like to run on them. A decent desktop experience depends on snappy processing, fast storage, networking, quality display and keyboard/pointerdevice. As the common web experience goes up in sheer bloat smoke, SBCs are just overwhelmed with all the nonproductive bull. A cheap used laptop upgraded with SSD and an ultrafast LXDE-Debian, MACOS or WIN desktop is hard to match when trying to mimick it by turbo-charging an SBC. SBCs are just wonderful gadgets when their strenghts are used. Desktop use stresses their weaknesses. I personally employ them successfully as thin clients and remote desktop servers ( think visualizing IOT )  but mostly use them as specialiced servers, routers, secure cloud etc... Use cases like POS, simple kiosk solutions, low energy stuff all profit from SBC designs, but not the data-gathering slavery tools of big data abusers. Best of luck.
     
     
     
     
     
     
     
  6. Like
    Xalius got a reaction from TonyMac32 in ROCK64   
    Ok, I added a flash node inside the spi node for the flash with a driver that should work since the basic flash commands seem to be the same:
     
    spi@ff190000 { compatible = "rockchip,rk3328-spi", "rockchip,rk3066-spi"; reg = <0x0 0xff190000 0x0 0x1000>; interrupts = <0x0 0x31 0x4>; #address-cells = <0x1>; #size-cells = <0x0>; clocks = <0x2 0x20 0x2 0xd1>; clock-names = "spiclk", "apb_pclk"; dmas = <0xb 0x8 0xb 0x9>; #dma-cells = <0x2>; dma-names = "tx", "rx"; pinctrl-names = "default"; pinctrl-0 = <0x30 0x31 0x32 0x33>; status = "okay"; w25q128@0 { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "winbond,w25q128", "jedec,spi-nor"; reg = <0x0>; spi-max-frequency = <40000000>; status = "okay"; }; };  
    That gives me:
     
    rock64@rock64:~$ dmesg | grep spi [ 1.172285] m25p80 spi32766.0: w25q128 (16384 Kbytes) rock64@rock64:/dev$ mtdinfo Count of MTD devices: 1 Present MTD devices: mtd0 Sysfs interface supported: yes rock64@rock64:/proc$ sudo flash_erase /dev/mtd0 0 0 Erasing 64 Kibyte @ ff0000 -- 100 % complete rock64@rock64:~$ sudo dd if=/dev/mtd0 of=test.bin status=progress 16642560 bytes (17 MB, 16 MiB) copied, 30.0011 s, 555 kB/s 32768+0 records in 32768+0 records out 16777216 bytes (17 MB, 16 MiB) copied, 30.4636 s, 551 kB/s So I guess something works...
     
    Edit: The MTD device hangs at random points during write/read operations, I tried to create an ubi volume for testing purposes, but formatting the flash just hangs during the process...
     
    root@rock64:/home/rock64# ubiformat /dev/mtd0 ubiformat: mtd0 (nor), size 16777216 bytes (16.0 MiB), 4096 eraseblocks of 4096 bytes (4.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 4095 -- 100 % complete ubiformat: 1 eraseblocks are supposedly empty ubiformat: warning!: 4095 of 4096 eraseblocks contain non-UBI data ubiformat: continue? (y/N) y ubiformat: warning!: only 0 of 4096 eraseblocks have valid erase counter ubiformat: erase counter 0 will be used for all eraseblocks ubiformat: note, arbitrary erase counter value may be specified using -e option ubiformat: continue? (y/N) y ubiformat: use erase counter 0 for all eraseblocks ubiformat: formatting eraseblock 477 -- 11 % complete  
    I tried to reduce SPI clock to 25Mhz bus still hangs at random points...
  7. Like
    Xalius reacted to Ian in The new Banana PI M2 Ultra   
    Thanks for the work Armbian do in getting decent secure builds for these little SBC's which have been "caught between a rock and a hard place" (hard place being the CH SOC makers that historically were not interested in supporting these quasi reference boards and the rocks being the backstreet CH SBC makers who have neither the finances nor abilities to support their quasi reference boards).
     
    IMHO unless the SOC makers start to properly support software wise an up to date reference SBC board for each SOC then things are not going to change that much but i think the CH SOC makers have realised that if they can IOTise their business then this can add a shed load of valuation potential and the likes of Allwinner seem to be taking typically CH baby steps in this direction.
     
    I pick up these SBC boards periodically (either as samples from the SOC makers or i buy then as in the case of ODROID) and I received a R40 based BPI and out of the box it didn't inspire confidence (fingerprints/areas of residue in board coating) and the BPI website is just dire (though no worse than many of the other CH SBC's) and its no surprise they have downgraded to microusb power/no emmc to save a few pennies on its BOM - i mean how much does it cost to add an aluminium heatsink to the PMIC + SOC!
     
    I'll keep this little board on the back burner for a while to play around with as the R40 ref. board has a lot of potential as a little low power headless SATA squeezeboxserver its just a pity noone else is using the R40 platform or Allwinner hasn't stepped up to the plate with decent reference board linux source for an up to date kernel/drivers.
     
    i live in hope Allwinner ? while i wait to see what HardKernel's new 64bit platform is like (to replace long-term my lovely ODROID based squeezebox server my nephew has taken off to University with him)
     
     
    ian          
     
     
     
     
  8. Like
    Xalius reacted to giri@nwrk.biz in Armbian on LY-F1/Gooseberry/Topwise A721 [Make old tablets great again]   
    Hey guys!
     
    Cheap Android tablets based on allwinner chipsets were pretty common back in 2012. Recently I found an tablet equipted with an Allwinner A10 SoC (LY-F1) lying lonely around on my fathers desk. He bought that tablet back then because of the cheap price, but never really used it. Luckily my father also saved an Android 4.0.4 ROM he downloaded from the suppliers website back then, because all websites of this supplier are offline now.
     
    After playing around with my OPiZ and seeing how well the sunxi/armbian kernel works, I thounght myself i should try to boot linux from this tablet. At first I tried to pack an image that can be directly written onto the devices 8GB NAND storage, but soon found out that the device tries to boot from SD by default. After doing some research I found out that this device uses an PCB called Topwise A721 which was also sold as standalone board named 'Gooseberry'. This PCB was used in many Chinese Tablets back in 2012.
     
    My next logical step was to burn the only avaiable armbian image for the A10 (pcduino2) and see if it boots. At first I thougth it did not work, because the screen kept blank and the tablet did not give any response, but after plugging the SD card back into my PC i saw that the filesystem was extended to the max 16GB of my SD :). (Hooray, no dissasembly and fiddeling around with UART needed)

    So next I extracted the script.bin (attached to this post) from the android image and replaced it with the symlink on the armbian image. And voila even the screen works out of the box  The only problem I have now is, that I do not have an USB mini OTG cable (I already ordered one) to plug in an keyboard and do further testing. LOL, just found an mini USB OTG in an USB Adapter set I bought some time ago. The desktop environment boots up fine!
     
    The tablet itself has an mini HDMI port, so this may be useful for me! 
     
    Picture of tablet with Armbian login + desktop:
     
    I'll report back when I have done further testing!
     
    EDIT1:
    To enable wireless networking 8192cu has to be added to etc/modules (legacy kernel ofc).
     
    EDIT2:
    Audio works out of the box. 
     
    EDIT3:
    I now added following kernel modules to etc/modules (most of them are loaded on the android image too!):
    This should enable GPU HW acceleration, enables the touchscreen of the tablet and the touch keys.
     
    Touch key info:
    Scancodes:
    BACK: 10x02, 0x82
    HOME: ^[0x01, 0x81
    MENU: 20x03, 0x83
     
    Keycodes:
    BACK: 2
    HOME: 1
    MENU: 3
     
    EDIT4:
    Things I could not get to work:
    camera module (missing kernel module? gc030809 or wrong I2C address?)
    Volume HW keys.
     
    EDIT5:
    Cam somewhat works with cheese after changing gc030809 to gc0308 in script.bin (Yeah silly me, its because cheese tries to use OpenGL rendering.)
    Cam works pretty nice with mplayer, making fotos using fswebcam also works!
     
    EDIT6:
    I made working configurations for the armbian build system (files attached!).
     
    EDIT7:
    Configs are upstream, but not officially supported
     
    EDIT8:
    I am currently working on an tablet optimized image.
     
    Awesome how nearly everything worked out of the box! Armbian on this tablet outperforms the original android image by far!
    Moral of the story, check any old chinese tablets lying around and make them great again using linux
     
    script.bin
    linux-topwise-a721-default.config
    topwise-a721.fex
    topwise-a721.conf
  9. Like
    Xalius got a reaction from TonyMac32 in ROCK64   
    I have a short update on the latest patches RK sent to BSP upstream. As of this morning we have a Rock64 image that doesnt lock up anymore  after 20 minutes and ayufan found a hotfix for the GbE issues by turning off tx-offloading (no TX/RX paramters tuned yet) and that seems to work well at least for him (930Mbit both directions) with one CPU core loaded since integrity calculations are now done on the CPU. Currently we boot the 2GB and 4GB with one firmware loader at 768Mhz DRAM frequency. The u-boot patches to autodetect DRAM size seem to work so far, havent heard back from someone with a 1GB board yet. RK also should push a DRAM init blob for 933Mhz soon...
     
    https://github.com/ayufan-rock64/linux-build/releases - new images and deb packages for system upgrade
  10. Like
    Xalius got a reaction from tkaiser in ROCK64   
    I have a short update on the latest patches RK sent to BSP upstream. As of this morning we have a Rock64 image that doesnt lock up anymore  after 20 minutes and ayufan found a hotfix for the GbE issues by turning off tx-offloading (no TX/RX paramters tuned yet) and that seems to work well at least for him (930Mbit both directions) with one CPU core loaded since integrity calculations are now done on the CPU. Currently we boot the 2GB and 4GB with one firmware loader at 768Mhz DRAM frequency. The u-boot patches to autodetect DRAM size seem to work so far, havent heard back from someone with a 1GB board yet. RK also should push a DRAM init blob for 933Mhz soon...
     
    https://github.com/ayufan-rock64/linux-build/releases - new images and deb packages for system upgrade
  11. Like
    Xalius got a reaction from pfeerick in ROCK64   
    Yeah I am following the mainlining process for some time now, and some new things went into 4.12.x , we'll see at what pace that continues. As for the documentation there are only the datasheets (SOC+RK805), Part 1 of the user manual and the schematics right now. Tl is trying to get the Part 2 of the user manual released, but I am not sure what is actually in there. RK just today provided some more patches for the 4.4.x BSP, maybe the Rock64 can now stay up longer than 20 minutes :-)
     
    On the hardware front Tl was looking for last suggestions regarding schematic changes or board layout changes, I think the plan is to go into production as soon it is confirmed that 933Mhz DRAM works on all three (1/2/4GB) variants...
     
    @TonyMac32 I can ask Tl if he can send you a board sample if you like
  12. Like
    Xalius got a reaction from TonyMac32 in What does your workbench look like?   
    HP50G!!  Will update my post with a photo later...
  13. Like
    Xalius got a reaction from umiddelb in Moderator duties   
    :-)
  14. Like
    Xalius got a reaction from Myy in RK3328 Kernel   
    Do not forget to actually lift the BT reset GPIO, on the Pine64 that is done via 'rfkill unblock all' or 'rfkill unblock xxx' otherwise the uart of the BT part will not answer and you just get a 'sync timeout'  from the firmware loader...
  15. Like
    Xalius got a reaction from Myy in RK3328 Kernel   
    Pine64 uses the same RTL8723BS module and we got BT working more or less reliably now. There are some versions of the BT firmware loader floating around (Iwfinger, hadess, ...) but NextThingCo seems to have the latest version for the RTL8723DS, which also works with CS and BS though...
     
    Check out:
     
    https://github.com/ayufan-pine64/linux-build/blob/master/Makefile#L49 - build the rtk_hciattach firmware loader, loads FW over UART and attaches it to the BT stack
     
    https://github.com/ayufan-pine64/linux-build/tree/master/package/root/lib/firmware/rtlbt - needed firmware files
     
    https://github.com/ayufan-pine64/linux-build/blob/master/package/root/etc/systemd/system/rtk-hciattach.service - systemd service
     
     
  16. Like
    Xalius reacted to tkaiser in Nightly images?   
    To elaborate on this only for now. My main concern is 'communicating clearly to end users what to expect'. On our download page only devices should be listed that receive 100% full support.
     
    All other devices should be moved to completely separated 'Unsupported' page. The devices listed here fall into the following 3 categories:
     
    'Phased out': support has been removed for documented reasons (applies to those A20 Orange Pis and the two S500 devices now). Latest OS images are still accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once). 'Work in Progress': these are the boards we're currently working on but that are not ready, where every question 'why not worky?!' is just useless and a waste of time. Preliminary or even nightly OS images are accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once, we should add the 'nightly' motd disclaimer to .wip boards too) 'Not supported': these are the boards people would think will be supported by Armbian (soon) but won't. This is the process of a short discussion in development forum which ends up in a file below https://github.com/armbian/documentation and a link to the initial thread. This page clearly documents the reasons why there's no support for the board (not worth the efforts since support nightmare due to crappy Micro USB, vendor not releasing complete schematic, only crappy BSP available and so on  
    The last category is the most important one for me since it allows us to document decisions and maybe even to change vendor behaviour (providing schematics earlier, becoming more cooperative).
     
    How do we do today? A hardware vendor sends out a bunch of dev samples and we start like brain damaged retards immediately to work on getting all these boards supported in Armbian even if it makes no sense at all. For example OPi Zero Plus H5. For Xunlong it makes no difference to feed the reel with H3 or H5 SoCs and to push out boards with a slight price difference all running a 32-bit Android they already have from Allwinner. For whatever reasons (desktop replacement the only possible on this design) people buy these boards. But running a 64-bit distro especially with X on this limited device is just stupid with only 512 MB DRAM. So at least three reasons against: Armbian support would be stupid, Micro USB and high expectations combined with unreliable powering create a support nightmare. No thanks.
     
    Since while supporting such devices might be absolutely wrong but board bring up could be fun we could treat these devices simply as 'WiP forever'. They just remain on the unsupported page marked 'Work in Progress' so software can be improved, support requests happily ignored and once something changes we could rethink and move the board to supported section (BTW: Having download statistics from dl.armbian.com as well as torrent tracking would be great to help with decisions regarding user acceptance)
     
    To me it's really important to list devices we'll most probably never support on a page just to document this clearly, list requirements (so vendors looking this up could improve eg. providing schematics earlier) and maybe even educate users (what to look for prior to an impulse buy). We'll soon get more H3 boards with H5 instead (since it's that easy to exchange the SoC) and I really don't see why we should automatically support them since software support for H3 and H5 is somewhat different and higher memory requirements of a 64-bit distro render use cases useless.
     
    Also we face SBC customers who were tricked into believing they buy 'upgrades'. This applies to eg. 'Cubieboard 6' (Actions Semi S500 --> no way at least for now) or the so called 'BPi R2' many users believe would be just an enhanced R1 version eliminating the many design flaws of R1 and being somewhat compatible. But it's a whole different product using a new SoC from a manufacturer that started just recently to become somewhat open (MTK guys now even send patches upstream so maybe in 2018 we can talk about R2 again then running with mainline only). But R2 customers have not the slightest idea how crappy software situation for R1 was in the beginning and that unlike R1 they can't expect any improvements with R2 since there's no community around this time. This needs to be clearly documented so people might get actual results when doing a web search for 'bpi r2 armbian'.
  17. Like
    Xalius got a reaction from tkaiser in ROCK64   
    Moderator edit (pfeerick): I have modified this post to contextualise this split thread. It was initially intended to be a discussion of a board bring up procedure / proposal format, and has since evolved into discussion of the rock64 generally. 
     
    Xalius originally said in this post: 
    TODO-List sounds good to me, I will run some tests as soon as China Post/DHL actually deliver my package. I get a 4GB version with the suppressor diodes for USB3 already replaced...
     
    This is what tkasier originally wrote in his first post, minus the disclaimer as was only relevant to that thread:
     
     
  18. Like
    Xalius got a reaction from pfeerick in Quick Pinebook Preview / Review   
    I have not heard back yet from TL regarding XPowers looking into the issue with the battery charger, and I pretty much would like to see the ARISC code by now since working around that black box is rather frustrating. For now I changed my UPower settings to shutdown at 4% and the default action to 'poweroff' instead of 'hibernate' to avoid issues...
  19. Like
    Xalius got a reaction from pfeerick in Quick Pinebook Preview / Review   
    The protection circuit specs are in the battery datasheets which are already on the Pine wiki. The UVLO voltages for are around 2.7-2.8V and should be well below those set in the AXP. I still have a suspicion that whatever happens, it has something to do with running out of battery in suspend. Under normal load the battery cuts out well above 3.0V , I saw values around 3.2-3.4V in my tests....
  20. Like
    Xalius got a reaction from tkaiser in Changing to Chromium   
    There is a switch to limit Chromium's disk cache size:
     
    --disk-cache-size=n n in Bytes, I use 300MB atm...
  21. Like
    Xalius got a reaction from tkaiser in Pine64 Pinebook   
    Lol, 'exclusive' story... they didnt even mention their source, I hope that is legal were they live...
  22. Like
    Xalius got a reaction from tkaiser in Armbian running on Pine64 (and other A64/H5 devices)   
    I just took a closer look at my Pinebook PCB and the DRAM chips are https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125-m x 4
     
    1.35V DDR3L-RS SDRAM with D9QLJ stamp code
     
    256 Meg x 16 256M16
     
    96-ball 9mm x 14mm FBGA
     
    tCK = 1.25ns, CL = 11
     
    1600 11-11-11 13.75 13.75 13.75
     
    This PCB is a V1.1 Version from september 2016, so they could have changed DRAM for the next version as the schematic states... 2017-01-10 on page 4 for the DRAM