peterm6881 has joined #Speedsaver
<peterm6881> hey Xogium
<peterm6881> in your make command string. shouldnt it say /buildroot-mangopi-r3c/ in the path
<Xogium> depends, where you clone it
<Xogium> that's just a placeholder
<Xogium> you could just as well make the directory called mangopi
<peterm6881> yeah but the name of the git repo is fixed
<Xogium> nop
<peterm6881> peter@peter-powermatemlxxx:~/buildroot$ make BR2_EXTERNAL=/home/peter/buildroot-mangopi-r3c/external widora_mangopi_r3_defconfig -O=output/widora-mangopi-r3
<peterm6881> make: *** unknown output-sync type '=output/widora-mangopi-r3'. Stop.
<Xogium> if you git clone with a url followed by a space and another directory name, git will clone the repo in a directory with that name
<Xogium> huh did I typo that
<peterm6881> no idea lol
<Xogium> ah yeah typo
<Xogium> remove the - before the O
<peterm6881> if you're correcting text in the readme, would you mind calling that part of the placeholder the name of the actual git, for idiots like me
<Xogium> isn't it obvious that its a path to where you put the external tree ?
<Xogium> I guess not
<peterm6881> its the MangoPi part of the path that could be more obvious
<peterm6881> path/to is very clear
<peterm6881> peter@peter-powermatemlxxx:~/buildroot$ make BR2_EXTERNAL=/home/peter/buildroot-mangopi-r3c/external widora_mangopi_r3_defconfig O=output/widora-mangopi-r3
<peterm6881> Makefile:194: *** '/home/peter/buildroot-mangopi-r3c/external': no such file or directory. Stop.
<peterm6881> make: *** [Makefile:84: _all] Error 2
<Xogium> huh ?
<Xogium> wait what the
<Xogium> what about it now
<peterm6881> wait
<Xogium> hmm
<Xogium> you might want to cd to the path there. Let me add it
<peterm6881> same
<peterm6881> theres no file or directory just called external in the buildroot-mangopi-r3c directory
<Xogium> I'm not saying there is
<peterm6881> 5 files, 2 directories
<Xogium> external was part of the placeholder I removed
<peterm6881> hmm....
<Xogium> sigh typo in the cd command
<peterm6881> do you see the problems that can cause? path/to is fine, thats universal
<Xogium> hmm I didn't, because I knew there was no file named external
<peterm6881> peter@peter-powermatemlxxx:~/buildroot$ cd output/widora-mangopi-r3c
<peterm6881> bash: cd: output/widora-mangopi-r3c: No such file or directory
<peterm6881> make was ok
<Xogium> mm yeah I fixed the typo in the cd command
<Xogium> was supposed to be r3 not r3c
<peterm6881> sigh...
<Xogium> this whole business with r3 vs r3c is confusing anyway
<peterm6881> given our readme clearly states its only for the R3c, should we not be consistent in the use of that term?
<peterm6881> the current version is r3c, i doubt they will revert to the r3
<Xogium> well they are not consistent with it themselves
<Xogium> they have r3 config
<peterm6881> its a different board, the difference being they switched to a CH341 instead of a CP210, annoyingly
<peterm6881> although as far as the tree is concerned, that shouldnt make any difference, its an external interface
<Xogium> and indeed it doesn't
<peterm6881> im happy to stick with r3, now you've corrected the typo
<Xogium> reckon that's when they also switched the flash though I have no proof of it
<peterm6881> unkless u wanna revert ;)
<peterm6881> unless, obvs
<Xogium> anyway yeah… try to build, let me know if it sticks anywhere else I guess
<peterm6881> ok wait
<Xogium> it could very well stick, I mean my build machine is diffrerent from yours after all
<Xogium> different
<peterm6881> so far so good
<peterm6881> I think we're probably about evens when it comes to stuff building or not building.
<Xogium> you even have the u-boot commands to make it boot manually
<peterm6881> actaully i think my much more generic environment has been slightly more build friendly
<peterm6881> really? You cracked that?
<Xogium> of course, I wouldn't have posted them otherwise
<peterm6881> outstanding.
<Xogium> I'd have held on the committing too given that would produce totally broken stuf
<peterm6881> oh yeah, i see your addendum on current problems
<Xogium> man are folks really that daft ?
<peterm6881> Russia / Ukraine?
<Xogium> I just saw someone filling his entire ultrasonic cleaner with isopropyl alcohol
<peterm6881> thats not gonna end well, either of them
<Xogium> well, he says he's been doing it for years
<Xogium> I'm thinking he's either bullshitting or very lucky
<peterm6881> :)
<Xogium> IPA has a very low flash point
<Xogium> even if you have a blast-proof tank which he doesn't ! You risk an explosion from the gas that will inevitably escape in the air around the cleaner, should even the tiniest spark light up
<Xogium> even ESD sparks
<peterm6881> sheesh, I think hes kidding
<Xogium> he also keep the lids on his glass containers tightly shut, which is an even worse idea
<Xogium> not allowing the gas to escape as the alcohol evaporates is even more dangerous than having it escaping
<peterm6881> maybe its the Jackass guy, come out of retirement
<Xogium> I mean, don't get me wrong, using IPA and flamable solvent in a cleaner can be done, but it requires special equipment, good ventilation and an even better head on your shoulders
<Xogium> and far as I'm concerned, it is unnecessary risks
<Xogium> like that idea that using de-ionized water will help
<Xogium> that's completely false because at the second you pour it into the bath it will get contaminated back with ions
<peterm6881> sry soldering
<peterm6881> build still trucking alone
<peterm6881> along
<Xogium> good
<Xogium> subsequent builds will be faster by the way
<Xogium> the beast here can build the entire system from a make clean to finished image in a minute and a half
<Xogium> but then again its a lightweight image
<Xogium> its not containing more things than unframeworks or the others by the way
<Xogium> they just made a larger ext4 filesystem
<Xogium> Mem: 52.4M 7.2M 37.2M 80.0K 8.0M 41.8M
<Xogium> /dev/root 88.2M 19.5M 61.7M 24% /
<peterm6881> :)
<peterm6881> still building :)
<Xogium> nice, at least even the sound codec is working
<peterm6881> so what would be the next step to loading the software, even just onto the sd card? Given DFU is broken
<Xogium> well probably just incorporate navit package and stuff into our own speedsaver tree
<Xogium> and switch to systemd as init process while we're at it
<peterm6881> im glad you're clear on that, i agree with everything you just said ;)
<Xogium> but having it manually booting each time is sort of exasperating
<peterm6881> uh-oh, trouble
<Xogium> hmm what is it ?
<peterm6881> >>> Executing post-image script /home/peter/buildroot-mangopi-r3c/board/allwinner/generic/scripts/genimage.sh
<peterm6881> make[1]: *** [Makefile:816: target-post-image] Error 1
<peterm6881> cp: cannot stat '/board/allwinner/generic/kernel.its': No such file or directory
<peterm6881> make: *** [Makefile:23: _all] Error 2
<Xogium> hmm
<peterm6881> right at the very end, prob something simple
<Xogium> let me fix that up
<peterm6881> :)
<Xogium> ok fixed. You should just be able to git pull again then it should run ok
<Xogium> just a make, no need to make clean
<peterm6881> will i need to do a make clean?
<peterm6881> okie dokie
<Xogium> this time it should work
<Xogium> but if not then I'll try and reproduce if I can
<peterm6881> do i need this:
<peterm6881> make BR2_EXTERNAL=/home/peter/buildroot-mangopi-r3c widora_mangopi_r3_defconfig O=output/widora-mangopi-r3
<Xogium> for what ?
<Xogium> this is only to generate the config
<peterm6881> do i need to do that too
<Xogium> no
<peterm6881> no then lol
<Xogium> just plain make
<peterm6881> building now
<peterm6881> i have news
<peterm6881> :)
<peterm6881> success
<Xogium> good, good
<peterm6881> go you
<peterm6881> indeed, well done
<Xogium> so in output you get 3 images
<Xogium> sysimage with nand, nor or sdcard
<peterm6881> yup
<peterm6881> => bootm ${kernel_addr_r}
<peterm6881> ERROR: can't get kernel image!
<peterm6881> =>
<peterm6881> Wrong Image Format for bootm command
<Xogium> hmm
<Xogium> did the first command succeed ?
<peterm6881> im using puTTY
<Xogium> like did it tell you something like, 4 million bytes read in
<peterm6881> yes, well there were no errors
<peterm6881> no
<peterm6881> wait ill do it again
<Xogium> huh really
<Xogium> if you can try printenv next, you could try and see if there is a variable called kernel_addr_r defined
<Xogium> => printenv kernel_addr_r
<Xogium> kernel_addr_r=0x80500000
<peterm6881> the first command just bounces back to prompt, with no printout
<peterm6881> kernel_addr_r=0x80500000
<Xogium> right, that's good…
<peterm6881> confirmed
<Xogium> hmm
<Xogium> => load mmc 0:2 ${kernel_addr_r} kernel.itb
<Xogium> 4362356 bytes read in 715 ms (5.8 MiB/s)
<Xogium> can you ls mmc 0:2 and confirm there is kernel.itb in there
<peterm6881> 0 file(s), 0 dir(s)
<peterm6881> erm...no!
<Xogium> what in the world
<Xogium> hmm
<Xogium> that would explain why then
<peterm6881> let me reset and try again, hang on
<peterm6881> by the way im talking to it through putty on the ttl usb socket
<peterm6881> is that ok
<peterm6881> whats your setup
<Xogium> same as you except I use scr4een
<Xogium> er screen that was
<Xogium> hrm
<Xogium> do you have a kernel.itb file in the images directory ?
<peterm6881> yes
<Xogium> ok so that looks good
<Xogium> at least for that part
<peterm6881> try a make clean && make?
<Xogium> yeah, you never know
<peterm6881> ok
<peterm6881> well it worked once time before :)
<peterm6881> one *
<peterm6881> ;)
<Xogium> yeah I'm not sure what went up there
<peterm6881> building now
<peterm6881> so what audio will we have? Alsa?
<Xogium> maybe it fucked up something the first time the post-image script failed to run
<peterm6881> is aplay part of alsa?
<Xogium> I guess so, there's no real need for pulseaudio in there
<Xogium> aplay is part of alsa-utils
<Xogium> like speaker-test
<peterm6881> im guessing we wont have alsa-utils
<peterm6881> yeah
<Xogium> not in that image no, since it's tiny as hell
<peterm6881> do we have alsa-utils?
<peterm6881> ok
<Xogium> but nothing is preventing us from enabling it in our own image
<peterm6881> how do you adjust volume without alsamixer?
<Xogium> huh… that's a bloody good question
<Xogium> I don't know
<peterm6881> is it possible :)
<Xogium> probably… but how ? No idea
<peterm6881> haha was it?
<peterm6881> maybe its there
<Xogium> hmmm nah, don't think so
<Xogium> I think they have a few softwares, busybox as init, and that's all
<peterm6881> what was that command that lists all the installed apps
<peterm6881> can you remember
<Xogium> yeah but that won't work, its for debian specific systems
<peterm6881> ah ok
<peterm6881> no BR equivalent?
<Xogium> hmm there might be some graphing possible
<Xogium> hmm not quite, you can graph dependency between packages, filesystem size contribution per package and the build duration…
<peterm6881> would dpkg -l not work?
<Xogium> dpkg is debian specific
<Xogium> debian and its derivatives use it, but that is about it
<peterm6881> meh
<Xogium> hmm maybe this way
<Xogium> make pkg-stats
<Xogium> you might need to install some python dependency
<Xogium> on arch its called python-aiohttp, not sure what's the name on debian
<Xogium> maybe python3-aiohttp
<Xogium> this should generate packages statistics
<peterm6881> same problem
<peterm6881> load mmc 0:2 ${kernel_addr_r} kernel.itb
<peterm6881> is this correct?
<Xogium> yeah… what in the world
<Xogium> nothing in mmc 0:2 again ?
<peterm6881> the bizarre thing is it wont let me paste the whole thing, I have to manually type the last 6 characters
<Xogium> must be some putty weirdness
<Xogium> going to try a build here
<peterm6881> mmc - MMC sub system
<peterm6881> mmc info - display info of the current MMC device
<peterm6881> Usage:
<peterm6881> mmc write addr blk# cnt
<peterm6881> mmc read addr blk# cnt
<peterm6881> mmc erase blk# cnt
<peterm6881> mmc rescan
<peterm6881> mmc part - lists available partition on current mmc device
<peterm6881> mmc dev [dev] [part] - show or set current mmc device [partition]
<peterm6881> mmc list - lists available devices
<peterm6881> mmc wp - power on write protect boot partitions
<peterm6881> mmc hwpartition [args...] - does hardware partitioning
<peterm6881> arguments (sizes in 512-byte blocks):
<peterm6881> [user [enh start cnt] [wrrel {on|off}]] - sets user data area attributes
<peterm6881> [gp1|gp2|gp3|gp4 cnt [enh] [wrrel {on|off}]] - general purpose partition
<peterm6881> [check|set|complete] - mode, complete set partitioning completed
<peterm6881> WARNING: Partitioning is a write-once setting once it is set to complete.
<peterm6881> Power cycling is required to initialize partitions after set to complete.
<peterm6881> mmc setdsr <value> - set DSR register value
<peterm6881> oh may i messed something up
<peterm6881> maybe
<peterm6881> 0 file(s), 0 dir(s)
<Xogium> hrmm
<Xogium> what about mmc 0:3 that one should contain stuff like usr, var, home, etc.
<peterm6881> ▒H▒!>▒ȞJ▒g▒▒▒▒▒J▒▒JL<▒▒▒▒a1▒H^@▒^X!>▒Ȟ^Xg▒▒▒^XJ▒▒JL<a
<peterm6881> Unknown command 'H^@▒^X!>▒Ȟ^Xg䭌^XJ▒▒JL<a' - try 'help'
<peterm6881> Wrong Image Format for bootm command
<peterm6881> => bootm ${kernel_addr_r}
<peterm6881> => load mmc 0:2 ${kernel_addr_r} kernel.itb
<peterm6881> ERROR: can't get kernel image!
<peterm6881> => load mmc 0:2 ${kernel_addr_r} kernel.itb
<peterm6881> => mmc 0:2
<peterm6881> mmc - MMC sub system
<peterm6881> Usage:
<peterm6881> mmc info - display info of the current MMC device
<peterm6881> mmc read addr blk# cnt
<peterm6881> mmc write addr blk# cnt
<peterm6881> mmc erase blk# cnt
<peterm6881> mmc rescan
<peterm6881> mmc part - lists available partition on current mmc device
<peterm6881> mmc dev [dev] [part] - show or set current mmc device [partition]
<peterm6881> mmc list - lists available devices
<peterm6881> mmc wp - power on write protect boot partitions
<peterm6881> mmc hwpartition [args...] - does hardware partitioning
<peterm6881> arguments (sizes in 512-byte blocks):
<peterm6881> [user [enh start cnt] [wrrel {on|off}]] - sets user data area attributes
<peterm6881> [gp1|gp2|gp3|gp4 cnt [enh] [wrrel {on|off}]] - general purpose partition
<peterm6881> [check|set|complete] - mode, complete set partitioning completed
<peterm6881> WARNING: Partitioning is a write-once setting once it is set to complete.
<peterm6881> Power cycling is required to initialize partitions after set to complete.
<peterm6881> mmc setdsr <value> - set DSR register value
<peterm6881> => mmc 0:2
<peterm6881> mmc - MMC sub system
<peterm6881> Usage:
<peterm6881> mmc info - display info of the current MMC device
<peterm6881> mmc read addr blk# cnt
<peterm6881> mmc write addr blk# cnt
<peterm6881> mmc erase blk# cnt
<peterm6881> mmc rescan
<peterm6881> mmc part - lists available partition on current mmc device
<peterm6881> mmc dev [dev] [part] - show or set current mmc device [partition]
<peterm6881> mmc list - lists available devices
<peterm6881> mmc wp - power on write protect boot partitions
<peterm6881> mmc hwpartition [args...] - does hardware partitioning
<peterm6881> arguments (sizes in 512-byte blocks):
<peterm6881> [user [enh start cnt] [wrrel {on|off}]] - sets user data area attributes
<peterm6881> [gp1|gp2|gp3|gp4 cnt [enh] [wrrel {on|off}]] - general purpose partition
<peterm6881> [check|set|complete] - mode, complete set partitioning completed
<peterm6881> WARNING: Partitioning is a write-once setting once it is set to complete.
<peterm6881> Power cycling is required to initialize partitions after set to complete.
<peterm6881> mmc setdsr <value> - set DSR register value
<peterm6881> => ls mmc 0:2
<peterm6881> 0 file(s), 0 dir(s)
<peterm6881> =>
<peterm6881> 0 file(s), 0 dir(s)
<peterm6881> => load mmc 0:2 ${kernel_addr_r} kernel.itb
<peterm6881> => ls mmc 0:3
<peterm6881> <DIR> 1024 .
<peterm6881> <DIR> 1024 ..
<peterm6881> <DIR> 12288 lost+found
<peterm6881> <SYM> 7 bin
<peterm6881> <DIR> 1024 dev
<peterm6881> <DIR> 1024 etc
<peterm6881> <SYM> 7 lib
<peterm6881> <SYM> 3 lib32
<peterm6881> <SYM> 11 linuxrc
<peterm6881> <DIR> 1024 media
<peterm6881> <DIR> 1024 mnt
<peterm6881> <DIR> 1024 opt
<peterm6881> <DIR> 1024 overlay
<peterm6881> 669 preinit
<peterm6881> <DIR> 1024 proc
<peterm6881> <DIR> 1024 root
<peterm6881> <DIR> 1024 run
<peterm6881> <SYM> 8 sbin
<peterm6881> <DIR> 1024 sys
<peterm6881> <DIR> 1024 tmp
<peterm6881> <DIR> 1024 usr
<peterm6881> <DIR> 1024 var
<peterm6881> =>
<peterm6881> wtf
<peterm6881> ls mmc 0:3
<peterm6881> <DIR> 1024 .
<peterm6881> <DIR> 1024 ..
<peterm6881> <DIR> 12288 lost+found
<peterm6881> <SYM> 7 bin
<peterm6881> <DIR> 1024 dev
<peterm6881> <DIR> 1024 etc
<peterm6881> <SYM> 7 lib
<peterm6881> <SYM> 3 lib32
<peterm6881> <SYM> 11 linuxrc
<peterm6881> <DIR> 1024 media
<peterm6881> <DIR> 1024 mnt
<peterm6881> <DIR> 1024 opt
<peterm6881> <DIR> 1024 overlay
<peterm6881> 669 preinit
<peterm6881> <DIR> 1024 proc
<peterm6881> <DIR> 1024 root
<peterm6881> <DIR> 1024 run
<peterm6881> <SYM> 8 sbin
<peterm6881> <DIR> 1024 sys
<peterm6881> <DIR> 1024 tmp
<peterm6881> <DIR> 1024 usr
<peterm6881> <DIR> 1024 var
<peterm6881> usr and var, no home
<Xogium> well that's fine then
<Xogium> at least the rootfs is in there
<Xogium> but why is your boot partition empty…
<Xogium> I'll try and reproduce it here
<peterm6881> ok
<peterm6881> when I burn the card, I end up with 2 visible partitions, rootfs plus an 8.4 MB volume called AB3A-5861, which contains kernel.itb and splash.bmp
<peterm6881> rootfs is about 19.5 MB and contains 718 files
<Xogium> yep
<Xogium> ermf this is… weird
<Xogium> I confirm that my image does contain both files
<Xogium> kernel.itb and splash.bmp file
<Xogium> can you check the content of the sd card on your machine ?
<Xogium> I suspect the boot partition would be empty but…
<Xogium> just to be absolutely sure
<peterm6881> yeah its the sd card im reading
<Xogium> yeah in u-boot but what about on your machine directly ?
<peterm6881> no i mean ive taken the card out of the board and im reading it directly in an sd card reader on the NEC
<Xogium> ah sorry
<Xogium> and there's nothing ? Damn that's crazy…
<peterm6881> thats where i got the info from
<peterm6881> nothing where?
<Xogium> in the 2 nd partition, the boot one
<peterm6881> is that the one called AB3A-5861 ?
<peterm6881> the one that ISN'T rootfs ?
<Xogium> huh… not sure ?
<Xogium> there is 3 partiton there
<peterm6881> no its either missing or hidden
<Xogium> hmm let me check the genimage config so I don't say nonsense
<peterm6881> when I burn the card, I end up with 2 visible partitions, rootfs plus an 8.4 MB volume called AB3A-5861, which contains kernel.itb and splash.bmp
<peterm6881> thats reading the card on the NEC
<Xogium> right
<Xogium> ok so the card is correct
<Xogium> why does u-boot says 0 files
<Xogium> heck leme check on my u-boot…
<peterm6881> did you try a card on one of your boards?
<Xogium> => ls mmc 0:2
<Xogium> 4362356 kernel.itb
<Xogium> 94514 splash.bmp
<Xogium> 2 file(s), 0 dir(s)
<peterm6881> wow...im stumped
<peterm6881> guess Lubuntu is somehow broke, and yet not broke enough to break
<peterm6881> ;)
<peterm6881> share me an image
<Xogium> can you try and reinsert the card ? I noticed that simetimes the connector seems to be a bit picky and you have to make sure its really got in cleanly
<Xogium> earlier it didn't want to detect my card because it moved like 2 mm away from the end of the socket
<Xogium> that's one thing I don't like about this board frankly, its even easier to lose the micro sd now that it doesn't use a push-pull connector that clicks into place
<peterm6881> no, same
<Xogium> what in the world rofl
<peterm6881> what the screen command
<Xogium> detach putty first then run something like
<peterm6881> device is USB0
<Xogium> sudo screen /dev/ttyUSB1 115200n8
<Xogium> or whatever tty it is on your side
<Xogium> but yeah I don't think putty could somehow lie and tell you 0 files
<Xogium> this is super weird
<Xogium> I mean, the files are definitely there, you saw them yourself
<peterm6881> screen is exactly the same
<peterm6881> share me your image
<Xogium> yep that's expected…
<Xogium> yeah… let me reburn my micro sd first. I want to know if I can make it happen here too
<Xogium> this is an image I had made yesterday
<Xogium> just a second
<peterm6881> is that not where you got this information from:
<peterm6881> <Xogium> 4362356 kernel.itb
<peterm6881> <Xogium> 94514 splash.bmp
<peterm6881> <Xogium> 2 file(s), 0 dir(s)
<peterm6881> <Xogium> => ls mmc 0:2
<peterm6881> u-boot
<Xogium> yes that is u-boot
<Xogium> but this image I burned yesterday, not today
<peterm6881> ahh ok
<peterm6881> understood
<peterm6881> few changes
<Xogium> I assumed that your image really didn't contain those files, not that u-boot itself couldn't find them for whatever reason
<peterm6881> what were you saying about 3 partitions
<peterm6881> 2, surely
<Xogium> u-boot is in its own partition, but its actually hidden
<Xogium> that's why kernel and such is on 0:2 and nont 0:1
<peterm6881> ahh ok
<peterm6881> if i get the prompt, presumably u-boot is not part of the issue
<Xogium> indeed
<Xogium> if u-boot couldn't even run, you'd have nothing over serial
<peterm6881> yes i noticed the version is the like the first thing that prints
<Xogium> fuck's sake the micro sd slot is a pain in the ass
<peterm6881> yeah its umm.... not ideal
<Xogium> oof got it back on
<Xogium> now leme try
<Xogium> erk nop false alarm I have it inserted wrong
<peterm6881> :)
<Xogium> ok I confirm I have not broken anything
<peterm6881> contacts are towards the pcb
<peterm6881> so yours works?
<Xogium> yeah
<peterm6881> lest swap images
<Xogium> good idea
<Xogium> yeah lazy me using the pastebin to transfer that
<peterm6881> i shared mine via wetransfer, check your email
<Xogium> will do
<peterm6881> good news, I can confirm yours works perfectly
<peterm6881> let me try something..
<peterm6881> i worked out whats wrong, at ease soldier
<peterm6881> u wont believe it
<peterm6881> before i tell you, can you confirm you dont have the issue with the image i sent
<Xogium> yeah it works fine
<peterm6881> i knew it would
<peterm6881> after I burned the card, I unmounted it
<peterm6881> just a hunch, becuase its the only thing i was doing different, compared to what I usually do, which is a sudo sync and just pull it out
<peterm6881> every day is a fucking school day
<peterm6881> haha
<peterm6881> you can replicate the fault by unmounting the card after burning
<peterm6881> nuts huh
<peterm6881> anyway the good news , after that Peter induced hiccup, your new repo is in excellent shape
<peterm6881> niceness Xogium
<Xogium> to be fair you shouldn't mount a peripheral if you want to dd to it lol
<Xogium> but yeah sync, always
<peterm6881> i dont mount it
<peterm6881> it just does whatever the OS does, I had the bright idea I should eject it safely, like windows does
<peterm6881> its a desktop environment thing
<peterm6881> interestingly, if i do a reboot through the command line, it introduces the same problem..
<Xogium> huh what do you mean ?
<peterm6881> what happens on your side if you log in and type reboot
<peterm6881> and then try to boot again
<Xogium> I get back to the bootloader eventually, which fails to boot up, so I have to load the stuff again, then bootm, etc.
<peterm6881> loading the stuff stops working for me, even if i pull the power
<peterm6881> yeah i guess all that manual boot stuff will be the first thing to fix lol
<peterm6881> i think thats more than enough for today, dont you think
<peterm6881> well done Xogium
<Xogium> sounds like you have a fucky board or a fucky micro sd
<peterm6881> funky
<peterm6881> what irc server does Buildroot use?
<Xogium> they are still on oftc. Why ?
<peterm6881> i was gonna ask if theres a way to list installed packages
<peterm6881> since we dont actually know whats in this image
<Xogium> you can know what is in it if you check the defconfig
<Xogium> in configs directory, in the mangopi external tree
<peterm6881> BR2_arm=y
<peterm6881> BR2_CCACHE=y
<peterm6881> BR2_ARM_INSTRUCTIONS_THUMB=y
<peterm6881> BR2_PER_PACKAGE_DIRECTORIES=y
<peterm6881> BR2_TOOLCHAIN_EXTERNAL=y
<peterm6881> BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
<peterm6881> BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY=y
<peterm6881> BR2_TARGET_GENERIC_HOSTNAME="mangopi-r3"
<peterm6881> BR2_TARGET_GENERIC_ISSUE="Welcome to Widora MangoPi R3"
<peterm6881> BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
<peterm6881> BR2_ROOTFS_MERGED_USR=y
<peterm6881> BR2_SYSTEM_DEFAULT_PATH="/bin:/sbin:/usr/bin:/usr/sbin"
<peterm6881> BR2_ROOTFS_OVERLAY="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/generic/rootfs $(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/suniv-f1c100s/rootfs $(BR2_EXTERNAL_MANGOPI_PATH)/board/widora/mangopi/r3/rootfs"
<peterm6881> BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/generic/scripts/genimage.sh"
<peterm6881> BR2_ROOTFS_POST_SCRIPT_ARGS="${BR2_TARGET_UBOOT_SPL_NAME}"
<peterm6881> BR2_LINUX_KERNEL=y
<peterm6881> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
<peterm6881> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.4.99"
<peterm6881> BR2_LINUX_KERNEL_PATCH="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/suniv-f1c100s/patch/linux"
<peterm6881> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
<peterm6881> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/suniv-f1c100s/linux.defconfig"
<peterm6881> BR2_LINUX_KERNEL_DTS_SUPPORT=y
<peterm6881> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/suniv-f1c100s/devicetree/linux/suniv-f1c100s.dtsi $(BR2_EXTERNAL_MANGOPI_PATH)/board/widora/mangopi/r3/devicetree/linux/devicetree.dts"
<peterm6881> BR2_PACKAGE_GDB=y
<peterm6881> BR2_PACKAGE_FSWEBCAM=y
<peterm6881> BR2_PACKAGE_FB_TEST_APP=y
<peterm6881> BR2_PACKAGE_UMTPRD=y
<peterm6881> BR2_PACKAGE_TINYALSA=y
<peterm6881> BR2_PACKAGE_LIBV4L=y
<peterm6881> BR2_PACKAGE_LIBV4L_UTILS=y
<peterm6881> BR2_PACKAGE_TSLIB=y
<peterm6881> BR2_PACKAGE_HAVEGED=y
<peterm6881> BR2_PACKAGE_UTIL_LINUX_UUIDD=y
<peterm6881> BR2_TARGET_ROOTFS_CPIO=y
<peterm6881> BR2_TARGET_ROOTFS_CPIO_GZIP=y
<peterm6881> BR2_TARGET_ROOTFS_EXT2=y
<peterm6881> BR2_TARGET_ROOTFS_EXT2_4=y
<peterm6881> BR2_TARGET_ROOTFS_EXT2_SIZE="100M"
<peterm6881> BR2_TARGET_ROOTFS_SQUASHFS=y
<peterm6881> BR2_TARGET_UBOOT=y
<peterm6881> BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
<peterm6881> BR2_TARGET_UBOOT_CUSTOM_VERSION=y
<peterm6881> BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2020.07"
<peterm6881> BR2_TARGET_UBOOT_PATCH="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/suniv-f1c100s/patch/u-boot"
<peterm6881> BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG=y
<peterm6881> BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL_MANGOPI_PATH)/board/widora/mangopi/r3/uboot.defconfig"
<peterm6881> BR2_TARGET_UBOOT_NEEDS_DTC=y
<peterm6881> BR2_TARGET_UBOOT_NEEDS_PYTHON3=y
<peterm6881> BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
<peterm6881> BR2_TARGET_UBOOT_SPL=y
<peterm6881> BR2_TARGET_UBOOT_SPL_NAME="u-boot-sunxi-with-spl.bin"
<peterm6881> BR2_TARGET_UBOOT_CUSTOM_DTS_PATH="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/suniv-f1c100s/devicetree/uboot/suniv-f1c100s.dtsi $(BR2_EXTERNAL_MANGOPI_PATH)/board/widora/mangopi/r3/devicetree/uboot/suniv-f1c100s-generic.dts"
<peterm6881> BR2_PACKAGE_HOST_DOSFSTOOLS=y
<peterm6881> BR2_PACKAGE_HOST_GENIMAGE=y
<peterm6881> BR2_PACKAGE_HOST_MTOOLS=y
<peterm6881> BR2_PACKAGE_HOST_PYTHON3=y
<peterm6881> BR2_PACKAGE_HOST_PYTHON3_SSL=y
<peterm6881> BR2_PACKAGE_HOST_UBOOT_TOOLS=y
<peterm6881> BR2_PACKAGE_HOST_UBOOT_TOOLS_FIT_SUPPORT=y
<peterm6881> BR2_PACKAGE_HOST_UBOOT_TOOLS_FIT_SIGNATURE_SUPPORT=y
<peterm6881> BR2_PACKAGE_HOST_UBOOT_TOOLS_ENVIMAGE=y
<peterm6881> BR2_PACKAGE_HOST_UBOOT_TOOLS_ENVIMAGE_SOURCE="$(BR2_EXTERNAL_MANGOPI_PATH)/board/allwinner/generic/uboot.env"
<peterm6881> BR2_PACKAGE_HOST_UBOOT_TOOLS_ENVIMAGE_SIZE="0x10000
<peterm6881> python3
<peterm6881> it doesnt look like theres any playback functionality at all
<peterm6881> -sh: alsa: not found
<peterm6881> meh, who needs audio
<peterm6881> where have i heard that before.....
<Xogium> well
<Xogium> its a minimal system
<Xogium> its up to the user to add whatever they want in there
<peterm6881> what was that command you said to show the os
<Xogium> check /etc/os-release
<peterm6881> sh: check: not found
<peterm6881> lol
<peterm6881> funny
<Xogium> I meant, check the content of that file
<Xogium> with cat or whatever
<peterm6881> NAME=Buildroot
<peterm6881> ID=buildroot
<peterm6881> VERSION=2021.11-1727-ga0fb3eed27
<peterm6881> VERSION_ID=2022.02-git
<peterm6881> PRETTY_NAME="Buildroot 2022.02-git"
<Xogium> isn't that a lot better ? Heh heh
<peterm6881> yes fantastic
<Xogium> 2022.02 should be released in a couple of days, and then we can go back to following lts
<peterm6881> thats a big step forward, and it all works
<Xogium> well… mostly
<peterm6881> thats the foundations laid
<Xogium> this manual boot stuff's annoying as hell
<peterm6881> umm.. yeah
<peterm6881> lol
<peterm6881> yeah but you documented that, I mean the repo does exactly what it says on the tin
<Xogium> true
<peterm6881> u should chill now :)
<Xogium> I hope to fix that because otherwise it won't be very atractive
<peterm6881> its quite an achievement
<Xogium> I don't get how they made an image that just works with the official mangopi
<Xogium> I'd bet on them having some local modification they forgot to push which makes it work for their generated image but not for anyone who build with the repo. That, or I forgot some part when grabbing the necessary stuff from the old buildroot crap, damned if I know what
<peterm6881> its a challenge
<peterm6881> maybe we can let them think about that, and focus on loading our stuff into the image
<peterm6881> are we sticking with the u-boot and kernel they used?
<Xogium> we don't have much of a choice
<peterm6881> i was afraid you'd say that lol
<Xogium> mainline is too young for us yet
<peterm6881> ok, understood
<peterm6881> i need to go shopping
<peterm6881> you've done really well
<Xogium> and given the 2819 lines patch applied on top of 2020.07 of u-boot… Yecch
<Xogium> plus that aod guy doesn't seem to be even slightly interested in mainlining the work to upstream kernel and u-boot
<Xogium> someone opened 2 issues about that on april 2021, and he did not bother replying
<Xogium> once again the effort of mainlining lichee nano, lichee pi zero and mangopi will be left to the community
<Xogium> because once again, the vendors don't care
<Xogium> they are willing enough if you use their own stuff, but I bet if we try and tell them our ultimate goal is to use mainline kernel and u-boot and forget all the vendor crap they will leave us on our own
<peterm6881> i dunno, hopefully we'll have a better idea of their logic soon
<Xogium> yeah…
<peterm6881> they seem willing enough to engage
<peterm6881> i think they're just in too big a hurry to fire something out there, then they move on to the next thing like butterflies.
<Xogium> yes because we plan on using their buildroot stuff and just convert into an external tree
<Xogium> but as soon as you mention mainline, they fall silent
<peterm6881> back
<peterm6881> why is that?
<Xogium> no idea, honestly
<peterm6881> by the way is there anything else you wanna do, while you're on a roll ;)
<Xogium> not sure, you got anything in mind ?
<peterm6881> where to start....
<peterm6881> enable audio and check the speaker?
<Xogium> hmm… how do you connect the speaker ?
<peterm6881> first of all, do you have a 4 or 8 Ohm speaker with dupont jumper wires?
<Xogium> hmm nop. I mean, I have the one from your speedsaver kit… I suppose I could unplug it
<peterm6881> thats not the one that fried is it?
<Xogium> no
<Xogium> the one that fried was the one you sent me in the official case and expantion attached
<peterm6881> i wouldnt dismantle it, if its potentially working, i can send you a speaker
<Xogium> like that one ?
<peterm6881> yeah i have umm... several :)
<Xogium> sound's not half bad with that speaker must say
<Xogium> sure then, that could work
<Xogium> I can even get myself some jumper wires hooked up to serve as an extension if they are too short
<peterm6881> I could put it in one of the early cases, so it will sound just as good. Although the amp on the R3 is only about 1.5 Watts I think
<Xogium> hmm would it fit in the case ?
<peterm6881> but im ready to go with a speaker, pretty much we just need alsa and alsa-utils
<peterm6881> yeah i should have some cases left that were designed for it, like yours was
<Xogium> m'kay let me enable alsa
<Xogium> yeah but I mean, the mangopi probably won't fit in that case
<peterm6881> ok ill test left and right
<peterm6881> see if they connected both channels correctly
<Xogium> you might need to toy with alsamixer and such though remember
<peterm6881> quite :)
<peterm6881> be interesting to see what options we get with the new card
<peterm6881> i see some new commits in the Buildroot git
<peterm6881> dont those guys ever sleep?
<Xogium> really ? Hmm
<peterm6881> sing objects: 100% (14/14), done.
<peterm6881> Unpacking objects: 100% (16/16), 110.76 KiB | 2.17 MiB/s, done.
<peterm6881> a0fb3eed27..7227d005d2 master -> origin/master
<peterm6881> remote: Total 16 (delta 2), reused 16 (delta 2), pack-reused 0
<peterm6881> Updating a0fb3eed27..7227d005d2
<peterm6881> Fast-forward
<peterm6881> DEVELOPERS | 1 +
<peterm6881> package/Config.in | 1 +
<peterm6881> ...-remove-Werror-and-Wfatal-errors-compiler-comma.patch | 37 +++++++++++++++++++
<peterm6881> package/libcamera-apps/Config.in | 29 +++++++++++++++
<peterm6881> package/libcamera-apps/libcamera-apps.hash | 3 ++
<peterm6881> package/libcamera-apps/libcamera-apps.mk | 48 +++++++++++++++++++++++++
<peterm6881> package/libcamera/libcamera.hash | 2 +-
<peterm6881> package/libcamera/libcamera.mk | 2 +-
<peterm6881> 8 files changed, 121 insertions(+), 2 deletions(-)
<peterm6881> create mode 100644 package/libcamera-apps/0001-cmake-remove-Werror-and-Wfatal-errors-compiler-comma.patch
<peterm6881> create mode 100644 package/libcamera-apps/Config.in
<peterm6881> create mode 100644 package/libcamera-apps/libcamera-apps.hash
<peterm6881> create mode 100644 package/libcamera-apps/libcamera-apps.mk
<peterm6881> meh, cut and paste fail
<Xogium> ok I enabled alsa here and pushed, but you will need to do the distclean and remake the defconfig and such, since that touched the defconfig
<peterm6881> PLEASE NOTE TO UPDATE THE KERNEL, or for any other speedsaver_defconfig changes, Xogium to update the defconfig, then git pull the Speedsaver repo, re-make the speedsaver_defconfig and run make distclean from buildroot-202x.xx.xx/output/speedsaver
<peterm6881> does this look correct
<Xogium> well the path is obviously wrong since its for speedaver
<peterm6881> oops yeah lol
<Xogium> but its basically the same idea
<peterm6881> ok wait
<peterm6881> do i nead to do a make clean && make at the end?
<peterm6881> or just make
<Xogium> make clean doesn't make sense since you wiped out all the directory
<Xogium> then just recreated it when you ran the defconfig one
<Xogium> so just that then make
<peterm6881> i wasnt sure what distclean actually does :)
<Xogium> make clean just removes stuff like the target dir, images, build, etc.
<Xogium> distclean is more violent, it removes even the .config generated when you ran make with the defconfig
<Xogium> you could do the very same stuff by hand if you removed the entire output directory
<peterm6881> peter@peter-powermatemlxxx:~/buildroot/output/widora-mangopi-r3$ make -j5
<peterm6881> Makefile:944: *** Please configure Buildroot first (e.g. "make menuconfig"). Stop.
<peterm6881> make: *** [Makefile:23: _all] Error 2
<peterm6881> GEN /home/peter/buildroot/output/widora-mangopi-r3/Makefile
<peterm6881> what did i do wrong..
<peterm6881> do i just need to run that, and not change anything?
<Xogium> did you forget to run the defconfig line ?
<peterm6881> i did, but maybe my guide is in the wrong order
<Xogium> didn't you note that for speedsaver ?
<Xogium> the idea is you run make distclean from toplevel buildroot, then you run the defconfig again, then you cd to the output directory you just recreated, then make
<peterm6881> its so rare i need to use distclean, I take it i need to make the defconfig AFTER i do make distclean
<Xogium> yes
<Xogium> obviously not before
<peterm6881> yeah my guide is arse about face
<peterm6881> let me fix that
<Xogium> that wouldn't make much sense otherwise, if you amtomize your config right after creating it
<peterm6881> yeah i think we had this conversation before :)
<peterm6881> hehe
<peterm6881> PLEASE NOTE TO UPDATE THE KERNEL, or for any other speedsaver_defconfig changes, Xogium to update the defconfig, then git pull the Speedsaver repo, run make distclean from buildroot-202x.xx.xx/output/speedsaver, then re-make the speedsaver_defconfig and follow all usual steps after
<peterm6881> does this look better? for speedsaver read mangopi blah blah
<peterm6881> by the way, i take it we have alsa-utils
<Xogium> well yes, I just said I enabled it :p
<peterm6881> you said you enabled alsa, just sayin
<peterm6881> its not built in
<Xogium> well actually alsa is already enabled… As its part of the kernel
<Xogium> we were simply lacking the userspace
<peterm6881> building now
<peterm6881> have you tried a build on arch?
<Xogium> I always build on arch
<peterm6881> no i mean did you build it at your end
<Xogium> oh nah I just enabled it for you
<Xogium> but it shoudln't blow up
<peterm6881> i sent you an audio clip
<peterm6881> perect
<peterm6881> perfect
<Xogium> good
<peterm6881> i only had to adjust the "headphone" slider off 0 and unmute it, thats all
<Xogium> neat
<peterm6881> do you think we should make that adjustment before you push it to the repo?
<Xogium> nah
<peterm6881> you monster :)
<Xogium> we'll do for speedsaver but for the baic build that would require makind an init script
<Xogium> basic
<peterm6881> ok no problem
<peterm6881> right, whats next :)
<Xogium> not much at this point
<peterm6881> yeah i think thats phenomenal progress, congratulations
<peterm6881> did you listen to the audio?
<Xogium> yep fancy
<peterm6881> hehe
<peterm6881> its great
<peterm6881> thats with no baffle box, just a speaker
<peterm6881> so the front is cancelling out the rear to a certain extent
<peterm6881> as they are in anti-phase
<peterm6881> so in a proper box it would be even better
<peterm6881> not massively loud but it will do.
<Xogium> niceness
<peterm6881> good work you
<peterm6881> ok so in answer to your question
<peterm6881> the longer continuous row of pins
<peterm6881> do you see how one end goes to the edge of the board, the other end stops short of the edge of the board
<Xogium> yeah
<peterm6881> ok the end that stops short, the final pin is a ground, but the NEXT 2 pins are your direct speaker out
<peterm6881> incidentally, the NEXT 2 pins after the speaker are Line In Left and Right
<peterm6881> not that we'll probably ever use them
<Xogium> oh nice
<peterm6881> next pin is adc, not sure what that is. Then TV out
<peterm6881> thats all the analogue pins
<peterm6881> ohh i think its digital audio
<peterm6881> One audio analog-to-digital(ADC) channel, yeah
<Xogium> fancy stuff
<peterm6881> ive prepared an abs-230-rc for you. ive cable tied the wires to one corner screw mounting hole, glued them and glued the 2 Dupont female plugs together
<peterm6881> thats your speaker, same as the one in the original speedsaver
<peterm6881> sleep well
<Xogium> woot, thanks
<Xogium> jumper wires are so much fun
<peterm6881> the 4 pins at the other end of that long bank of pins will be the i2c 2-wire connections for the oled
<Xogium> niceness
<peterm6881> the very end pin is 5V, then clock and data in that order
<peterm6881> 4th pin is ground
<peterm6881> they will have enabled that, because they're labelled scl and sda
<Xogium> sounds like i2c indeed
<peterm6881> serial might be a bit interesting, because we're into matrixed IO
<peterm6881> PA2 and PA3
<peterm6881> so, after the first 4 pins I just described, the 5th pin is 3.3V, the next 2 pins are PA3 and PA2 respectively
<peterm6881> wait, scrub that
<peterm6881> after the first 4 pins just described, next is a reset pin, then 3.3V, then PA3 then PA2
<peterm6881> PA3 and PA2 can be configured as UART1 TX and RX respectively, when Multiplexing Function 5 is selected
<peterm6881> can we tell which UART MangoPi are using for their Bridge? Can we assume its UART0?
<Xogium> its uart1
<peterm6881> yes it looks like the Bridge is connected to PE0 and PE1
<peterm6881> hmm....
<Xogium> remember uart0 did not talk
<peterm6881> according to the datasheet the bridge is physically connected to PE0 and PE1
<peterm6881> sorry i meant according to the schematic, the bridge is connected to PE0 and PE1, which according to the datasheet can only be UART0
<Xogium> hmm what about pin muxing ?
<peterm6881> for a UART connection, it can only be uart0
<Xogium> I'm even more confused then because if its uart0 then at the very least u-boot from unframework should have talked… plus uart0 would be enabled in the device tree, which it isn't. Only uart1 seems to be
<peterm6881> it can be other stuff, for example TWI2
<peterm6881> but for UART, its only UART0, thats also Multiplexing Function 5
<peterm6881> which must be what they have selected
<peterm6881> i agree, theres definitely some mix up or confusion about the LicheePi Nano stuff
<Xogium> well I clearly see them enabling uart1
<peterm6881> who?
<peterm6881> I would expect them to enable 2 of the 3 UARTs, since they reserve one for their debugging Bridge
<peterm6881> surely you would expect them to make a UART available
<Xogium> uart1 is the only one enabled
<peterm6881> since they definitely exposed a Two Wire interface already
<Xogium> yeah but that's concidental they expose it because they assume you have a camera or a lcd panel connected there
<peterm6881> maybe uart0 is always enabled
<Xogium> I doubt that, in the dtsi it is disabled
<peterm6881> i wish this wasnt so complicated
<peterm6881> yeah we're gonna have LOTS of fun getting the serial gps to work, since we cant even agree whats connected
<Xogium> what if its the schematic that is wrong ?
<peterm6881> its possible. The schematic shows a CP2104, which we know was changed in the r3c
<Xogium> indeed
<Xogium> let me check in realtime
<Xogium> woah I just uh noticed u-boot has tab completion
<peterm6881> what does that mean lol
<Xogium> I went like bootm ${ker then tab and it completed to kernel_addr_r and even added }
<peterm6881> oh wow thats convenient right?
<Xogium> definitely
<peterm6881> nice
<peterm6881> so what are you able to check?
<Xogium> ok so I confirm
<Xogium> serial@1c25400 which is uart1, is the only uart port that is enabled
<peterm6881> uart1
<peterm6881> yeah i just realised something
<peterm6881> the pins on the other side of the board are PE0 to PE11
<Xogium> #
<Xogium> okay#
<Xogium> woops
<Xogium> # cat /sys/firmware/devicetree/base/soc/serial@1c25400/status
<Xogium> okay#
<peterm6881> they wouldnt have exposed PE0 and PE1 as pins if they were already using them for the Bridge
<Xogium> # cat /sys/firmware/devicetree/base/soc/serial@1c25000/status
<Xogium> disabled#
<peterm6881> they not only changed the chip, they must have rewired it
<Xogium> aye, and they did not upload a new schematic for r3c either
<peterm6881> so yeah looks like you're right, the schema is wrong
<Xogium> so we can use either uart0 or uart2
<peterm6881> this makes no sense
<Xogium> and on that note, I'll get some shut eye
<Xogium> what doesn't ?
<peterm6881> no its ok, its me. Well we cant use PA3 and PA2 on the same side as the speaker and oled
<peterm6881> because they can only be configured as UART1
<Xogium> ah shit
<peterm6881> let me check this table, hang on
<Xogium> will read tomorrow when I wake up
<Xogium> :)
<peterm6881> pleasant dreams Xogium
<peterm6881> and thanks again
peterm6881 has quit [Quit: Leaving]
peterm6881 has joined #Speedsaver