Stephen Graf

@pixdrift Would you please look at dmseg on your orangepizero2 to see if it starts at time 0. I came across this in the internet: Your kernel's ring buffer ran out and the first entries were removed for new entries. Simply set CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT larger in your kernel config. yeah now works with 19! ~ $ cat /usr/src/linux/.config | egrep CONFIG_LOG_ CONFIG_LOG_BUF_SHIFT=19 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

I am asking for help in resolving an issue with dmesg and journal not starting at time zero on the orangepizero2. I don't' know about the zero2. I am actually trying to determine why bluetooth only works on the initial boot and never again after a reboot. I am booting from spi flash to a usb hard disk. The dmesg started at time .03 sec on the initial boot and only at time .6 sec on the second boot. In previous investigation I noted the journal indicates missing about 150 messages on boot. I am not sure if the missing data would help in my bluetooth investigation, but I feel very uncomfortable without the data. I have no idea of where to start looking at the missing data problem. An armbianmonitor -u has been uploaded: https://paste.armbian.com/isajocaper

Orangepizero2/3 are using spi0 internally to connect to the 16MB flash memory on the boards. Spi1 is available and should be enabled by a working overlay in the near future. In the meantime if you can find the driver source, it should be easy to change the spi port and cs in the code as they are usually just definitions. As an aside, if you are looking to use a tpm for secure boot, you should be looking at u-boot and not Armbian.

@MrK I think you owe @Gunjan Gupta an apology. There is no need for such language when people are volunteering their time and efforts, or ever for that matter. @MrK you are in the wrong forum. Changes such as you are proposing should be done at the Linux kernel level. @MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment. You will get more things done and with better results. If you had been working for me I would have fired you for behaving this way. It is just too disruptive.

I think this was meant for @SteeMan attention. I was following this discussion and I think the discussion should be going on upstream not at the Armbian level.

For hardware work I find 1GB is plenty. As Bill Gates once said "who needs more than 512KB".

When I was working with u-boot to test the orangepizero3 implementation there was an issue with memory size not being detected properly. The issue was resolved by raising the default memory speed parameter to the value recommended for LPDDR4. I have not seen an reported problems since then.

I think the bigtree board is the one that is causing all this conflict. It is a very specialized board built for a specific function - to run 3D printers. Bigtree paid Armbian to set up the image and they got the paid treatment regardless of the compatibility with other boards. I suspect future h616 and h618 boards will be much more alike and not similar to the bigtree board. As for the devices that hang on the spi and i2c buses, there are hundreds of them. Go to AliExpress and search for "i2c device". There is no way to provide overlays for each of them. My suggestion is to provide overlays for the the main i/o that the SBC advertises and brings out to the headers. If users want to implement some of the other muxed functions then it should be the users responsibility to provide a user overlay which does not impact the build environment. Yes there will be many overlays that are common between boards and yes there will be some overlays that are not. The difficulty is how to deal with the overlays that are not in common.

@Igor What is the status of the orangepione? On the download page there are no images presented yet in the build framework is shows up as "conf" in the support (1st) page.

@Gunjan Gupta Yes I can see that you are trying to take on too much and no I don't think this is that urgent. However in the interests of moving forward, is there anyone else who would have some cycles to deal with this? I would like to follow your proposal and stay with the existing naming convention for the time being. As the orangepizero3 is the first h618 SOC, in keeping with the existing procedures we should create a new overlay structure called sun50i-h618. I could recreate the patch for the overlays (5) that I think are useful for the zero3. Then by the time new h618 boards are added you may have had time to revisit the whole issue. In the meantime let others do the work. This change will not impact any other board. As I am proposing to stay with the existing procedures. I don't think this patch will require any significant time from you. I can see from @SteeMan comments that trying to improve things will be a big headache. What do you think?

@ag123@Gunjan Gupta@pixdriftLet's try to go back to fundamentals to see what we are trying to resolve with the overlays. I will try to give you an idea of what a hardware developer would think about when deciding on a specific SBC. The SBC designer will have made some choices as to what i/o will be available on the board. The SOC has numerous options of which only a few will be implemented. The hardware developer will look at the array of boards available and choose one that readily provides the functions that he thinks he would need. I chose the orangepizero3 based on the availability of i2c (aka twi), spi and gpio which is very similar to the orangepione that I have a lot of experience with. My problem is trying to get this i/o enabled via the usual armbian-config procedure. @Gunjan Gupta has taught me how to write overlays and I have been able to patch the dtb directly to get the i/o working. But that is not the preferred procedure. In the process I have come to question the rational of tying the overlays to the SOC instead of the SBC. Should the overlays for orangepizero3 be labelled sun501-h618? That would be an easy solution for today as there are no other h618 boards. I think the bigtree board should not have been allowed to use the label sun50i-h616 for its overlays as that board is a very specific implementation for a particular environment. After further reflection I don't think enabling the i/o in the dtb is the best idea. It is usually better to keep things turned off if not in use. @pixdrift Think of your problem with the half plugged in serial to usb adapter. In a similar vein I would recommend that gpu, bluetooth, wifi and hdmi not be always enabled. Many users will run a headless server using these boards and all these unused devices add a lot of software overhead in addition to the extra power drain and associated heat generated. I am not sure this moves us further along in resolving the issue, but I hope it provides some stimulus for thought.

@MrK Try the spidev_test tool. It has many options to set various parameters such as speed. https://github.com/rm-hull/spidev-test/blob/master/README.md

@pixdrift Thank you. I will test current on zero3. I don't think zero3 is supported on legacy. I have a monitor with hdmi and audio and can test sound over hdmi on zero3. I can also test analog sound from the header if the sound fix works for both.

@pixdrift If you want to proceed with a PR please go ahead. If you apply the patch to your repo I will build and test on current for the zero3. I still have concerns with a number of items that might be related: - Bluetooth only working on the initial boot - pinctl errors on boot - dmesg log not starting at time 0.

@MrK You should try the build from @pixdrift (edge only). https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix There is only one overlay item for spi, spi1, PH6,7,8 and cs0, which is on PH9 as per the orangepizero2/3 drawings. I have not put a scope on the pins but tested with spidev_test and a loopback on SI/SO which returns the correct data. I also put a meter on PH9 and it goes high during the test.

@pixdrift If your serial to usb adapter is not connected on the usb side, where is it getting power from? This could be a cause for possible garbage characters appearing on the input of the serial side that would stop u-boot. It is also possible for the serial side to oscillate (if not powered) just from the voltages on the output pin and u-boot is trying to decode a lot of garbage. Bus usb@5200400: USB OHCI 1.0 scanning bus usb@5200000 for devices... 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Autoboot in 2 seconds, press <Space> to stop Card did not respond to voltage select! : -110 Regarding an overlay for the leds. Currently in the dtb the leds are defined as: leds { compatible = "gpio-leds"; led-0 { function = "status"; color = <0x01>; gpios = <0x14 0x02 0x0c 0x00>; linux,default-trigger = "heartbeat"; }; led-1 { function = "power"; color = <0x02>; gpios = <0x14 0x02 0x0d 0x00>; default-state = "on"; }; }; What would you propose? Overlays can add or change existing lines. They can not remove lines. My recommendation is to just leave them as they are. There is a option to add user defined overlays. Check out the /boot/boot.cmd: for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done There is a catch. If the user overlay messes up the dtb is restored to the state before even the kernel overlays have been added! I think I would like to prepare the overlay patch as a PR to the Armbian master.

@pixdrift Comparing the debug console of the first boot and of a failed startup would be a good place to start. Have you tested on a zero3 with the fast SD? I'm sorry I can not help with the zero2. I am going to test with my hard drive again. If you need to cool things down, I could send you some snow. We had our first snowfall here today, about 20cm.

@pixdrift, @Gunjan Gupta Yes, the output of the serial debug console would be very useful to see how far into the boot process the system got. The speed of the SD card might be the trigger for the problem you are seeing, but I doubt it is the source of the problem. The system boots from a fresh flash and probably runs quite cool until a second boot. I have had an issue with what I think is timing related. I was using a usb hard drive for a system disk and booting from spi flash. The usb disk was twice as fast (40MB/sec) as the SD (17Mb/sec) card. On the initial boot after flash Bluetooth worked properly. After a reboot Bluetooth never worked again (the /dev/bluetooth was not created). I have now put away the usb disk and am using an SD card. I have on occasion seen a failure of Bluetooth on the SD card but am not really checking for it. Another concern I have is that the dmesg log does not start until about 1.6 sec or more instead of 0. This is not right. There is also some problem with setting up pinctl being logged. I dislike testing on a system that I know has problems that could be affecting the testing I am trying to achieve.

I'm curious to see what the zero2 does if you remove overlay_prefix=sun50i-orangepizero2-3 from /boot/armbianEnv.txt. Does it load sun50i-h616 or not find the overlays? On the zero3 it will not find the overlays.

@pixdrift I built an image for the zero3 from your repository and I am not having any difficulties with the overlays. If you think it is the overlays that are causing your boot problems you can try putting your system drive on another machine and removing the overlays line in: sysadmin@orangepizero3:~$ more /boot/armbianEnv.txt verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun50i-orangepizero2-3 rootdev=UUID=8b58b731-6024-4fbe-bd3e-c784b3b9a449 rootfstype=ext4 overlays=i2c3 ir otg-host spi1-cs0-spidev uart5 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Armbian-config creates and modifies this line when you enable/disable overlays. If that resolves the problem try adding overlays one at a time. I would suggest this order: i2c3 ir spi1-cs0-spidev uart5 otg-host

Sorry, wrong patch. Try this one. Moving too fast.arm64-dts-overlay-sun50i-opangepizero2-3-overlays.patch

@pixdrift Attached is the patch and my testing. Can you try it on an zero2. gitdiff.txt overlay_test.txt arm64-dts-overlay-sun50i-opangepizero2-3-overlays.patch linux-serial-test spidev_test

Re: fixup script for orangepizero2/3 I have looked at the script: /boot/dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-fixup.scr and not being any kind of expert have these comments: The first test is for spi that controls the flash chip. Spi0 is already set up properly in the dtb and I have flashed the memory with u-boot successfully without running the fixup.scr. The second test is to fix up spi1 if it is not being used for the flash memory. This is not necessary as spi1 is already set up in the dtb. Additional setup for spi1 should be done in an overlay. The final six items are for pins that are not brought out on the orangepizero2/3 (pps, w1, pm34 and uart1,2,3 rts/cts) and should not be required. This leaves me with an empty script. Is there an option somewhere to prevent the fixup.scr from running? @Gunjan Gupta I looked at the h6 fixup and the h616 seems to be an exact copy.

@ag123 Thank you for the info. I would like to propose the following overlays for orangepizero2 and 3: - i2c3 to enable - spi1 to enable, create spidev and use cs0 - spi1 to enable, create spidev and use cs0 and cs1 - ir to enable - uart5 to enable - usbotg to set to host I don't know what lineout might require until sound is working. Usb2 and 3 are already enabled in the dtb. Does anyone have any suggestions for the fixup script? I have been running the zero3 for a couple of months without it and have not experienced any difficulties. Suggestions/comments are requested.

I have been able to create an overlay for spidev, copying the Zunlong overlays. An overlay is necessary to set disabled to okay ie to enable the device.