H3 Allwinner Firmware
Melissa Russian
according to video i need to know where flash chip is mapped in to memory then use md print whole firmware then used -uboot-dump.py to convert to firmware as he used bdinfo to get address (which is not present), what i do?
Mornings all :) i was in china for a business trip and i bought 2 android box's called T1BOX , but when i returned to my country egypt i found that it's all with chinese firmware and i am unable to install google play or youtube or any app and cant go to developers mode and also cant root the box , i opened it and took a snap from he mother board as below , tried to reset the box with the reset button with no use as the power do not come up while pressing the button , i got a male to male usb cable and with phoneix i put a firmware but for sorry the box now dont want to power on , can any one support me with a firmware i can flash my box , if now i have another box how can i take the firmware from it and put it to the one i made a wrong firmware on , help is needed from you guys :) thanks in advance :)
In your subject you have the word 'urgent'. What exactly is urgent on your topic. And if you needed the box work immediately, wouldn't you have rather bought an Android-TV-Box in the shop around the corner?
Hi tido, thanks for your reply for sorry dont have enough money to go and buy another android box from the shop around the corner and thinking of losing the box is driving me crazy thats why i said urgent for me it's a critical issue and would be pleased if you can support me
We also don't have the money to sponsor support for yet another cheap chinese hardware.
Hint: Just try a few images on the download section containing H3/H2+ chip. You might get lucky to boot Armbian with most of the things working.
Dear Tido thanks alot for your support , i discovered that my box do not have SD or TFT card slot to burn the rom and tried to do so with normal USB but i failed , can you provide me with a way to burn the rom via windows or usb , regarding the android forum thanks alot i will search and try my luck
Steve here,
Thank you PJ for your response. I thought i had done a pretty thorough search for ANY firmware or software that could bring life back to this camera. But I will try again. The camera seems to be a good product but the firmware and support are not what they should be. Let me know if you run into anything that will help.
thanks again
The screenshot above have been taken in Draco AW80 Meta (with 16GB eMMC) booted from a 32GB SD card. So booting from SD card is nice to get more storage, and trying out firmware before flashing a new one as it does not affect your current installation. Just make sure you use a fast SD card (Class 10 or greater) or the system may feel very slow.
SUNXI_PSCI_USE_NATIVE : Support direct control of the CPU cores powerdownand powerup sequence by BL31. This requires either support for a code snippetto be loaded into the ARISC SCP (A64, H5), or the power sequence controlregisters to be programmed directly (H6, H616). This supports only basiccontrol, like core on/off and system off/reset.This option defaults to 1. If an active SCP supporting the SCPI protocolis detected at runtime, this control scheme will be ignored, and SCPIwill be used instead, unless support has been explicitly disabled.
SUNXI_PSCI_USE_SCPI : Support control of the CPU cores powerdown andpowerup sequence by talking to the SCP processor via the SCPI protocol.This allows more advanced power saving techniques, like suspend to RAM.This option defaults to 1 on SoCs that feature an SCP. If no SCP firmwareusing the SCPI protocol is detected, the native sequence will be usedinstead. If both native and SCPI methods are included, SCPI will be favouredif SCP support is detected.
SUNXI_SETUP_REGULATORS : On SoCs that typically ship with a PMICpower management controller, BL31 tries to set up all needed power rails,programming them to their respective voltages. That allows bootloadersoftware like U-Boot to ignore power control via the PMIC.This setting defaults to 1. In some situations that enables too manyregulators, or some regulators need to be enabled in a very specificsequence. To avoid problems with those boards, SUNXI_SETUP_REGULATORScan bet set to 0 on the build command line, to skip the PMIC setupentirely. Any bootloader or OS would need to setup the PMIC on its own then.
BL31 lives in SRAM A2, which is documented to be accessible from secureworld only. Since this SRAM region is very limited (48 KB), we takeseveral measures to reduce memory consumption. One of them is to confineBL31 to only 28 bits of virtual address space, which reduces the numberof required page tables (each occupying 4KB of memory).The mapping we use on those SoCs is as follows:
There are at least two known revisions of the board. The older version is silkscreened D1_DEV_DDR3_16X2_V1_0 on the top and does not have the AWOL logo. The newer version has the AWOL anagram silkscreened on the front (d1.docs.aw-ol.com being the official documentation website with the same logo), and the identifier D1_DEV_DDR3_16X2_V1_2 on the back.
The BSP U-Boot/kernel use a NAND layout which merges a pair of pages from consecutive blocks into a super-page. Mainline uses the physical layout as-is. So while SPI NAND contents are accessible from both mainline and BSP kernels, they are only usable by one driver or the other. For this reason, it is recommended to install mainline software to an SD card, and leave the SPI NAND alone.
For recent versions of OpenSBI that include Kconfig support, you can reduce the size of the firmware by disabling almost all of the drivers. The only necessary ones are FDT_IRQCHIP_PLIC, FDT_RESET_SUNXI_WDT, and FDT_SERIAL_UART8250.
Mainline U-Boot support is mostly complete, but is not merged yet. Booting Linux from the network, USB, and an SD card works. Some refactoring of the various sunxi device drivers is still needed before any RISC-V sunxi platforms can be upstreamed.
These commands will generate the file u-boot-sunxi-with-spl.bin which contains the entire firmware and can be written to an SD card, just like for ARM-based Allwinner boards. See Bootable_SD_card#Bootloader for flashing instructions.
If you are using an old version of the mainline U-Boot branch, or the BSP U-Boot, you will need to use the BSP's boot0 as SPL. If you are using a current version of mainline U-Boot, you do not need this.
This version has been modified so it can be built outside the BSP's build system, so it compiles with mainline GCC, and so it cooperates better with mainline firmware binaries. See the commit history for more details. Below is the process for building it and writing it to an SD card:
The mainline U-Boot branch builds a mkimage tool which contains rudimentary support for making TOC1 images. Since a TOC1 can contain multiple items, we must create a config file telling mkimage where to find them. Use the following content, adjusting the path to OpenSBI as needed:
As usual there is no documentation for the memory controller or PHY IP used here. The baseline of this code was lifted from awboot, which seems to be based on some form of de-compilation of some original Allwinner code bits (with a GPL2 license tag from the very beginning). This version here is a reworked version, to match the U-Boot coding style and style of the other Allwinner DRAM drivers.
The preinstalled version of U-Boot requires holding down "S" during boot to enter the command line. From a booted Linux system (like the Tina Linux preinstalled in the on-board NAND) run the following command to set a three second delay during which it's possible to enter the command line on the built-in serial port:
The test pin T6, as per the manual and verified, is the reset pin (RST). A wire can be attached to it, and for convenience, routed to one of the N/C (not connected) pins on the GPIO header. It can be used for test and development automation.
To test an firmware/OS image, hold FEL, trigger reset, release FEL, then use xfel to bring up DRAM, load the image, and execute it. Watch the output on the UART, try input, and see if the device becomes visible on the network.
All the following Allwinner Stock Rom/Original firmware (zip file) contains reliable Allwinner USB driver, flash tool and firmware, follow the guidelines step by step to flash the firmware on the device.
However, if you are determined that code from the u-boot repo must boot before any TF-A code runs, then take a look at how the Allwinner parts boot: -software/arm-trusted-firmware/blob/master/docs/plat/allwinner.rst
The two bits of software end up with more or less the same role so swapping them in and out offers little technical benefit. It just means you now need TF-A to build u-boot instead of needing u-boot to build TF-A. The reduction in build complexity this would bring comes from having the AArch32 shim pre-assembled (and a pre-assembled shim could equally have been added to TF-A anyway).
The following page describes how to extract the bootloader, u-boot, and kernel from an Allwinner H700 based device. The following devices are based on this processor and these instructions are valid for all of them:
The original recovery firmware image (h700_linux_tv_uart0_20231108.zip) was posted as part of the Garlic 2.0 development. That included the bootloader for the original RG35XX as well as the one for the RG53XX Plus. You can download it from here (original link from the GarlicOS bootloader GitHub repository)
This firmware image can be extracted with several tools, but OpenixCard works well for these types of Allwinner firmware images. With the image downloaded and OpenixCard tools installed, first extract the image from the archive:
This is now achievable using the new serdev (Serial Device) subsystem, which allows us to describe and bind slave devices to UARTs. A Bluetooth device node is attached to the UART device node, describing clocks, regulators, and GPIO lines. The kernel driver would do all the power sequencing and also take care of uploading the firmware and registering the Bluetooth HCI device.
c80f0f1006