lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<Armbian-Discord> <M​icroLinux (Salva)> okay downloading debian sid from that repo balbes
<Armbian-Discord> <M​icroLinux (Salva)> Okay, @balbes150 so far armbian efi (I didn't know that we had armbian efi builds that also included uboot, I supposed that efi images do not have bootloader at all) debian sid xfce works fine on my T4, everything seems normal aside some normal warnings. Writing the system to the emmc now.
<Armbian-Discord> <T​onymac32> it's just u-boot with nice upholstery
<Armbian-Discord> <T​onymac32> is this a spearate EFI image from the ones @rpardini is making?
<Armbian-Discord> <M​icroLinux (Salva)> What I noted it's that we still have a problem on xfce armbian images they still use auto xfwm (WM) mode by default, and that performs horrible compared to xpresent mode
<Armbian-Discord> <M​icroLinux (Salva)> It seems like that
<Armbian-Discord> <T​onymac32> why.
<Armbian-Discord> <M​icroLinux (Salva)> No idea, ask balbes
<Armbian-Discord> <T​onymac32> shrugs not my project at the end of the day I guess
<Armbian-Discord> <M​icroLinux (Salva)> I am new to EFI
<Armbian-Discord> <T​onymac32> fragmentation isn't worried about, or even noticed.
<Armbian-Discord> <M​icroLinux (Salva)> Okay
<Armbian-Discord> <M​icroLinux (Salva)> I think I got it
<Armbian-Discord> <M​icroLinux (Salva)> Well, no, wasn't able to understand how to set it to xpresent system widely, but to shift to xpresent you need to use "xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "xpresent" --create"
<Armbian-Discord> <M​icroLinux (Salva)> Tried fedora efi with your image, but once it boots, it dies.. probab it's working and just not doing any hdmi output
<Armbian-Discord> <M​icroLinux (Salva)> I can check it from uart
<Armbian-Discord> <T​onymac32> hmmm, I booted EFI fedora using the generic rockchip64 kernel with no modification
<Armbian-Discord> <T​onymac32> U-boot *
<Armbian-Discord> <T​onymac32> not kernel rofl
<Armbian-Discord> <T​onymac32> I have a T4 running pre-media-kernel rockchip64, if I can test without destroying my stable system let me know
<Armbian-Discord> <M​icroLinux (Salva)> Well, I reached grub
<Armbian-Discord> <M​icroLinux (Salva)> Then, wheb trying to boot fedora.. it sinks
<Armbian-Discord> <M​icroLinux (Salva)> No hdmi output
<Armbian-Discord> <T​onymac32> probably a fault in the device tree then
<Armbian-Discord> <T​onymac32> unless the U-boot has been modified from our defaults, then I don't have any idea
<Armbian-Discord> <T​onymac32> if the rockpro64 can do it, well, anything should be able to 🙂
<Armbian-Discord> <M​icroLinux (Salva)> Sure sure
<Armbian-Discord> <M​icroLinux (Salva)> This have to be resolved buddies since xfce is our main DE
<Armbian-Discord> <M​icroLinux (Salva)> Armbian efi pardini works fine from sd while @balbes150 5.19 debian sid uefi on the emmc on T4. Also noted that the xfce fixes are there, so, it may be just related to the balbes fork not having xpresent set on their fork
<Armbian-Discord> <T​onymac32> Kernel family, it's part of Armbian, not a fork :).
<Armbian-Discord> <M​icroLinux (Salva)> T4 is so robust. It lacks of spi, aside that and the price... such a nice hw
<Armbian-Discord> <T​onymac32> I really like the board. It could use SPI. I am willing to pay for something that isn't shit 😄
<Armbian-Discord> <T​onymac32> we need more boards without gimmicks built into them
<Armbian-Discord> <M​icroLinux (Salva)> We have any friendlyarm friend here?
<Armbian-Discord> <T​onymac32> no idea. I can talk to their US distributor, like Rich
<Armbian-Discord> <M​icroLinux (Salva)> Yeah, I lost their discord server link
<Armbian-Discord> <T​onymac32> a shame the SoC is so old, that board stretched into a (real) pico-ITX form factor with SPI flash would have been a killer, and given them a little more room.
<Armbian-Discord> <T​onymac32> it's only a bit shallow compared to Pico-ITX
<Armbian-Discord> <T​onymac32> like Radxa they were determined to put an analog audio plug on the connector side, so they have the Type-C oddly positioned off the side
<Armbian-Discord> <T​onymac32> shrugs again, these are all toys, so I guess I should lighten up
<Armbian-Discord> <M​icroLinux (Salva)> Well, yeah, toy's is a difficult concept on our ecosystem.. they all are at some extent
<Armbian-Discord> <M​icroLinux (Salva)> But well, @balbes150 , everything seems to work okay aside fedore. Armbian efi pardinu boots and function properly
nitropep has joined #armbian-rockchip
<Armbian-Discord> <b​albes150> Thanks for checking. Can you try to add (for example, just copy\duplicate the kernel and initrd files with other names) additional items in the startup selection menu and check the selective startup mode ? Did I understand correctly that you were able to install the system on eMMC in efi mode? Have you used the standard procedure (nand-sata-install)? Pardini build scripts use incorrect partition generation
<Armbian-Discord> logic for EFI.
<nitropep> Hello armbian rockchip community I am writing to you because I have installed armbian distro on my nanopi m4v2 and it seems that in all of them the wifi/bluetooth and GPU drivers are not working properly can I solve this problem of course I can participate having some Linux skills
<Armbian-Discord> <l​anefu> Keep an eye on this commit. Not sure if we will need for the new production pine book pros. https://github.com/FrangaL/kali-arm/commit/6790a16667e9602300a850e532de4e9b6a00eada
<Armbian-Discord> <r​pardini> True. I never handled nand-sata-install for the UEFI builds, it of course does not work (it would need to create the ESP partition, deploy grub, etc -- all stuff I did in image generation time, not board-side unfortunately). When I did the UEFI images, I imagined the UEFI firmware would be 100% separate, say, in SPI or eprom, as is the case for x86... I never targeted having u-boot -> EFI -> GRUB, but I
<Armbian-Discord> imagine we can come up with a way to make way for applying a (board-specific) uboot on top of the UEFI arm64 images and it will just work....
<Armbian-Discord> <b​albes150> I meant that you use a "strange" partition formation scheme (from the beginning you create a ROOT, then an efi partition 15 and then you start changing their numbers). I have removed all these "oddities" and the assemblies work fine with EFI (including the partition extension works correctly) on all tested models, including RISC-V. And if I understood correctly, the installation on eMMC in EFI mode is checked
<Armbian-Discord> on T4 and works correctly.
<Armbian-Discord> <r​pardini> Yep -- the strangeness (partitions 14 and 15) come from me trying to reproduce the EFI scheme used by Ubuntu -- that is required by a few cloud providers. It is not strictly necessary.
<Armbian-Discord> <T​onymac32> grabbing a notebook so I can learn something
<Armbian-Discord> <r​pardini> it's very weird indeed: partitions 14 and 15 come first physically on the disk, but are later in number-order.
<Armbian-Discord> <r​pardini> (also I think 14 is only on x86, where in addition to UEFI I also support the old x86 (32-bit) legacy "BIOS" boot -- for old x86 machines)
<Armbian-Discord> <T​onymac32> Would it make sense to have a "cloud" and "iron" image? 🙂
<Armbian-Discord> <T​onymac32> I haven't had any issues booting the EFI stuff you've made on hardware
<Armbian-Discord> <r​pardini> Yeah, I focused on cloud from the start since that's what I had access to on the arm64 front (and I didn't consider uboot -> EFI) at the time
<Armbian-Discord> <T​onymac32> But if it is a little goofy as per Balbes150, maybe not a bad idea
<Armbian-Discord> <r​pardini> but it seems Ubuntu's layout is quite well accepted and works on Iron as well
<Armbian-Discord> <r​pardini> also that grub.sh extension does way too much stuff in a very messy way
<Armbian-Discord> <r​pardini> so maybe we could redo a board/image that does more sane partitioning, and maybe uses systemd-boot instead of grub
<Armbian-Discord> <r​pardini> and use that as EFI-for-SBC's
<Armbian-Discord> <T​onymac32> Have we (Igor/team/you) made a roadmap for merging next?
<Armbian-Discord> <T​onymac32> (unrelated but related)
<Armbian-Discord> <r​pardini> not yet 🤦‍♂️ -- it's my fault -- I've yet to gather all the stuff I have in there in bullet points, and present status of each
<Armbian-Discord> <T​onymac32> Haha ok
<Armbian-Discord> <r​pardini> some things worked very well I think (eg: getting rid of mkdebian and general packaging patches etc) others, like the damned not-shallow-git-clones not so much
<Armbian-Discord> <r​pardini> but the real thing was just logging and error control, all the helper functions to avoid the bash shenanigans like EVALPIPE, I really should split those and prepare for merge
nitropep has quit [Remote host closed the connection]
<Armbian-Discord> <r​pardini> maybe also interesting to explore: https://www.gnu.org/software/grub/manual/grub/html_node/devicetree.html seems like we can give GRUB a dtb explicitly -- so uboot's internal DT would be used only for loading EFI, but with this, maybe kernel will get full DT translated...?
montjoie has quit [Ping timeout: 252 seconds]
montjoie has joined #armbian-rockchip
<Armbian-Discord> <T​onymac32> For our uses that could probably be helpful, since so many of the vendors have garbage software support
<Armbian-Discord> <T​onymac32> For some others it won't be necessary
<Armbian-Discord> <b​r> Is there any reason I should or shouldn’t use the generic ARM64 build on my Pinebook Pro?
<Armbian-Discord> <b​r> I figure that having a boot menu can be useful and nice, even though booting is slower, but I don’t know if there are any drawbacks to booting my PBP with UEFI this way
<Armbian-Discord> <b​r> I’m using the latest Tow-Boot firmware on SPI
<Armbian-Discord> <M​icroLinux (Salva)> I use the armbian-config for installing it into the emmc, yes
<Armbian-Discord> <c​0rnelius> ah... that seems to be the key to getting the Odroids to boot using uefi/grub. devicetree /location/to/dtb Nice find.
<Armbian-Discord> <c​0rnelius> now if they could just add a fdtoverlay bit to it.
<Armbian-Discord> <r​pardini> this might help @MicroLinux (Salva) with his EFI panfrost / video driver too
<Armbian-Discord> <M​icroLinux (Salva)> Panfrost worked just fine on efi, but on rockchip T4, not on amlogic zeros