Is there no way to descern the GPIO information from a running device? I tried a simple “friendly” email to ZoomGo and to Damai and in neither case got a response.
edit: just emailed PlayOn (the rebadger) and Damai (the rebadgee) again and included a note about GPL compliance.
Well,if sysfs is active then you can see the GPIOs but not for all things.
Unfortunately,device does not use DTS so you cant extract it from kernel.
They are seriously storing the root account password in plain text.
Good thing is that both the datasheet and programming guide for the CPU are public.
They are even on the Ingenic site.
Good news is that it uses the BCM43438 radio which is also used in Raspberry Pi 3b and is supported by the brcmfmac driver.
Its actually quite nice SoC, a lot of integrated stuff in it.
I didn't see the root account password in plaintext, I had to decipher it with John. Plus since that was off the initial flash chip I missed the first run script that nuked the root password (effectively preventing it from being used to log in). When I booted to failsafe over serial I reset the password.
I looked at the gpio in sysfs and only saw the controller chips, not the actual GPIOs themselves:
root@ZoomGo:/sys/class/gpio# ls
export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport
It looks like each chip except for gpiochip96 reports that it controls 32 GPIOs; gpiochip96 says 6. Any other way I could figure out what GPIOs to map? It ain't like this thing has a reset button or anything. I see 2 LEDs for it in the sysfs, but there appears to only be one physical LED from what I see.
root@ZoomGo:/sys/class/leds# ls
longsys:blue:led longsys:green:led
Any ideas what I should try next? I'm a complete newbie at porting OpenWRT but I've got a decent amount of hardware hacking and Linux experience...
Probably means nothing, but I am following this thread and your development actively! =)
Well that means that there are no GPIOs registered for some general purpose stuff.
They are registered for that LED and other important stuff.
That LED is most likely dual color,so that is why 2 colors are registered.
Since it does not use DTS I dont think there is a way to see which GPIO pins are reserved and for what.
Does the device have NAND of ony SPI NOR?
If its NOR then GPIOs should not really matter as I am pretty sure(Gotta check in Datasheet) that there are dedicated pins for it.
Too bad that device does not use DTS so we can easily see whats configured for what.
They are seriously storing password for all acounts in plaintext in /etc/passwd
SPI NOR and MMC reader (using jzmmc which appears to be in the mainline kernel). uboot claims MMC support but it wouldn't recognize the micro SD card I inserted no matter if it was present at power-up or what file system I used. uboot also claims USB support, but I haven't tested that yet.
Ok,so at least those GPIO dont need to be known.
Most likely Uboot support for MMC is broken,I wouldnt trust it.
Altough which way were you testing if MMC works in Uboot?
It looks like MMC driver is upstream and even maintained regularely.
Ok, so the first thing would be to make a dump of all current partitions.
That way recovering everything is possible.
Hm, SoC in this stick is X1000 series, but X1000 is a fancy marketing name for Xburst core and all of JZ74XX series reuses it.
It seems that this one uses Damai DM6291A SoC which is a Xburst based, but there is only generic info on it.
Also, it looks like a OEM company Ce Link actually manufactures the device according to FCC
The firmware I posted on the github earlier is a full dump of the system. From the uboot output it looks like the LEDs might be GPIO 89 and 90:
gpio_request lable = off-led gpio = 89
gpio_request lable = led-sys gpio = 90
I did a dump of each individual partition and posted it to the github I made earlier.
I tested uboot by accessing it via console; mmc was one of the commands listed. I tried all the different mmc commands and it kept reporting that no mmc device was found.
Well then its broken.
I figured out which SoC is it based on.
Its JZ4770, much upgraded JZ4720 used in that upstream supported board.
So I dont know if the drivers are the same at all.
One way to find out...
Also, it looks like I can at least boot the backup kernel from uboot, mtd6 appears to be a kernel backup from which I was successfully able to boot. Worst case scenario I can fry mtd3 and mtd4 and still get it to boot because mtd6 and mtd7 appear to be backups.
Well,defining SPI nor will be interesting as there is no example.
Altough it should be similar to NAND partition definition.
Hm, I dont know if PCI works
It looks like 4.16 kernel includes support for JZ4770.
So we gotta do some backporting from 4.18 preferably.
They even migrated everything to use DT and DTS.
So that is awesome,but the issue is that its just the most basic support to get it booted.
No buses etc
Cool. Doesn't mean I know how to set up a proper DT/DTS setup.
I think all the commits were done by this guy, so that should in theory help narrow down what needs to be backported. I can mess with some diffs later.
https://github.com/torvalds/linux/commits?author=pcercuei (author pcercuei).
I dont think you understand.
Drivers for JZ4770 are very few.
Not even for the SPI bus, pretty much nothing would work.
MMC we can most likely get to work.
SPI could be bitbanged only and I dont think that NOR flash would run fine on it.
PCI looks like no support too so the BCM radio wont work
I wrote a patch to attempt to upstream all the stuff that was put in 4.16-4.18 so far (assuming it all comes from that one guy). It patches and compiles fine against master, though note you have to remove the 006 and 007 patches that compiled previously because it appears to change some SPI stuff. Compiled for the Ben Nanonote with device tree enabled and it seemed to compile (still can't test it though).
Do you think more needs to be done before we can support the JZ4770?
Well, like I said most of the drivers are missing.
SPI that is needed for you to load rootfs does not have a driver and needs bitbanged spi-gpio.
MMC could also be used since that has a driver but a compatible for JZ4770 is missing, so that needs to be patched in.
I can help you but without having the device I really cant do a lot
Well let me know what I can do, I'm relatively new to this. Otherwise, we'll just have to wait until some more support is upstreamed and attempt to backport it too.
Thank you for all of your help.
I looked into getting one of these but they are not available in EU at all.
I can make a simple DTS just to initramfs load and see fi anything works at all, but you gotta know that most stuff won't work.
Although it looks like the radio uses SDIO interface so it could actually work since brcmfmac supports it, but we don't know to which GPIO pins it is connected
I can try to narrow it down; I tried to hit all the GPIO high and low and some of the pins either were locked or crashed the GPIO driver.
Just let me know what to test, I can write an initramfs to one of the backup partitions to test it and worst case I have a Pomona clip and a Raspberry Pi.
Well initramfs kernel is not meant to be written to a flash, its usually loaded over TFTP to RAM and then you simply load it.
It would be great if MMC driver actually works so that SD card can be used for loading the firmware.
What do you have under /sys/bus/i2c/devices?