Already discussed in http://community.onion.io/topic/1671/compiling-lede-on-windows-10
Posts made by Maximilian Gerhardt
RE: Assembly Language Programming
@Max-Mitchell If you have installed the cross-compiler tools,
mipsel-openwrt-linux-asis there alongside with
mipsel-openwrt-linux-gccwhich can also compile inline assembler. This definitely works, as I have programmed the Omega2's DSP coprocessor with SIMD assembler instructions :)
RE: How to install GDBServer ?
@Carst-Dan Have you tried the repos listed in https://docs.onion.io/omega2-docs/c-compiler-on-omega.html?
RE: Can't install any packages at all using opkg install on Onion Omega2 Pro [RESOLVED]
@Yvan-Gagnon What package are you trying to install? What is the contents of your
RE: Omega2 as a LoRaWAN node
@Lazar-Demin Great to see it working. If you need a gateway you can also use a ESP8266 NodeMCU board with another RFM95 module and configure and flash the https://github.com/things4u/ESP-1ch-Gateway-v5.0 firwmare on it, also see http://things4u.github.io/. Needs a little bit of fiddling around with the configuration and pinout; Also be aware that the EUI of the TTN gateway must be the one that the firmware spits out on startup (it's made up of the ESP8266's MAC address and two 0xff in the middle).
RE: I2C and C++
so then I copied the libraries reference above from
put them in the /sources/minitest2c/ directory
You should temporarily rename the
// confirmed /usr/lib/liboniondebug.so exists
// confirmed /usr/lib/libonioni2c.so exists
to something else so that the linker doesn't attempt to link against these. Then add
-L .to the compiler options to add the current directory (
.) to the linker search path.
RE: custom kernel
Actually when you follow my kernel modules tutorial it will also compile the kernel and give you the upgrade and flash
.binimages. Clone and see https://github.com/OnionIoT/source#using-a-linux-system.
RE: About Fast-GPIO
In https://github.com/OnionIoT/fast-gpio/blob/master/src/fastgpioomega2.cpp, the
open("/dev/mem", O_RDWR), then
mmaps 1024 bytes starting from the given base address. The result tof the
mmapis stored into
regAddressand based on this memory-mapped address the program accesses the registers. So the file handle is not needed anymore and is closed.
mmap-ed block should later freed using
munmap()but the code doesn't do that. However, it should still work.
I.e. I don't see a problem with the library code. What is the application program you've written to access GPIO15?
RE: The Omega2 Pro is now available on Crowd Supply!
The entire main SoC is the same, 580MHz MIPS (MT7688) with 128MB DDR2 RAM. The Pro Version is the Omega2S+ with a 8GB eMMC and a LiPo charger, with a 384 MB swap file from flash to expand the RAM (already described here) and a few Dock accessories for the USB-Serial and power part.
I see no reason why the firmwares for the Omega2+ and the Omega2 Pro shouldn't be compatible with each other, please correct me if that's wrong.
And using the same SoC with the same silicon bugs for the SPI also means we'll inherit the exact same problems with full-duplex transfers there.
RE: Need Deteiled Datasheets to make a Gameingconsole with 2x Omega 2+
Nice project idea. But why abandon the Linux OS and all the peripheral drivers and start everything writing from scratch? For the sake of a pure speed advantage or wanting to learn MIPS assembler? I feel like doing a UBoot bootloader + using baremetal C/C++ combination would have very similiar performance and be way more feasable to program.
Still as soon as you want something like USB for Audio you probably don't want to re-implement the USB stack and USB peripheral driver from scratch. Or multitasking. (maybe use FreeRTOS on an Omega? ;))
How is data shared between the Omegas? You say you have a 'combined RAM' but the memory / data bus of the Omega isn't exposed? How are they going to have shared memory?
As for the video output, I think the fastest way to output the framebuffer would actually be USB because of its highest available bitrate. That's why I started using USB display adapters (here), they have an ok performance for low resolutions (90FPS @ 160 × 144 @ 16bpp) but need substantial optimizations for higher resolutions. I did rendering to SPI displays here.
- use the even higher-speed Ethernet peripheral and an FPGA to render to a SPI display an HDMI encoder chip
- write framebuffer into shared RAM or a dedicated RAM which a FPGA renders out
The only problem I see with graphics / 3D performance is the missing GPU. Everything has to be done in software. Maybe you can at least accellerate a few 2D operations with DMA acellerated copying though. I was using software-rendered OpenGL here (MESA 3D).
The whole thing sounds a like a modern Nintendo64 (64-bit MIPS CPU @ 93.75MHz for game logic, 64-bit Reality Coprocessor @ 62.5MHz as GPU, audio processor, I/O processor, loadable with custom Microcode for programming the rendering stages), just that we have two 580MHz 32-bit MIPS cores now (with a 64-bit DSP).
links with it are very welcome
Only datasheet of the MT7688 I know of is at https://labs.mediatek.com/en/chipset/MT7688 and https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/documentation, I'd gather the rest of peripheral drivers from the linux source code and patches (https://github.com/OnionIoT/source) or other bare-metal implementation (e.g. GPIO)
Anyways if you want to work together I'd be a happy about a mail.