DrTune

I tore out the crappy wifi on my OPi Zero just now and was trying to use an external realtek dongle. No luck until I copy-pasted the wifi section out of the fex from an OPi without wifi, e.g. [wifi_para] wifi_used = 0 wifi_sdc_id = 1 wifi_usbc_id = 5 wifi_usbc_type = 1 wl_reg_on = port:PL07<1><default><default><0> wl_host_wake = port:PG10<0><default><default><0> wl_host_wake_invert = 0 Replacing the wifi_para in orangepizero.bin with this disabled the onboard wifi and allowed my realtek to work. thx!

Also if you remove U56 (the LDO for wifi) that conveniently leaves you that pin (PCM0_DOUT) spare to use for its' god-given purpose, that is, driving WS2812B leds (for example). The Allwinner I2S hardware is dope- it has its own PLL so you can overclock it to crazy speeds (e.g. 100mbs)

Hiya, Goal: Ok so I'm after a high speed synchronous serial interface (50mhz would be nice) with reasonably flexible clocking options so I can tweak it up and down. The goal is to implement a "fast as possible" SWD debug interface to a Cortex M0; ideally the serial interface could be run arbitrarily fast until the target M0 or the wiring can't handle it. If can do 48mhz I can basically read/write one 32-bit word per microsecond over swd, so 4MB/sec, and I want to process that a little and send it to a PC (obviously ethernet). I especially care about consistent, gap-free, no jitter on this serial interface. So SPI is the obvious choice but I'm also strongly drawn to abusing I2S; I don't care about real audio working so it looks like I can repurpose the H3's audio PLL. The H3 I2S hardware looks pretty decent in that it has reasonable size FIFOs and DMA and especially that it appears to allow you to clock the living shit out of it. Referring to the H3 datasheet http://linux-sunxi.org/images/4/4b/Allwinner_H3_Datasheet_V1.2.pdf Page 524 shows the 64x32 bit RX and 128x32 TX fifos, which are pretty generous. The clock comes from PLL2, the audio pll, which appears to have no other use and it appears will run up to 200mhz If you look at page 536 you see the I2S clock divider support as fast as /1 (!) up to /192. It's effectively an SPI port (TX+RX synchronously) with extra care to make sure it can run without dropouts (of course, because it's for audio) The FIFOs have programmable low water and DMA, I mean what could possibly go wrong? The shortest fifo (rx) is 64x32 bits= 2kbit (256 byte). At 100Mhz that's 10ns*2048= 20.48us or 48k FIFO contents/sec, and the H3 can trigger DMA FIFO operations automatically of course. Half-emptying the RX fifo (if we have high-water mark at 50% to allow for a bunch of dma latency) is 32 32-bit DMA transfers, which of course is 100Mbit/8=12.5MBytes/sec. Superficially it seems very doable in terms of the traffic running on the H3 silicon, it may even run faster - however I do not really expect to get a usable 100mbit link out of an orange pi, primarily for pcb/electrical reasons. By comparison the real SPI controller only has 64x8 bit FIFOs, and the clock selection is less flexible. (with I2S we have our own PLL to play with) Hmmmm.. so looks pretty handy actually. I started off abusing I2S to drive WS2812s but it looks like there's a lot you can do with it; a flexibly & reliably clocked 100mbit bidirectional synchronous link running into a SOC that has plenty of ram and cpu grunt and network capability that costs about $10... mmmm... Ok, hold my beer...

Yes please! I love my A20 / H3 SBCs despite their various quirks - them being so hackable is very handy (having schematics + datasheets; OrangePi even do a decent job on the silkscreen which is a lifesaver)and Armbian has long been the only serious game in town for Allwinner boards IMO. Will be nice to have a couple in the drawer with a BLE capable radio and EMMC. (C.H.I.P has both but ended up being a bit disappointing for me in practice; esp for I/O's - some via i2c expander and not even an unused UART; meh). They're all good SOCs to hack on IMO (I'm sure I can even find a use for my Wifi-impaired PiZero's) ; the Allwinner datasheets are just about good enough to make it fun :-) Thanks! Hugely appreciate your work. DrTune

Hiya, Using a Banana Pi M1 as a factory production tester in China, running Armbian Mainline 4.6.3. Works fine here; never had the problem they're reporting, but they're saying: a) after a certain amount (unspecified) of time the boards crash and get stuck in a reboot loop displaying screen as shown in JPEG - "kernel panic not syncing - Attemped to kill init! exitcode=0x000000b" b ) rewriting the SD card image (from one I provided; a 4GB pre-configured image) fixes it (until it happens again) c) Only useful thing I can get from the photo attached is that the stack trace in the image (which is all I have to go on btw; trying to get a copy of the bad SD card now) indicates CPU0 is in "gic_handle_irq"; assume this is handling an IRQ from the NIC (gigabit on BPi) but it's not clear to me why that would happen (the boards do have an active wired LAN connection, don't know if it's 100 or 1000mbps) d) Obviously "SD card corruption" is an answer but it's never ever happened on my end and (for example) the fsck is shown passing e) The app this thing runs is not writing much to the SD card at all; the image I sent them occupies something like a 1.5G (it's a vanilla mainline Armbian server image with a few tens of megs of extra packages and stuff). I don't know the SD card brand they're using. I use fairly cheapo 4GB SDs on my board (because I like to be able to pull off the image and I don't want it to be huge from say a 32G card); I send them this image (once I'd set it up) in a zip that was just under 1G. I believe they then wrote that onto 8G cards (not sure). I don't know if the image will have expanded it's filesystem to their SD size or if the resizefs only happens on firstboot. Any suggestions to figure this out and prevent it happening would be very welcome, thank you! If I can get them to upload their broken image to me I'll be able to do more poking at it. Cheers, much appreciate your time. DrTune.

Hey all, I've been using Allwinner boards for the last couple of years and Armbian+forums have made this a workable thing that I promote to my friends as being The Way To Go instead of being a big fat waste of time. Igor + Tkaiser (and anyone else forgive me if I didn't give you a shout) - You fucking rock. You really do; you've all provided amazing amounts of support for multiple kernels and userspaces and in the face of (at least) bullshit from the chip vendors, yet you are absolutely crucial to them being taken seriously. The work from Armbian has (for me) made the difference between BananaPi, OrangePi, etc all being an unusable washout of #ShitDidn'tWork, to being something I am excited to build into things and personally promote. Igor, Tkaiser; I've never met you but your work speaks for itself; you give a shit and you keep giving and shit and THANK YOU FOR THAT. I just donated you some $. If you're still reading this and you're using their work, you might think about doing same. FWIW; what turned my head is seeing Igor and crew putting _years_ of work into this. Anyway, much, much, much appreciated. From one to another; good job. DrTune

FYI for anyone else wanting to avoid having Armbian use all your SD card when it first boots... a) download armbian and write image to SD. Don't boot with it yet! plug SD card into a running linux system as external drive (e.g. via a USB-SD adapter) - I just used a previous Armbian image on my Banana Pi - and mount it, c) cd to the card's root directory d) echo 50% >root/.rootfs_resize <<Where 50% is the amount of the actual SD card you want to utilize e) sync and remove card. f) Boot it e.g. I used a 4GB card and set it to resize to 65% and now my Armbian is using 2.4G of the 4G card. I want this because I keep my images compact so I can zip up the SD image and send it to my factory in China (who I have set up with a production programmer/tester device using BananaPi + Armbian) Thanks Armbian guys, I can barely express how much I love your work. My fave distro for embedded systems EVER!