Gunjan Gupta

TV out might work, its not tested though. The DTS changes for the same was part of HDMI changes that were merged. But there is no audio support added yet so you will not have any audio.

just look at the output and share the same here especially close to the moment the board crashes

I did said we can document whats needed on the download page. If required, we can even add a picture giving full list of features that will be available on headers that will correctly show 2 spi pins. We don't have to follow what shown in Orange Pi's documentation. If user would be so hell bent on following Orange Pi's documentation, they would most likely be using Orange Pi's images. After all their documentation also says how to flash their images. They won't come to Armbian.

There are two chip select pins for each spi interface on H616, infact that is the case for most Allwinner boards. User can choose to use either one of them or both of them. You are hung on the idea of enabling everything as per orangepi's own documentation and hence you think both i2c3 and spi should be enabled out of box. Yes both can be enabled, but user has to select chip select 1 to do the same. Work in progress. If you see my activity on git, jira, discord and forums, you can easily see I am working on multiple things. I am almost working more than 40 hours a week making changes and testing things for Armbian. And as I said before community support device is not at the top of my priority list. If the overlays would have implemented the same way as H6, then this could have been easily handled in armbianEnv.txt by setting param_spidev_spi_cs=1. Also we could have document this on download page as well. We could have stated there that orangepi's documentation is incomplete and it doesn't show all possible config options.

I am not sure what issues you are having when trying to build. Could you please share the logs? I personally am building on MBP 2019. All that is needed is to have docker installed. The build system will make use of it if its available. Then just run ./compile.sh it will present you with the available options. Also check this video explaining the process -

Logic was simple, I was missing the context of the change. A PR is not just a code change. It also documents why the change is made. I couldn't have explained that myself at that point of time. Now that I took a look at the datasheet and orangepizero3 layout and I think I understand now why it was proposed, though I don't agree with the change now. I would suggest to add a new entry for spi1_cs1_pin pointing to PH9. If someone needs to connect two spi devices and don't need to use i2c3, they can still make use of CS0 aka PH5 pin. Just because orangepi's documentation list PH5 as i2c doesn't really limit the pin to be i2c only. It will still be possible to use PH5 as SPI1_CS0. Hence I suggest to add entry for SPI1_CS1 instead of modifying SPI1_CS0.

Hmm, 10 base-t and 100 base-tx only uses 4 of the 8 ethernet pins, while a 1000 base-tx will use all 8 pins I wonder if the extra 4 pins causes the issue

I guess those logs are for @going. I really can't do anything about 23.10 image that going is sharing, That is an Armbian fork and not Armbian itself.

which can be easily fixed by running date command. Anyways, does it breaks for you if you plugin ethernet. Were you using it with or without ethernet?

I have a feeling that this is same as Not 100% sure though.

@Tu Hu Does thing works correctly if you boot without ethernet pluged into it?

There looks like some residue around the pins, may be thats the flux. But anyways try cleaning that with some alcohol This photo makes it look like there is something shorting tx and rx pin. Looks like a jumper or something. Not sure if what I am seeing is just lighting or something is really there, If something is there, can you try removing the same. Never mind, I guess you placed it for loopback testing.

I wonder if these issues are related -

@pixdriftI will raise my PR when I am ready. But for the SPI change, could you please raise the PR yourself?

I had most of the commits running on my orange pi 3 lts and as they were tested I included the same. I do have some leftover commits for zero3 in my local git that I have still not pushed. I was planning to test everything and push them on the coming weekend. Is it ok if I defer this to be included in that as well?

Feedback are always welcome. But even when changing this value, user will either have to build uboot deb, install the same and then update bootloader from armbian config or create a new image. If the user is willing to do all that, I guess it will not be too hard to change value in a text file. After all if we make it configurable that had to be documented somewhere and documentation is already too far behind. And I am not sure how many people read documentation. I personally prefer code to documentation, most of people I know do the same too. But it can probably be a cultural thing

Yes patching is still there. The context behind moving that from out of the patch to the hook is actually pretty simple. In the last 7 months, I have done quite a few number of u-boot bumps and most commonly broken patches are that of defconfig files. So I decided to move the broken defconfig patches to board config file utilising the hook system in order to avoid wasting time on fixing defconfig patches in the future. The same was explained in the PR that contained the change as well. Plan was to migrate them as they gets broken.

Yeah response was based on me being confused from the overall message. I hope there is not hard feeling over it either

https://github.com/armbian/build/pull/6228

Maximum value I see is 21 config/kernel/linux-arm64-sm8250.config:CONFIG_LOG_BUF_SHIFT=21

I did checked it out. It was only changed in one place for BPi M3. I hope you are not suggesting to change for every other board as well. I was only talking about this patch - patch/u-boot/u-boot-sunxi/board_bananapim3/adjust-default-dram-clockspeeds.patch . And I think we already have users with 3 different types of board here. As I understand you represent the set for whom the current patch works well. This also makes you the perfect candidate to test if removing the patch keeps the board working well as well. Once you can confirm that, we can ask @AaronNGray and @Tu Hu to try the same image as well

I was only able to relocate the patch that sets the value. Not sure where you found it encoded in the build system for BPi M3. Anyways does removing the patch and booting from corresponding images fixes the issue? I can not test as I don't have the board.

I think this is fine. I noticed this issue on Allwinner H6 SoC as well. So I think this will benefit other SoCs as well. The sunxi64 I believe covers A64, H5, H6, H616/H618 I think they will be fine.

Those links are not reachable

On my board I don't have the headers soldered. I just held a male to male jumper cable in place and tested the same and it worked fine. Have you soldered the headers? I wondered if there is a short somewhere. Can you share the photos of the board from both front and back?