lanefu reacted to TonyMac32 in Librecomputer Tritium H3
SoC's have built-in support for changing frequency, generally. So the "Magic" is a driver controlling a clock generator/multiplier. However, most of the time, with reduced frequency you can reduce operating voltage a little bit to save on power and reduce heat. In this case that isn't going to be an option, on the Allwinner-based boards that support it it's a bit of a hack in the first place, using a transistor on a gpio to change the target voltage of the system regulator by adding/removing a resistor from the regulator's "voltage setting". This board does not support that. On a board like the Tinker, Renegade, Rock64, there is a matched/recommended regulator chip PMIC that takes commands and adjusts the voltages accordingly in a much more controlled fashion.
lanefu got a reaction from TonyMac32 in Librecomputer Tritium H3
My Tritum h5 board came. I just built an image from Dev branch using Tony's tritium-5.csc. w/ Kernel 4.14.43 Fired right up..... Even has console login on HDMI. (although its not returning keystrokes at the console)
but I ssh'd in an all is well.
Trying to understand a bit more about regression bug. I'm running at 1.01ghz. Is that related to regression bug? Basically trying to understand on how I can help achieve parity with the Clock on my Opi PC2 or Prime. etc
lanefu reacted to TonyMac32 in Librecomputer Tritium H3
Correct. A bit strange. There is a dw-hdmi patch that needs a fixup, but I tried to to no effect.
@Igor my support patches for this board do the opposite of the OPi PC2 image I tried, I get debug console with uboot on mine, but no kernel hdmi, the opi image made today has no uboot hdmi but does have kernel. I'm sure I'm doing something ridiculous... Any argument about uploading as CSC even though it's headless? it's only a csc, uboot and kernel patch to add the dts's?
lanefu reacted to arre in Testers wanted Real Time Kernel image builds for H3 boards
Just wanted to share that I got the realtime patch working on an Orange Pi Zero on 4.18.8
I used the armbian build environment and the official RT patch.
A few tricky points were the CPU govenor and CPU operating points automatically switching by default, causing the realtime behavior to be really bad (max spikes around 3000 in cpu test).
By patching the device tree to only use a fixed operating point, I achieve the following output:
Linux orangepizero 4.14.8-rt9-sunxi #1 SMP PREEMPT RT Sat Jan 6 14:36:31 CET 2018 armv7l armv7l armv7l GNU/Linux /root/rt-tests/cyclictest -p 80 -t5 –n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.85 0.49 0.22 4/168 3083 T: 0 ( 3079) P:80 I:1000 C: 3297 Min: 8 Act: 17 Avg: 16 Max: 66 T: 1 ( 3080) P:80 I:1500 C: 2198 Min: 8 Act: 24 Avg: 15 Max: 50 T: 2 ( 3081) P:80 I:2000 C: 1648 Min: 8 Act: 11 Avg: 16 Max: 60 T: 3 ( 3082) P:80 I:2500 C: 1318 Min: 8 Act: 12 Avg: 15 Max: 44 T: 4 ( 3083) P:80 I:3000 C: 1098 Min: 9 Act: 17 Avg: 18 Max: 57
If anyone is interested, I used this realtime kernel to run a virtual wifi guitar amplifier on the orange pi zero.
I documented the entire thing on http://arre234.blogspot.be/2018/02/linux-portable-wifi-guitar-amp-on.html , including the device tree and cpu govenor stuff.
Hope this helps anyone
lanefu reacted to Tido in Kickstarter: Allwinner VPU support in the official Linux kernel
Release the libVA improvements when the kernel driver patch series is ready for submission, sometime next week. read more here: https://bootlin.com/
lanefu reacted to NicoD in My new video about the Rock64 with Armbian
I've made a video about the Rock64. I've tried different distro's, but Armbian was the best for me.
The only problems I've found was that Synaptic Package Manager didn't work. It crashes when I press the search button. And sometimes surfing was extremely slow. Otherwise it did fix all the problems I've had with the other distro's I've tried.
Thank you for all the great work.
Now I've started my research with the Orange Pi +2, and again Armbian is the best choice.
Here is my video.
lanefu reacted to TonyMac32 in Patch and configuration directory organization
This topic is a response to the growing number of kernels, growing number of boards with... "unique properties", and for the increased complexity of some platofrms (aarch64 and the atf, etc). I think the coherency of the chosen organizational method is starting to fall apart.
So just a thought experiment on my part:
Currently, we have a sources directory, and the sources file has not just sources, but also executable script functions in it. We also do our patches per SoC, mostly, but the organization is by the thing being compiled rather than by the target, making finding/adjusting a bit cumbersome in some cases.
I would propose a directory tree looking something like this:
├── RK3288 │ ├── kernel │ │ ├── default │ │ ├── dev │ │ └── next │ ├── miqi │ ├── tinkerboard │ │ ├── kernel │ │ │ ├── default │ │ │ ├── dev │ │ │ └── next │ │ └── uboot │ │ ├── default │ │ ├── dev │ │ └── next │ └── uboot │ ├── default │ ├── dev │ └── next └── S905 In this case the organization is by SoC, then by board. All patches safe for the entire board population get put in the SoC-level kernel and uboot patch folders, anything unsafe (hardkernel-specific patches, Tinker board specific patches) go into the board-level folders. To reinforce that we want those folder to be "last resort", we could call them "C2_bugs, Tinker_bugs" etc.
For our 64-bit targets, the trusted firmware would likewise have it's directory. I think it might also make for a lower barrier to entry on committing fixes, I still worry about patching things when I don't have all the boards to test on, this way, as a novice or as someone doing something that I can't test on other hardware, I can drop the patch into the board(s) I have, then they can be evaluated by the other devs on the remainder of the hardware.
My particular set of boards benefit this way:
Tinker board specific patches are many, integrating them safely is one of the biggest reasons we lag the vendor kernel, changes to the architecture files, changes to rk3288.dtsi instead of just to rk3288-minarm.dts, changes to various drivers for specific hardware issues, etc etc etc etc. Differences in gxbb vs gxl Meson64 devices. Most of these coexist peacefully, but then you have vendor issues with u-boot of the C2, K2, etc (everyone has their own bootloader blobs)
I'd say we organize bootloader scripts similarly, rather than having executable scripts in the sources file we could place an include in the appropriate board folder covering the specifics. For example, if a board ships with a SPI boot flash, we don't need to burn u-boot, only provide the proper configuration of partitions/etc. That might be the only board in the series (an unusually awesome H3 board, for example).
Ideally, at that point, adding a new board would require a new board definition file, and then the proper patches folder.
lanefu reacted to TonyMac32 in Pi-Factor power solution
I've done some load testing of my first prototype power "mezzanine" board (can't say "hat") The voltage drop of powering the RPi touchscreen off of the GPIO while the tinker is on micro-USB is insane, I was reading 3.9 Volts on the USB ports when I ran minerd --benchmark. I may have finally worn out the Micro-USB connector...
This is a project for learning the ins and outs of kicad and get an idea of the capabilities of the PCB houses I have reasonably fast access to (Chinese ones unfortunately always get stuck in customs for a week or more on top of the normal shipping and fab times, so the cost savings is lost in time) I have some more interesting things in mind, but I thought I'd start out (very) small. The input is protected by the recommended ideal diode circuit from the RPi guys, stress testing didn't even make it warm. If a better solution is needed, it can obviously be designed, but this is extremely cheap all things considered and that was part of the G&O for this project.
By comparison, using this GPIO board to power everything resulted in a minimum 4.8 volts while also powering a USB 2.0 spinning disk HDD. (lower than I'd hoped, I'm going to make some adjustments to see if I can squeeze a bit more out once I get the redesigned version 2 back, I forgot about the temperature rise factor... )
One of the issues goes back to our friends at RPi, the 5V pins are on the outside edge, so you have to go around the inner row to get to them. This complicates moving big conductors around somewhat...
The chip in the back is a SPI NOR for booting the Tinker (experimental, I threw it in there as an experiment and never actually performed the experiment...) I'll probably wipe it from the board, perhaps leave an 8-pin SMT-adapter-sized pattern to the SPI for the adventurous.
Power supply used here is the Odroid XU4 supply. This initial run has no overvoltage or overcurrent protection. And I need finer tipped soldering iron...
I'll GitHub this one after some cleaning and citation of sources, normal disclaimers for those who want to build one. I will have moved one of the USB ports though since @chwe happily pointed out that Y-cables don't reach that far to get from the real ports to the power-only ones... (oops)
Boards successfully powered by this configuration (I don't / can't own one of everything... ):
Tinker Board Le Potato NanoPi K2 (Already has a barrel jack, by the way, but you never know, maybe you want the bigger one)
lanefu reacted to MickMake in The mmBoard
Thought I'd let you know about a new board that I've just released - called the mmBoard.
Has all the features that SBC hackers have been wanting, plus more.
Let me know if there's any questions about it. Would be happy to answer them.
lanefu reacted to Anodev in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64
I was able to get ROOT rights to Android from Xunlong image(OrangePi OnePlus), and install GAPPS!
1. Remove the boot.img from this firmware
2. Install the Magisk Manager and patch boot.img
3. Turn on USB0 mode in the developer settings
4. Run adb and reboot into the bootloader
5. Flash patched_boot.img via fastboot
Then install GAPPS manually
lanefu reacted to tkaiser in Armbian for OrangePi PC2, AllWinner H5
Which 'outsourcing'? Allwinner sells hardware. Cheap hardware for special markets. Android tablets back then, $something in between, now smart speakers, dashcams, retro gaming stuff, again tablets and TV boxes. Nintendo's NES Classic sold 2.3 million units in no time. Using a boring A33 SoC with technology from 5 years ago running a smelly 3.4.39 kernel from 5 years ago. Their customers (that's not us) do not care so why should Allwinner care so far?
They enable device manufacturers to throw out cheap hardware with somewhat working software with ok-ish margins (their main market) or sometimes enable their customers like Nintendo to sell insanely overpriced/overhyped products where again no-one cares about kernel, software or anything else we would be interested in.
For Allwinner there's still no 'Linux market'. Though things might change in the future. But unless there's an incentive to mainline their own hardware and submit code upstream (good luck given the BSP code quality) I doubt anything will change soon or at all. But of course I highly appreciate that they now contribute and react in a very responsive way. As @jernej pointed out in the meantime many requests will be answered positively (and I always chuckle seeing wink, the Allwinner guy, directly contributing to linux-sunxi wiki now -- I never thought this would happen)
lanefu reacted to René Kliment in Mali support announced for mainline (Allwinner SOC's)
This is my very dirty script that seems to work for me: https://gist.github.com/renekliment/707ea4a2dc3f11fc15ed8085f506c57e
lanefu reacted to TonyMac32 in board support - general discussion / project aims
- legacy kernels should go out due too overall bad kernel quality
- reboot/poweroff problems on some boards
- CSI (camera) doesn't work on mainline, gc2035 needs an small script in legacy to start up properly
- Mainline support effort is still relatively new. Things like USB, audio, etc are WIP.
- "Legacy" kernel that is stable is old and EOL (3.14) and I haven't fooled with it. In that world and all others Amlogic, @balbes150 is the master.
- Newer legacy kernel is still a work in progress (4.9 w/bugs)
- u-boot blobs are lame and make using mainline u-boot difficult (need both legacy 2015 and mainline u-boot to get a working image)
- Lower quality of open source information, all more or less community driven by a very small group, unlike with say Rockchip with a large amount of published info from Rockchip themselves. Rumor/commits say this may change with newer IoT processors.
- the legacy kernel is getting obsolete. No point to have it.
- possible to implement hw video acceleration on mainline kernel
- Solidrun has new 4.9 kernel, but can be safely ditched for mainline
Rockchip (I suggest only the one we support at the moment, not RK3399):
- CSI (tinkerboard, rk3288) is supported (RK 4.4 bsp kernel) by kernel (OV6547 OV5640, imx219 - RPI-cam V1.3 resp. V2) but doesn't show up properly when booting)
- Igor and tkaiser are already seeing this, but mkimage/uboot/trust can be finicky. luckily that's a "figure it out and move on" situation, but it is likely to cause headaches.
- 4.4 kernel is an increasingly old kernel, now 2 LTS's in the past, however still much better than a lot of others (also has a lot of activity)
- RKwifi is something I don't know the reason for. I don't know why it exists, I don't know what it does (other than cause problems). It is a wrapper for some wifi drivers/an rfkill system
- Rockchip likes to use their own subsystems in many things, like the "MPP" system for media playing. This has different capabilities per SoC, so may not behave predictably to simply be able to say we know how to use it.
- missing SFP support in mainline
Armbian related scripts:
- h3consumption is legacy only
lanefu reacted to chwe in board support - general discussion / project aims
Let's try it with an example and lock what happens/if it works... Such a 'project manager' needs a background in the topic otherwise it's similar to marketing monkey writes product description for *random device*. I suggest we take @zador.blood.stained proposal as a test:
Is it possible to write a proposal what should be done out of it?
IMHO, it can't be a goal that you have to test all images on your own, otherwise armbian has to reduce the supported boards to much less boards. If you look into DL statistic, there are enough people downloading our images, there must be some interest from the community to report bugs (update or fresh download). Can we start with a 'testgroup lite'? IMHO most important (cause most annoying) is to avoid that the device is not bootable after update. As long as you have SSH access via ETH to the device, broken things can be fixed or at least, a backup of the data can made (I agree you should backup your system before the update - but to be honest, we have to accept that people don't do it). To avoid flooding the forum with a lot of junk from the testers group a small webservice might help:
With a clear statement that we don't suggest that you're test without having a serial console at hand (seems that a lot of user don't think it is necessary to have a usb serial device at home when playing with SBCs - maybe we should 'educate' our 'customers' also in this field.... ).
Is it possible to have a 'board specific' update mechanism? E.g apt-update/upgrade only updates kernel/u-boot only if it's somehow on a 'positive list'?
Internet of shitty Things is the 'new' buzzword... Since people like @Larry Bank and @sgjava strongly push the GPIO issue, we might have a good solution in 2018. To avoid more load for the maintainers and keep Armbian as general as possible, I suggest to solve it similar to the OMV project. Means that we can provide a post installation script for a 'ArmbianIoT' but IMO we should avoid providing it in 'standard Armbian'.
A few questions:
Do we have a nightly desktop policy? Why do we provide desktop in nightly images? Does it make sense to provide such images as long as we can't provide 'basic stability'?