ag123

rather pinctrl could be related to pinctrl or maybe gpiod. I'm not too sure if that message means that w1-gpio is using that pin so pinctrl cannot use it. if that is the case, I think it is ok if pinctrl don't use it for gpio. that message is likely safe to ignore as long as your w1-gpio works. to 'fix' that it may take editing other dts to exclude that pin from pinctrl which could be a hassle.

it may help to look in codes https://github.com/torvalds/linux/blob/master/drivers/w1/masters/w1-gpio.c https://github.com/torvalds/linux/tree/master/drivers/w1 [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 seem to suggest that pinctrl tries to map that pin but onewire@0 is using it, so i guess this is ok as long as you are not using that as normal gpio pin. that "no maps for state" is found here https://github.com/torvalds/linux/blob/cf87f46fd34d6c19283d9625a7822f20d90b64a4/drivers/pinctrl/devicetree.c#L175 ret = ops->dt_node_to_map(pctldev, np_config, &map, &num_maps); if (ret < 0) return ret; else if (num_maps == 0) { /* * If we have no valid maps (maybe caused by empty pinctrl node * or typing error) ther is no need remember this, so just * return. */ dev_info(p->dev, "there is not valid maps for state %s\n", statename); return 0; } my guess is it may be related to pinctrl-names = "default"; some related stuff https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/ https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/w1-gpio.txt as it works as you mentioned, I'd guess that "not valid maps for state default" can be ignored.

I'm half way feeling that it may be possibly to use DS18B20 using gpiod / libgpiod https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/ I tried googling around but thare are lots of offers for DS18B20 many of which use w1-gpio as you are doing the timing requires for DS18B20 fig 16 page 16 https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf from 15 uS to 60 uS per bit of data isn't after all that impossible to synchronize the hard part about libgpiod is the timing part as sending and receiving data is timing sensitive, if there is a way to do that to read and write data in sync with tight timing it is possibly feasible to do so even in python. i.e. no kernel drivers, the python (or c etc) codes simply use libgpiod and work the signals. I've thus far not (yet) found one based on libgpiod admist the 'noise' returned from the searches, maybe try searching around and you may find an existing implementation that's already done. ether way, you seemed to have *achieved* making w1-gpio work, perhaps try connecting a sensor to see if the dmesg changes. the hint is [ 4.997833] w1-gpio onewire@0: gpio_request (pin) failed [ 4.997841] w1-gpio: probe of onewire@0 failed with error -22 if w1-gpio does a 'probe' it is probably sending the 'reset' signal to the chip and waiting for a response

based on the messages, it seemed you managed to load the overlay for w1-gpio perhaps venture further and connect a device appropriately ? based on the data sheet https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf (page 15, fig 15) it seeemed detection works by master (host) pulling down the line for 480 uS then pull that up again. then the chip would respond by first pulling it down, and after some 60-240 uS pull that up to inform the host of presence. it may take using specialized equipment like a scope / logic analyzer to probe those signals. for what is worth, and not trying to disappoint you, I think it is probably easier to connect the sensor to a (simple) microcontroller e.g. using uart and for the microcontroller to interface the sensor. the thing is for things related to timing, it may take going pretty much close to 'bare metal' e.g. work the on chip hardware to synchronize those signals, e.g. using pwm, spi etc. a h616 manual is found here https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf if you want to venture there. uart on orange pi zero 3 is likely available in the standard configs without dts overlays.

in a normal case, files in your home directory should belong to you except ..

type id and look at the groups you are in then ls -l and/or ls -ld and look at the owners and permissions for the files in your home folder the owners and group should match that in id otherwise you can probably change them using chown , chown -R , chmod etc. for rsync, scp etc, you probably need to use a same username across different hosts in a sense that it should remote login to your Orange Pi host using ssh with that username.

@OttawaHacker connect to the board using a usb-uart (debug) serial dongle. the boot messages would normally show up there, or that if it booted to the prompt, you could login as root and run dmesg to see what goes wrong try also the other u-boot https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ to see if that helps. there is a sequence of patches that needs to be applied and I've done that with my implementation. Unfortunately, in my case I hardcoded the 1.5GB memory as I found that for 1.5GB boards, the mainline u-boot incorrectly detected memory as 2GB or 4GB inconsistently. For once it says 2GB, then 4GB, then 2GB, and the algorithm would probe into the wrong memory size. so 'hardcoding' it ensures that it is 1.5GB no more / no less. you can use the distributed Armbian images https://www.armbian.com/orange-pi-zero-3/ and subsequently apply the u-boot patch from my repository. If you don't use dd , you can try using the python script that I've provided in my respository to patch u-boot into the image. Checkout instructions in my repository.

@OttawaHacker you could try the images from here: https://www.armbian.com/orange-pi-zero-3/ and to patch the u-boot into the image from here https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main

@voapilro Thanks To try to get it to boot, try applying the patches https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main/patches in particular: https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/THS_fix.patch https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/enable_GPU.patch note that these are for mainline u-boot 2024-04 release (tag), the patches are for the same found in Armbian. I really disliked all these 'black magic', but that these are really the 'state-of-the-art'. After I did my initial 1.5GB 'hack' patches, originally I've got that 'gpu overheating' issue. But with that 2 patches, it booted to the prompt ! As for 'vendor' u-boot, I'm suspecting that orange pi customized u-boot to pass some additional variables (possibly hard coded) to boot.scr, boot.cmd. When something fails there, I'd guess it dropped to the u-boot prompt. It'd take figuring out what is the statement that the boot.scr, or boot.cmd aborted and what it needs. When that is figured out, you may also be able to do that same 'black magic', passing the variables boot.scr or boot.cmd is expecting. I kind of disliked these 'black magic', the 'right' way is for these to goto the device tree source or overlays (dts files), so that the relevant board use the correct board dts file instead of hard coding them in u-boot. But it is somewhat the 'state-of-the-art' as well as of current, the catch is mainline u-boot won't boot those custom boot.scr and boot.cmd as those 'special' hard coded variables won't be there. if you clone my repository, I've updated a build guide https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/build.md those steps should compile the mainline u-boot for Orange Pi Zero 3 - note with the '1.5GB hack' my repository is managed using quilt https://wiki.debian.org/UsingQuilt to make edits (note those steps in build.md needs to be done at least once prior this) quilt series quilt push patches/1.5GB_OPZ3_fix.patch vi u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c <- or use any editor you prefer quilt refresh <- note this would update patches/1.5GB_OPZ3_fix.patch quilt push -a <- this applies the remaining of the patches # compile it cd arm-trusted-firmware bash arm-trust-fw-make.sh <- normally only need to be done once, not necessary if that is already built prior cd u-boot bash build.sh # test it if necessary # you can rollback all the patches using # quilt pop -a

@voapilro I think there could be another mistake besides that, my memory computation is using unsigned long long, my guess is that'd be 64 bits, that becomes the 'offset' in mctl_mem_matches_top(offset). I made a guess that the unsigned long long would be truncated dropping the high order 32 bits, that would still match the 32 bits based address, but could be wrong. For reasons uncertain, searching for CONFIG_SYS_SDRAM_BASE 'returns a blank' in my source base, as such I took a liberty to define that as 0. A thing is memsz is computed as 2 GB ( 2048 * 1024 * 1024 ), as I guess observed, I'm not too sure if that might be offset away a little, say the 'bottom' 32kb

@voapilro I tried patching those codes into my custom u-boot loader https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ unfortunately, when I tried booting with the updated u-boot, I noted 2 scenarios that is goofy and didn't work first the board is incorrectly detect as a 4GB board. For reasons I'm unsure, the detection is not stable. Sometimes it is detected as a 4GB board, other times 2GB. when it is correctly detected as 2GB, apparently I'm observing the 'dram wraparound' problem, i.e. writing to a little before 2GB spoofs and faked memory at that location when there is actually none. If it is working correctly, it should detect 2048M and return 1.5GB instead. The patch is like such: As such, I reverted the codes to the old 1.5GB hard coded version. It would have been good if this works (well), at least that it can be used on all the different Orange Pi Zero 3 boards

@voapilro, I'd think for 1.5GB, we'd make do with that 1.5GB custom bootloader, I'd likely adopt your codes so that most who use that can benefit from it. As for pushing it to mainline, I'd think it is pre-mature, as that code applies to *all* H616/H618 devices and not simply Orange Pi Zero 3.

@voapilro thanks, I'd do some tests when I've some time, possibly working that into the custom bootloader code so that others can test that as well. I hardcoded 1.5GB as an/the author partly of the h616/h618 dram initialization/detection reported that (some?) 1.5 GB ddr4 dram chips has address wrap around issues https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233 I'm not sure if this is after all true. As if that is true, then that writing to and reading the last accessible address e.g. 2GB would actually return a false match, saying that there is memory there when there is actually none (i.e. writes to somewhere else). my guess would be to patch that custom u-boot loader with this 'version 2' codes and let 'everyone' test it out including those having non 1.5 GB boards. we'd probably need a way to collect some feedback from the 'testers' if after all that 'works'. the notion is that if there is after all no wraparound, the codes can possibly be committed to u-boot mainline, and become codes in the mainline u-boot. That is truly ideal. of course, a catch with this code is that we'd assume the only 'odd' size is only 1.5 GB, it is unknown if there could possibly be some other weird permutations e.g. 2.5 GB, 3.5GB, 1.2GB, 0.9GB etc that may declare 'too little' or 'too much' dram for some such boards. for that i'd think the only 'right' way is to wait till someone release a means to read the dram registers, which stores the actual memory sizes configurations.

hi @TRay I'd like to suggest playing with libgpiod to get familiar with gpiod based gpio access https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/ The readme is quite instructive https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README unfortunately, I've not tried out gpiod itself and wouldn't be able to say much more about it. Other than to say that I found the kernel repo for gpiod / libgpiod and think it is possibly a good way to do some gpio A good thing is libgpiod has bindings like c++ and python / rust https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings/python/examples which means that starting to play with them can start with python etc. e.g. to try to blink a led connected on the header. That (blinking a led) is normally the 'hello world' for embedded / bare metal programming. I'm not sure if more elaborate stuff like spi / i2c is achieved through the same means, those (SPI / I2C) would likely need messing with DTS and even deep down into the drivers and even lower to bare metal to interface with H618 *hardware* registers (for SPI / I2C etc) , it can be a pretty high bar to jump depending on how much information is available and can be found, e.g. is the SPI / I2C hardware after all publicly documented?

note that various armbian os images are linked on github https://github.com/armbian/os https://github.com/armbian/os/releases are you able to download images from there? you probably have to copy that say into a usb thumb/flash drive bring that home and you can try flashing that using dd from your raspberry pi I think there are also torrents link as alternative on the boards web pages, but I'm not too sure if you are able to download torrents say on a public terminal.

blobs are practically 'useless', it is compiled for a particular os, a particular version of it and if it is *undocumented* there is no way to use the blob, and even if they document the api, if you try to use the blob in a different OS say armbian, chances are that a call to the api can *crash*. it is a 'miracle' if those blobs work.

@voapilro @bjorn @Long-Johnny, all psst some fun stuff https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ ok that's the 2nd attempt to create a custom u-boot to boot Armbian on 1.5 GB OPi Zero 3 boards, do visit the repository for more info. first you can try that with the 'official' image https://www.armbian.com/orange-pi-zero-3/ but that this u-boot is build from mainline u-boot at the 2024.04 release https://gitlab.com/u-boot/u-boot and that it requires a working /boot/boot.scr or /boot/boot.cmd to boot linux. /boot/boot.scr or /boot/boot.cmd are the boot scripts that actually has u-boot commands which loads the kernel and dependencies and boot linux. if the boot drops you into a command shell, it could mean either that the /boot/boot.scr or /boot/boot.cmd is invalid or that it is using a *custom* u-boot and the /boot/boot.cmd, /boot/boot.scr uses or is expecting some variables that is not there in 'standard' mainline u-boot. I managed to boot to the Linux command prompt this time ! I'd just like to say that I took the Armbian Bookworm minimal image from the Armbian release web for Orange Pi Zero 3 Armbian_community 24.5.0-trunk.474 6.6.28 https://www.armbian.com/orange-pi-zero-3/ did my u-boot patch, run it on my 1.5 GB Orange Pi Zero 3 and it booted to the prompt! and just right now Here is a screenshot running from Orange Pi Zero 3 - 1.5 GB board tethered from usb-uart to debug console, I ran the command 'free' which shows that the total memory is 1.5GB how about that for a proof-of-concept without this u-boot 'patch' u'd get 'stuck' at the boot reporting 2GB seen on the usb-uart debug console for the 1.5GB board. men I feel like celebrating, now Armbian runs on 'all variants' of Orange Pi Zero 3 - 1 GB / 1.5 GB (with this hack) / 2 GB / 4GB

SPI tft can be quite an adventure (possibly difficult) to get going, but you can take a look at this project for some hints. https://github.com/notro/fbtft it would also take figuring out how to work SPI on Armbian and Zero 3 not tried that yet.

thanks, I'd probably try that some time. if audio for HDMI works, I think many users will be happy, I've read some comments some are looking for that. currently, I'm using headless as wifi ap, so I did not know if it works. analog may need to go back into h616 zero 2 to see how it is done there, maybe dts etc.

I kinda remember that in the original image, u-boot can be extracted from there the same way posted a few comments earlier, that with the u-boot SPL bin file and instructions. I looked at the /boot/boot.cmd from the some-files-from-boot-folder archive thoughts are that things could have changed between u-boot versions as new u-boot versions 'advanced' till today, though I'm not sure if Orange Pi could have made some customizations in u-boot (the actual core u-boot code itself) so that the /boot/boot.cmd works the way they wanted it. e.g. that some of the 'environment variables' may not be there in the 'standard' u-boot. that could cause the boot script to fail and hence what you saw. to get things back on track, I'd guess restoring the old u-boot could be a simplest resort, but the 'old' 1.5g issue stays with that u-boot. to be upfront, I'm learning all these new as well, u-boot basically run a bunch of scripts within the 'environment (with variables)', u-boot's own (specialized) shell commands / scripts. there is a bunch of scripts (environment (variables)) in the 'standard' core, then along the way core u-boot scripts evaluates/calls the scripts in /boot/boot.scr (if it exists), if not /boot/boot.cmd directly, that enables u-boot to 'pass' 'environment variables' between the core u-boot to the scripts in /boot/boot.cmd in the linux root partition. this will more than likely break things (e.g. script fail) when u-boot tries to run a /boot/boot.cmd that use 'environment variables' not there in the 'standard'. of course, this technique is 'powerful', everything is 'black magic' - undocumented, can vary with every different implementation of /boot/boot.cmd in infinite number of permutations (e.g. you can always add a variable in core u-boot for your hardware, then reference it in the /boot/boot.cmd (or /boot/boot.scr), then a 'standard' implementation would simply throw error once it reach there. not that it is 'wrong', but that that is the state of the art, 'bleeding edge' if you'd like to call it. that is the state of the art of the embedded world infinite permutations of permutations and no 2 of them are 'standard'. raspberry pi uses u-boot as well, so do a 'thousand' other soc and boards and no 2 u-boot implementation is 'the same', among all of all of them.

@voapilro oops, did you backup your original u-boot from the image? to restore this, you would need that u-boot backup. some u-boot bin files are customized with particular ways to start the kernel and that stored into u-boot in that 1st 1 meg or so. For the standard u-boot, it uses files in /boot/boot.cmd or /boot/boot.scr in the Linux root partition to boot linux, that is normally the case for Armbian distributions btw that scary prompt is the u-boot command prompt / shell https://docs.u-boot.org/en/latest/usage/index.html https://linux-sunxi.org/U-Boot https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html try ls mmc 0 [directory e.g. /, /boot etc] and 'help' in the u-boot command prompt, confusing at least if you can post the contents of /boot/boot.cmd in the root partition, normally those are the commands to boot linux from u-boot. If that is goofy (incorrect), linux will not boot. Those bunch of u-boot commands are critical to start linux. normally that can be compiled into another file called /boot/boot.scr (that is for an older version of u-boot) u-boot reads that /boot/boot.cmd (or /boot/boot.scr) which contains the commands to start linux with the kernel image, ram disk and the device tree binary (also called the flattened device tree FDT) this is so that changing the kernel probably means only editing /boot/boot.cmd (and generate /boot/boot.scr if needed)

ok just an update, I managed to get past that '1.5GB' issue the hack is done in u-boot, but the bad news is that that alone won't fix things: This gpu over temperature is nonsense, the chip is hardly warm and this same image boots just fine on a 2GB device with the 'standard' u-boot. It'd seem that some other things is at play here, e.g. that the registers for 1.5GB model are after all different and may need a different DTS configuration. I don't have a solution to go forward for now for 1.5GB devices, configuring DTS takes much more than this little hack, in the sense that we'd not know if this gpu thermal thing is the only odd thing or that there are other things that needs to be fixed as well. -- for those who insist if you would like to test this solution, the attached file is the modified u-boot compiled from https://source.denx.de/u-boot/u-boot https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1353 the function arch / arm /mach-sunxi /dram_sun50i_h616.c function mctl_calc_size() is modified as: static unsigned long mctl_calc_size(const struct dram_config *config) { u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ unsigned long long memsz = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; log_info("detected memsize %d M\n", (int)(memsz >> 20)); /* 1.5 GB hardcoded */ memsz = 2048UL * 1024UL * 1024UL * 3 / 4; return memsz; } i.e. that 1.5GB is *hardcoded*, obviously this won't be appropriate for most boards except in particular case of 1.5GB. Initially, i placed an if statement that says if the detected ram is 2GB say that it is 1.5GB, that is bad as well as then 2GB boards will simply read 1.5GB. however, during tests, I noted that the detected dram size varies between 2 GB and 4 GB. my guess is there are timing issues associated with the 1.5GB dram chip, hence I resorted to hard coding which does not bother how much dram is really detected. if you prefer to build u-boot from sources, follow instructions from here: https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html To use this modified u-boot, the best practice is to start with / use an image that is known to work on 1GB / 2GB / 4GB Orange Pi Zero 3 boards. update: the modified u-boot is in this repository https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ you can download the u-boot-SPL.bin from there. assuming that your image SD card is mounted at /dev/sdX, you can backup your existing u-boot e.g. sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024 that should backup the u-boot in your device to u-boot-backup.bin then to write the modified u-boot into the SD card it is (be sure that you are writing to the correct device ! mistakes here can corrupt your existing hard disks / storage) sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8 it may be possible to write that to an existing image file (do backup your image file beforehand) dd if=u-boot-sunxi-with-spl.bin of=file.img bs=1024 seek=8 conv=notrunc but that I've not tried this. I've created a 'sd image u-boot patcher' uploaded here in github gist: https://gist.github.com/ag88/cebfcd2bc1b413d2a0d43dafa6b572f0 usage: sdimage-u-boot-patcher.py [-h] [--nobak] [--ignimgsize] [--bkname BKNAME] image uboot_bin patch u-boot binary into image positional arguments: image image file uboot_bin u-boot bin file options: -h, --help show this help message and exit --nobak do not backup u-boot SPL from image --ignimgsize ignore image size check --bkname BKNAME u-boot SPL backup file name you need python3 to use that 'sd image u-boot patcher' https://www.python.org/downloads/release/python-3123/ run it as python3 sdimage-u-boot-patcher.py imagefile.img uboot-spl.bin This python script will first extract and backup the u-boot bin image from the image into u-boot-SPL-backup.bin in the current directory. This helps in case something goofs up, you can try restoring it with python3 sdimage-u-boot-patcher.py --nobak imagefile.img u-boot-SPL-backup.bin it is a console app, which means that for Windows users, it'd need to be run in a Cmd prompt window. note: I've not tried running this in Windows, only tested in Linux. This may help for 'Windows' users who may not have access to commands like 'dd' which is mainly available in unix, Linux. This is so that you can patch the image file directly and perhaps use Balena etcher https://etcher.balena.io/ or Rufus https://rufus.ie/en/ to write the image to an SD card / usb drive. In linux, it is found that the sdimage-u-boot-patcher script can actually update /dev/sdX directly. But that it it cannot determine the image size as it is a device and normally it'd need to be run as root. Hence, I've added a --ignimgsize ignore image size check flag for those who wanted to use it that way. e.g. sudo python3 sdimage-u-boot-patcher.py --ignimgsize /dev/sdX uboot-spl.bin This python script will first extract and backup the u-boot bin image from the image into u-boot-SPL-backup.bin in the current directory. This helps in case something goofs up, you can try restoring it with sudo python3 sdimage-u-boot-patcher.py --ignimgsize --nobak /dev/sdX u-boot-SPL-backup.bin this is 'slightly safer' than using dd as sdimage-u-boot-patcher actually validates the image format (it look for signatures for a master boot record this can still be confused with a regular disk, and a signature for u-boot at around 8k. it would prompt that the image does not appear to be valid linux image if it either can't find the master boot record 1st sector and the u-boot signature at 8k. you can then stop the patch by pressing control-c or answering 'n' when prompted to continue. for a valid image, it also verifies that the u-boot bin file should not overwrite into the root partition and note this is caveat emptor (let the user beware, use at your own risk), there is no assurance if after all it fixes anything or break other things.

I got past that DRAM: 0 Bytes it is my own goof when I'm editing the u-boot codes U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 18:04:53 +0800) sunxi_board_init DRAM:sunxi_dram_initmemsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ... the hack seemed to work next I'd need to learn u-boot,

@usual user I think this is what happens, within the microprocessor soc, there is sram likely small 10s-100s of K bytes is likely, so the on board rom loads u-boot as a SPL (secondary program loader) also into s-ram. Then that u-boot needs to *clock the dram* (i.e. setup the dram so that it is actually working), determine dram size, configure dram to be up and running e.g. the 'rows and columns', setup memory mapping. All these in *sram* it did not even touch dram. Then that once everything is up, u-boot loads the *linux kernel* into dram, pass over the DTS and pass over the dram memory size and jumps into the kernel code, then linux boots up from there on. The trouble is that u-boot did not detect the DRAM and the codes is directly from the stem (mainline) https://source.denx.de/u-boot/u-boot I added a lot of debug() statements to trace execution flow and it seemed apparently that it did not even go into the dram initialization parts of the code. So I actually need help with the u-boot codes. I can't figure out why it is not working. All that BL31 etc is mainly for power management (e.g. shutdown / suspend etc), didn't seem to deal with DRAM https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/allwinner/sun50i_h616

@voapilro, @bjorn, @electricworry I'm attempting to fix (at least a hack) the 1.5GB problem by attempting to build a custom u-boot to attempt to resolve the issue. The thing is the codes are pretty complex. https://docs.u-boot.org/en/latest/ https://source.denx.de/u-boot but that actually I succeeded in building u-boot The trouble is I'm getting this: U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) DRAM: 0 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ion U-Boot 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) Allwinner Technology size=30, ptr=590, limit=2000: 26370 CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 0 Bytes So I literally need help with the codes, I'm doing pretty tedious debug etc with a 1.5G OPi Z3 board I bought for this purpose. if you run the 'original' images, that has a 'working' u-boot, it reads DRAM 2GB https://www.armbian.com/orange-pi-zero-3/ still 'incorrect' but that accordingly there'd be fixes for it (in u-boot) https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/42 https://gist.github.com/iuncuim The trouble as i try to trace where the calls are going is that it is not even going into the dram initialization codes in u-boot meant for H616/H618 to initialize and size up the lpddr4 dram. the codes are complex and I'd hope to get some leads there to attempt a solution. if a 'custom u-boot' can fix that, it'd at least help those who still only have 1.5GB boards to get Armbian running on it. By *replacing* the u-boot (practically the boot loader (and BIOS)) in the image or sd card. The image (and on the SD card) looks like this 0-7 KB (unused/reserved) 8 KB - 1 MB u-boot 1 MB - the rest of your sd card (this is your linux partition and Armbian proper (Debian or Ubuntu) lives here) u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing, and then passing that across to linux during boot up. and linux uses the device tree (DTB, DTS) to configure the various devices uart, usb, sd card, leds, etc etc and subsequently present various of them in /dev. a 'custom u-boot' apparently seem to be a most feasible 'solution' (hack) to at least get past the 1.5GB problem. it is quite easy to simply take the original image, and substitute one u-boot made to say the memory is 1.5GB.