ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Logs: -> irc.armbian.com
Malditron has joined #armbian
norwich_ has joined #armbian
norwich has quit [Ping timeout: 240 seconds]
norwich_ is now known as norwich
xoan4 has joined #armbian
xoan has quit [Ping timeout: 240 seconds]
xoan4 is now known as xoan
xispita is now known as Guest5697
Guest5697 has quit [Killed (copper.libera.chat (Nickname regained by services))]
Dagger has quit [Ping timeout: 255 seconds]
Dagger has joined #armbian
slacker_HD has joined #armbian
slacker_HD has quit [Quit: Connection closed]
Nobz has joined #armbian
<Nobz> Hello anyone can help me with devicetree overlay?
<Nobz> i have one orange pi pc 2 and i need to put this work with 2-Channel Isolated CAN Expansion HAT from Waveshare
<Nobz> But im stuck with .dts and overlays
<Nobz> anyone there?
Malditron has quit [Quit: Konversation terminated!]
slacker_HD has joined #armbian
c0rnelius has quit [Ping timeout: 248 seconds]
c0rnelius has joined #armbian
lemonzest has joined #armbian
Nobz has quit [Quit: Connection closed]
p0g0__ has joined #armbian
Flecks has joined #armbian
mpmc_ has joined #armbian
MrFixIt has quit [*.net *.split]
smcavoy has quit [*.net *.split]
Mangix has quit [*.net *.split]
[TheBug] has quit [*.net *.split]
AlienTrooper has quit [*.net *.split]
clee has quit [*.net *.split]
Fleck has quit [*.net *.split]
mpmc has quit [*.net *.split]
p0g0_ has quit [*.net *.split]
clee has joined #armbian
mpmc_ is now known as mpmc
AlienTrooper has joined #armbian
Mangix has joined #armbian
MrFixIt has joined #armbian
Smedles has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Smedles has joined #armbian
cheakoirccloud has quit [Quit: Connection closed for inactivity]
archetech has quit [Quit: Leaving]
alekksander has joined #armbian
slacker_HD has quit [Quit: Ping timeout (120 seconds)]
xispita has joined #armbian
sunshavi has quit [Ping timeout: 272 seconds]
Tenkawa has joined #armbian
lemonzest has quit [Quit: WeeChat 3.5]
<Armbian-Discord> <T​enkawa> I use a custom build of Debian that uses syslinux/extlinux instead of the petitboot/uboot (boot.scr /boot.ini) methods that are in the armbian and tobetter images. I can post the kernel config however part of the debug and implementation for me was disabling petitboot and using this method.
<Tenkawa> s/boot.ini/boot.cmd/
<ArmbianHelper> Tenkawa thinks Armbian-Discord meant to say: <T​enkawa> I use a custom build of Debian that uses syslinux/extlinux instead of the petitboot/uboot (boot.scr /boot.cmd) methods that are in the armbian and tobetter images. I can post the kernel config however part of the debug and implementation for me was disabling petitboot and using this method.
sunshavi has joined #armbian
<Armbian-Discord> <c​0rnelius> I'm pretty sure Armbian is using extlinux and u-boot on the M1 builds. The question is whats different? Besides the partition table I would think its the kernel defconfig. On the img ur booting its gpt at 2048 followed by the RK offset to ROOTFS. The Armbian img has the RK offset followed by gpt and then rootfs. I believe.
<Armbian-Discord> <c​0rnelius> both imgs are using either the tobetter kernel or patch set. I only add like 2 extra patches, one being a missing pcie patch.
lemonzest has joined #armbian
<Armbian-Discord> <M​anoftheSea> Can I ask for an explanation of that ordering again? gpt at 2k? RK offset?
sunshavi has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
sunshavi has joined #armbian
<Armbian-Discord> <T​enkawa> The partition table for the M1 has an second offset embedded partition table right @c0rnelius ?
<Armbian-Discord> <c​0rnelius> 1:2048:+4MB (GPT); 2:32768 (ROOTFS)
<Armbian-Discord> <T​enkawa> it is a kind of an odd creation indeed
<Armbian-Discord> <M​anoftheSea> is "GPT" the right name? You're saying that's a partition, for firmware? Shouldn't it be BIOS?
<Armbian-Discord> <c​0rnelius> yes
<Armbian-Discord> <c​0rnelius> the gpt name is uboot in this case
<Armbian-Discord> <c​0rnelius> as its required according to the wiki
<Armbian-Discord> <M​anoftheSea> okay.
<Armbian-Discord> <M​anoftheSea> because petitboot looks for it by name
<Armbian-Discord> <c​0rnelius> well the loader or whatever
<Armbian-Discord> <c​0rnelius> if you compile the uboot ur self you can actually change the name.
<Armbian-Discord> <c​0rnelius> but seeing as the loader is flashed to the board, there is no point
<Armbian-Discord> <T​enkawa> they call it a protective mbr
<Armbian-Discord> <T​enkawa> Partition table scan: MBR: protective BSD: not present APM: not present GPT: present
<Armbian-Discord> <c​0rnelius> the board is straight odd
<Armbian-Discord> <T​enkawa> indeed
<Armbian-Discord> <M​anoftheSea> MBR in the last bytes of sector 0, says the whole disk is one partition. GPT in sector 1, says there's a GPT table at some place (usually, 2-33). And then descriptions of a BIOS type partition at 2k for the next 4megs, to cover the u-boot install at 16384? Or is it an EFI or vfat type, with an actual filesystem?
<Armbian-Discord> <M​anoftheSea> but... the bootloader is in spi, so there shouldn't need to be code at 64 and 16k, right?
<Armbian-Discord> <T​enkawa> I'm not using spi at all
<Armbian-Discord> <c​0rnelius> the gpt partition is not formatted to anything and the rootfs is ext4 (unless Tenkawa changed it?)
<Armbian-Discord> <T​enkawa> yeah I left it ext4
<Armbian-Discord> <M​anoftheSea> I'm just not understanding "gpt partition". What's in it?
<Armbian-Discord> <c​0rnelius> a uboot bin is flashed to it
<Armbian-Discord> <c​0rnelius> just the bin though, the loader isn't flashed. unless other RK boards.
<c0rnelius> unlike*
<Armbian-Discord> <M​anoftheSea> so, not the SPL or TPL at 64, just u-boot, and that based on its label rather than its offset?
<Armbian-Discord> <c​0rnelius> yes.
<Armbian-Discord> <M​anoftheSea> okay, I think I understand. Thanks.
<Armbian-Discord> <c​0rnelius> np
<Armbian-Discord> <T​enkawa> I verified that the image they are currently testing is using extlinux as well
<Armbian-Discord> <T​enkawa> so that leaves really only the kernels and part layout
<Armbian-Discord> <r​pardini> There's nothing crazy about "the board". It's just the vendors' SPI (booted by default unless button pressed during power-on) is a bit crazy.
<Armbian-Discord> <T​enkawa> actually.... Its a very odd board
<Armbian-Discord> <T​enkawa> from a design standpoint
<Armbian-Discord> <r​pardini> Yep, I'm using extlinux, but that's irrelevant here. The question is button or no button, and thus "vendor's blobs + SPL in SPI" or "blobs from the SD".
<Armbian-Discord> <M​anoftheSea> I want to hear why
<Armbian-Discord> <T​enkawa> I don't use the button
<Armbian-Discord> <r​pardini> do you have GPT with uboot label in SD?
<Armbian-Discord> <T​enkawa> I don't use a microsd
<Armbian-Discord> <M​anoftheSea> and you wiped SPI flash, that was said too, right?
<Armbian-Discord> <r​pardini> well this is confusing.
<Armbian-Discord> <T​enkawa> yes.. I also disabled petitboot completely
<Armbian-Discord> <T​enkawa> using this page (looking up url)
<Armbian-Discord> <c​0rnelius> according to the wiki its called a bypass 🙂
<Armbian-Discord> <r​pardini> if you wiped SPI, and have no SD card, then how in hell does it boot?
<Armbian-Discord> <T​enkawa> emmc chainload to bvme
<Armbian-Discord> <T​enkawa> ls -l /dev/disk/by-id/mmc lrwxrwxrwx 1 root root 13 May 23 18:03 /dev/disk/by-id/mmc-BJTD4R_0x4c848cdb -> ../../mmcblk0 lrwxrwxrwx 1 root root 15 May 23 18:03 /dev/disk/by-id/mmc-BJTD4R_0x4c848cdb-part1 -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 15 May 23 18:03 /dev/disk/by-id/mmc-BJTD4R_0x4c848cdb-part2 -> ../../mmcblk0p2
<Armbian-Discord> <T​enkawa> Samsung 32gb emmc
<Armbian-Discord> <r​pardini> yeah. but with zeroed SPI == holding the button.
<Armbian-Discord> <T​enkawa> no
<Armbian-Discord> <c​0rnelius> run this in pboot: fw_setenv skip_spiboot true
<Armbian-Discord> <T​enkawa> thanks
<Armbian-Discord> <T​enkawa> couldnt find which page on the wiki
<ArmbianHelper> ^ odroid-m1:software:boot_sequence [ODROID Wiki]
<Armbian-Discord> <T​enkawa> was trying to go through the list one by one
<Armbian-Discord> <c​0rnelius> so with that triggered it seems you can just boot the board normal and avoid pboot. just no nvme boot without chanload
<Armbian-Discord> <T​enkawa> yep
<Armbian-Discord> <T​enkawa> I don't mind chainloading one bit to have the nvme root
<Armbian-Discord> <T​enkawa> lrwxrwxrwx 1 root root 13 May 23 18:03 /dev/disk/by-id/nvme-WD_BLACK_SN750_SE_250GB_21211E800430 -> ../../nvme0n1
<Armbian-Discord> <r​pardini> I'd not like to start another war with HK telling users to wipe SPI.
<Armbian-Discord> <T​enkawa> its not wiped... just turned of
<Armbian-Discord> <c​0rnelius> as far as I know its not really wipe
<Armbian-Discord> <c​0rnelius> "bypass"
<Armbian-Discord> <T​enkawa> exactly
<Armbian-Discord> <T​enkawa> same as N2/N2+ had with the switch
<Armbian-Discord> <r​pardini> ok guys, but if not wiped, and not holding button, SoC will boot from SPI. both SPL and uboot will run from SPI (thus vendor's), only at the very latest moment booting extlinux or boot.scr from eMMC or SD
<Armbian-Discord> <c​0rnelius> not sure how to get it back though as the wiki says run the opposite, but how are you suppose to run it with out access to pboot?
<Armbian-Discord> <r​pardini> skip_spiboot true
<Armbian-Discord> <T​enkawa> yeah... how do you get it back there?
<Armbian-Discord> <T​enkawa> "you can't"
<Armbian-Discord> <r​pardini> abort autoboot via UART?
<Armbian-Discord> <T​enkawa> exactly
<Armbian-Discord> <T​enkawa> so SPI is "not" being used
<Armbian-Discord> <T​enkawa> I think you are missing the difference between SPI and SPL
<Armbian-Discord> <c​0rnelius> I think the loader is still being used and looking for the partition labeled "uboot" and with that setenv in place its just skipping pboot altogether.
<Armbian-Discord> <r​pardini> exactly
<Armbian-Discord> <T​enkawa> the SPI gets skipped by SPL if skip is set to true
<Armbian-Discord> <T​enkawa> and boots to emmc/sd according to their boot flowchart
<Armbian-Discord> <M​anoftheSea> Am I right to say that normally, tpl loads spl, spl loads u-boot, and on this board, u-boot loads petitboot? So if you change the environment, which of those can even check it? u-boot? So u-boot returns to spl, which then attempts to load from the next device?
<Armbian-Discord> <T​enkawa> it does
<Armbian-Discord> <T​enkawa> it does not run boot.scr in spi if that skip setting is enabled
<Armbian-Discord> <T​enkawa> so even if spi is running it is bypassed
<ArmbianHelper> ^ odroid-m1:software:boot_sequence-m1-v2.png [ODROID Wiki]
<Armbian-Discord> <T​enkawa> bottom left sequence
<Armbian-Discord> <r​pardini> yes. that means everything is loaded and run from SPI.
<Armbian-Discord> <T​enkawa> no
<Armbian-Discord> <r​pardini> just the boot.scr is loaded from eMMC
<Armbian-Discord> <T​enkawa> well.. whatever is happening I am breaking the rules then
<Armbian-Discord> <r​pardini> I'm just reading the diagram man.
<Armbian-Discord> <M​anoftheSea> So if "skip spi" is set, then the SPL loads u-boot from then next device (emmc, here?). But if SPI is wiped, then it's the bootrom code that goes to emmc sector 64?
<Armbian-Discord> <r​pardini> nope. if skip_skipboot == true, it already loaded both SPL and uboot from SPI.
<Armbian-Discord> <T​enkawa> it also is missing an important yes/no on the button image at the top
<Armbian-Discord> <r​pardini> the eMMC can have just filesystem with boot.scr and it will work.
<Armbian-Discord> <T​enkawa> poor graphing
<Armbian-Discord> <r​pardini> yes. that diagram is confusing "yes/no"
<Armbian-Discord> <T​enkawa> so it could be working from that top node down
<Armbian-Discord> <r​pardini> also "bootloader in eMMC/SD?" has inverted yes/no
<Armbian-Discord> <M​anoftheSea> and it's possible that u-boot returned to SPL, right, such that another copy of it from emmc BIOS partition labeled "uboot" could be loaded?
<Armbian-Discord> <T​enkawa> and if so... it "is" bypassing PI completely
<Armbian-Discord> <r​pardini> well call you what you want. it's bypassing the final step, but not everything else.
<Armbian-Discord> <T​enkawa> I don't care about the semantics... It is working
<Armbian-Discord> <r​pardini> my point here is: one day ™️ we'll have mainline uboot for rk3568...
<Armbian-Discord> <r​pardini> and I'd like to have an image ready for that when it happens
<Armbian-Discord> <T​enkawa> no... I have it working right now
<Armbian-Discord> <c​0rnelius> when ATF gets it together
<Armbian-Discord> <r​pardini> so delivering an image that requires vendor blobs / SPL / uboot in SPI does not cut it
<Armbian-Discord> <T​enkawa> well were you not here for the world of Broadcom?
<Armbian-Discord> <r​pardini> heh, but HK evidently went out of it's way to allow for post-SPL in SD/eMMC, so I'm trying to make it work
<Armbian-Discord> <T​enkawa> that is true
<Armbian-Discord> <M​anoftheSea> so... if vendor's SPI TPL/SPL were to do something "nefarious", the current situation is that u-boot can be loaded from emmc, but the TPL/SPL still runs. The desired state is to replace vendor TPL/SPL with open-sourced ATF and u-boot?
<Armbian-Discord> <T​enkawa> How good of a vendor is Khadas btw?
<Armbian-Discord> <T​enkawa> that new SoC they've got coming out has me intrigued
<Armbian-Discord> <M​anoftheSea> vim4?
<Armbian-Discord> <T​enkawa> yeah
<Armbian-Discord> <T​enkawa> I already have a Rock5 coming for the Rockchip world
<Armbian-Discord> <T​enkawa> this Amlogic though looks nice
<ArmbianHelper> ^ A311D2 has a completely different (and not supported upstream) HDMI 2.1 controller and USB3 USB complex, and plenty of other small changes in regards to A311D. You will need to use downstream kernel for a while - Neil Armstrong (@Superna9999) April 15, 2022
<Armbian-Discord> <c​0rnelius> and its to damn pricey
<Armbian-Discord> <r​pardini> yep. I'm not touching the VIM4 until Neil says so
<Armbian-Discord> <T​enkawa> yeah... but then again... "you" know what I'm typing on right now
<Armbian-Discord> <T​enkawa> I did find the Odroid-M1 makes a nice cluster compile server controller (good io backplane) just got finished running a test with it
<Armbian-Discord> <I​gorPec> there will certainly be others comming out with the chip. but if you ask about Khadas, they are doing nice boards
<Armbian-Discord> <T​enkawa> the Khadas looks like a good quality board
<Armbian-Discord> <I​gorPec> yes. software wise they are also not that bad. legacy junk is everywhere junk ... and until mainline is not ready enough ...
<ArmbianHelper> ^ ODROID-M1: add new board Hardkernel ODROID-M1 based on RK3568 · hardkernel/u-boot@356906e · GitHub
<c0rnelius> hmm
<Tenkawa> so
<Tenkawa> /* Load SPI firmware when boot device is SPI flash memory
<Tenkawa> * and environment value 'skip_spiboot' is not 'true'
<Tenkawa> so if set... spi b=is bypassed
<Armbian-Discord> <T​enkawa> thats the way "I" interpret that comment
<Armbian-Discord> <c​0rnelius> looks like it can just be a setenv var in the boot.scr file.
<Armbian-Discord> <c​0rnelius> or config.ini or whatever.
<Armbian-Discord> <c​0rnelius> not sure how that could be set using extlinux though.
<Armbian-Discord> <T​enkawa> but it does look like it does block spi
<Armbian-Discord> <r​pardini> nah. it is only read from uboot env (which is in SPI). what is does is change bootcmd from the default run distro_bootcmd (which will do extlinux first, boot.scr later) to loading a boot.scr in a cramfs in SPI.
<Armbian-Discord> <r​pardini> (oops wrong reply-to above)
<Armbian-Discord> <T​enkawa> then why comment "load * if not true"
<Armbian-Discord> <T​enkawa> that defeats the point
<Armbian-Discord> <T​enkawa> thats the whole point... you skip... to not load
<Armbian-Discord> <r​pardini> btw: binwalk the raw SPI mtdblock... and you'll find both the uboot env and the cramfs
<Armbian-Discord> <M​anoftheSea> and the cramfs, that just chainloads to another u-boot?
<Armbian-Discord> <r​pardini> nope, once cramfs is read, it boots boot.scr there, and the rest of their Petitboot stuff
<Armbian-Discord> <r​pardini> Petitboot is a tiny kernel + tiny rootfs
<Armbian-Discord> <r​pardini> my peeve with all this is: the actual binaries in SPI shipped from factory DO NOT correspond to the source code in their Github.
<Armbian-Discord> <M​anoftheSea> oh, I had the logic backward. so u-boot either runs distro_bootcmd, or it loads the boot.scr and falls back to distro_bootcmd (which it isn't expected to reach)
<Armbian-Discord> <r​pardini> and if I build the uboot myself from their code, boot it with button (thus no SPI involved at all), I get no eMMC and no HDMI -- even when using their own vendor kernel.
<Armbian-Discord> <r​pardini> my guess is 1) rpardini is stupid, very likely or 2) they've one or two secret/embarassing commits they've omitted from github...
Tenkawa has left #armbian [Was I really ever here?]
<Armbian-Discord> <r​pardini> either way I'm super happy with tobetter's work. His 5.18 odroid-m1 branch is clean & rebased & rebasable. He's added even the Amlogic stuff there now too, it's almost sane. This might be a great signal they're willing to properly maintain this.
<Armbian-Discord> <c​0rnelius> i personally wish he would have kept the rockchip sep from the amlogic.
<Armbian-Discord> <M​anoftheSea> hey, don't name-call on rpardini like that
<Armbian-Discord> <r​pardini> It's very easy to separate. He's keeping Amlogic "on top".
<Armbian-Discord> <c​0rnelius> yeah I saw
<Armbian-Discord> <r​pardini> and it does make me think we could have the concept of "vendor" kernels in Armbian; a single meson+rk kernel for all of ODROID.
<Armbian-Discord> <r​pardini> well, not really all, considering Exynos, but you see my point.
<Armbian-Discord> <c​0rnelius> accept he has a tendency to break shit. and he dropped Exynos in 5.17 I believe.
<Armbian-Discord> <c​0rnelius> he isn't supporting it anymore or so he says
<Armbian-Discord> <T​onymac32> Ewwwww
<Armbian-Discord> <T​onymac32> 😆
<Armbian-Discord> <c​0rnelius> so extracting his patchset was super easy for 5.17
<Armbian-Discord> <r​pardini> yeah I agree, threw up in my mouth a little after saying that. dunno what's come over me.
<Armbian-Discord> <r​pardini> anyway, if any of you build the full uboot (all blobs and SPL / whatever) and manage to make it work on M1 I'd be very interested. my aim is to allow Armbian users to stick an SD in there and have it work without fussing with buttons or uboot env...
<Armbian-Discord> <r​pardini> also: anyone tested SATA? 😄
<Armbian-Discord> <I​gorPec> i tried that 5 x sata pci card
<Armbian-Discord> <I​gorPec> but it was not working
<Armbian-Discord> <I​gorPec> https://amzn.to/39VVMa8
<ArmbianHelper> (REDIRECT) ^ Dpofirs M2 PCIe B Key to 5 x SATA 6G Adapter Card, Internal 5 Port SATA 6GB/s M.2 B Key Adapter Card for OS X, for Linux, for Windows: Amazon.de: Electronics & Photo
<Armbian-Discord> <c​0rnelius> what distro are you using to build the uboot?
<Armbian-Discord> <c​0rnelius> you can use the cross tools available in debian bullseye to build it. you don't really need their silly toolchain.
<Armbian-Discord> <r​pardini> I'm using Armbian x86 Jammy to build it... complete with their rkbins
<Armbian-Discord> <c​0rnelius> i used bullseye with the rkbins. built just fine.
<Armbian-Discord> <r​pardini> yep.... but when booting it from SD (with button!) then I get no HDMI on 4.9 and no eMMC on 5.18.
<Armbian-Discord> <c​0rnelius> strange
<Armbian-Discord> <r​pardini> yep, I'm stumped.
<Armbian-Discord> <c​0rnelius> fix ur part table. its crazy 🙂
<Armbian-Discord> <r​pardini> yeah, I've hammered it very horribly I know. But it does work -- I can't see how eMMC/HDMI could have anything to do with part table.
<Armbian-Discord> <c​0rnelius> nor me, but according to what I've seen the only diff between the img you put together and the one I did is the part table. at least thats the only thing that stood out to me.
<Armbian-Discord> <c​0rnelius> i mean kernel is kernel and I can't speak to that
<Armbian-Discord> <c​0rnelius> i don't aqctually have the board.
<Armbian-Discord> <r​pardini> yeah, I guess kernel .config could have a part with the 4.9/HDMI problem, but not with 5.18/eMMC.
<Armbian-Discord> <c​0rnelius> yeah
<Armbian-Discord> <r​pardini> if I produce an image just like HK's Ubuntu... without any uboot, just boot.scr or extlinux + kernel + rootfs... how would I instruct users to boot it? holding button won't do it; will have to show how to skip_spiboot which seems asking for angry ppl who then wanna "go back to Petitboot" and can't.
<Armbian-Discord> <M​anoftheSea> can't linux access the environment variables?
<Armbian-Discord> <M​anoftheSea> you could use fw_setenv to overwrite skipies.
<Armbian-Discord> <r​pardini> yeah, that could be; I haven't seen work to enable SPI in 5.18 yet. Maybe further down the line when it's settled.
<Armbian-Discord> <r​pardini> oh wow, interesting thing, this might be working in the very latest builds (since NVMe works). But I was asking about the onboard SATA port, which is muxed with USB3/NVMe.
<Armbian-Discord> <I​gorPec> pci bridge is seen but nothing on it
<Armbian-Discord> <I​gorPec> but i never tried this card anywhere else
<Armbian-Discord> <c​0rnelius> he is missing a pcie patch in his branch last time I checked.
<Armbian-Discord> <c​0rnelius> or maybe its not needed? don't know.
<Armbian-Discord> <T​enkawa> [ 0.228268] rockchip-dw-pcie 3c0800000.pcie: host bridge /pcie@fe280000 ranges: [ 0.228330] rockchip-dw-pcie 3c0800000.pcie: IO 0x0381000000..0x03810fffff -> 0x0001000000 [ 0.228356] rockchip-dw-pcie 3c0800000.pcie: MEM 0x0381100000..0x03bfffffff -> 0x0002000000 [ 0.240166] rockchip-dw-pcie 3c0800000.pcie: iATU unroll: enabled [ 0.240189] rockchip-dw-pcie 3c0800000.pcie: Detected iATU regions:
<Armbian-Discord> 8 outbound, 8 inbound [ 0.444914] rockchip-dw-pcie 3c0800000.pcie: Link up [ 0.445157] rockchip-dw-pcie 3c0800000.pcie: PCI host bridge to bus 0002:20
<Armbian-Discord> <c​0rnelius> i just know the patch set I saw at lore "if I recall correctly was 4 to 6 patches" and if branch was missing one. https://paste.debian.net/1241992/
<ArmbianHelper> ^ debian Pastezone
<Armbian-Discord> <T​enkawa> Mine appears to have the link showing up too
<Armbian-Discord> <T​enkawa> 0002:20:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3566 (rev 01) 0002:21:00.0 Non-Volatile memory controller: Sandisk Corp Device 501e
maknho has quit [Ping timeout: 272 seconds]
Smedles has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Smedles has joined #armbian
maknho has joined #armbian
cheakoirccloud has joined #armbian
alekksander has quit [Ping timeout: 255 seconds]
<Macer> Finally got the serial cable for my pinebook pro.
<Macer> Will be interesting to see where all the fun begins with it.
fizikz has quit [Remote host closed the connection]
<Armbian-Discord> <W​erner> Something like this? https://twitter.com/DieZuckerbude/status/1371782237671292928
<ArmbianHelper> ^ I like my music in a very specific baudrate. And you? pic.twitter.com/b1Lfxx55aG - Ben Zucker 🇺🇦 (@DieZuckerbude) March 16, 2021
<buZz> Macer: what are you running on it
<Macer> Right now manjaro.
<Macer> I was running armbian but couldn’t get it to boot from emmc.
<buZz> hmhm
<Macer> So I wanted to see if I could find a cause for that (and other things)
<Macer> Armbian img didn’t seem to want to boot from SD either until I wrote uboot manually to it.
<buZz> i'd love to run plain debian or devuan on such machine
<buZz> i have a samsung xe503c32, 8core exynos5800 32bit , 4gb ram
<Macer> Debian is a bit convoluted to get going on it. DietPi runs on it tho.
<buZz> ~10hr batterylife
<buZz> debian supports many arm devices as install target though
<buZz> like Nokia N900 :D
<buZz> hmm, not pro, but there's a pinebook article
<ArmbianHelper> ^ CategoryLaptopComputer - Debian Wiki
<ArmbianHelper> ^ InstallingDebianOn/Samsung/ARMChromebook - Debian Wiki
smcavoy has joined #armbian
<Armbian-Discord> <I​gorPec> last change 2018-03-06 21:57:57
toketin_ is now known as toketin
<Macer> Lol
<Macer> Yah. Pinebook pro can give me a good 12 hours on a charge. S3 still not working tho.
<Macer> If it did it would be the most amazing device ever.
<Armbian-Discord> <T​enkawa> I would just be happy to find a reseller to buy the pinebook pro in the states.. I'd like to use it for my on the go laptop (I have a good arm laptop but it will not be put through the back and forth of my cycling)
<Armbian-Discord> <T​enkawa> I have a x86 laptop currently but its the only x86 I have left anymore
<Armbian-Discord> <T​enkawa> (not my only laptop)
archetech has joined #armbian
<buZz> nice
lemonzest has quit [Quit: WeeChat 3.5]
<Macer> Tenkawa: you can always order one from pine64.com but just make sure you get the serial cable, and nvme adapter. maybe even an emmc to usb adapter if you want to not have a huge headache with it later. :)
<Macer> i still need to figure out exactly what is going on with armbian when it doesn't boot off emmc. and the fact that it seems like armbian img doesn't have uboot or something to that nature.
<Macer> armbian+gnome was acutally pretty decent tho tbh
<Armbian-Discord> <T​enkawa> they are on backorder
<Macer> they're always on backorder .. they do the batch thing.
<Macer> i've actually been using it day to day with manjaro + xfce
<Macer> but not having suspend is a pain :/
<Macer> the whole piont was to have long battery ilfe and a suspend is a big part of that. i guess it's still being worked on though so i'll see how it goes.
<Macer> like.. i'm on it right now :)
<Armbian-Discord> <T​enkawa> I'm still mostly stuck in my house so its no big rush yet
<Armbian-Discord> <T​enkawa> I just don't want to take my "good" arm laptop out or my heavy x86 out on my bike when I do go ouot
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #armbian
archetech has quit [Quit: Leaving]
<Armbian-Discord> <Z​anoryt> Hello, is there a channel that is appropriate for troubleshooting a build?
<Armbian-Discord> <M​icroLinux (Salva)> Maybe? What happened?
<Armbian-Discord> <Z​anoryt> I have the same build -- successful one way, unsuccessful another. Build 1 -- Ubuntu 20.04 VM (running in Parallels) building via Docker method -- builds the image fine and completes without error. Build 2 -- Ubuntu 20.04 and 22.04 VM (running via GitHub Workflow Action) build via Docker method -- build fails during the end at install_deb_chroot [ o.k. ] Applying common tweaks 1744 [ .... ] Cleaning [ package
<Armbian-Discord> lists ] 1745 [ .... ] Updating [ package lists ] 1746 [ .... ] Temporarily disabling [ initramfs-tools hook for kernel ] 1747 [ .... ] Installing PACKAGE_LIST_FAMILY packages [ ethtool ] 1748 [ .... ] Installing [ linux-u-boot-current-rockpi-4b_22.05.0-trunk_arm64.deb ] 1749 [ .... ] Installing from repository [ linux-image-current-rockchip64 ] 1750 [ error ] ERROR in function install_deb_chroot [ main.sh:588 -> main.sh:549 ->
<Armbian-Discord> debootstrap.sh:69 -> distributions.sh:321 -> image-helpers.sh:225 -> general.sh:0 ] 1751 [ error ] Installation of linux-image-current-rockchip64 failed [ rockpi-4b focal no rockchip64 ] 1752 [ o.k. ] Process terminated 1753 [ error ] unmount_on_exit() called! [ main.sh:1 -> image-helpers.sh:0 ] 1754 [ o.k. ] Unmounting [ /home/runner/work/aros/aros/build/.tmp/rootfs-449d4faa-8592-4f7b-abe3-10e0d57bd10a/ ] 1755 [ error ] ERROR in
<Armbian-Discord> function unmount_on_exit [ main.sh:1 -> image-helpers.sh:94 -> general.sh:0 ] 1756 [ error ] debootstrap-ng was interrupted 1757 [ o.k. ] Process terminated 1758 Error: Process completed with exit code 255.
<Armbian-Discord> <Z​anoryt> The build/output/debug/debootstrap.log does not exist.
archetech has joined #armbian