Werner 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 | Type 'help' for help | Logs: -> irc.armbian.com
chewitt has quit [Quit: Zzz..]
archetech has quit [Quit: Leaving]
archetech has joined #armbian
hyphop1 has joined #armbian
hyphop1 has quit [Ping timeout: 240 seconds]
hyphop1 has joined #armbian
hyphop1 has quit [Ping timeout: 245 seconds]
hyphop1 has joined #armbian
hipboi has joined #armbian
archetech has quit [Quit: Konversation terminated!]
hipboi_ has quit [Ping timeout: 245 seconds]
hyphop1 has quit [Ping timeout: 250 seconds]
hyphop1 has joined #armbian
hyphop1 has quit [*.net *.split]
qqqhhh has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
p0g0__ has quit [*.net *.split]
hyphop1 has joined #armbian
qqqhhh has joined #armbian
mcfrdy has joined #armbian
p0g0__ has joined #armbian
phipli has joined #armbian
plntyk has joined #armbian
ced117_ has joined #armbian
HerculeP has joined #armbian
Flecks has joined #armbian
HerculeP has quit [Changing host]
HerculeP has joined #armbian
phenom has joined #armbian
silver_hook has joined #armbian
iwamatsu` has joined #armbian
BluesBoy has joined #armbian
MrFixIt has joined #armbian
Unit193 has joined #armbian
s1b1 has joined #armbian
zentra[m] has joined #armbian
nekomancer[m] has joined #armbian
kprasadvnsi[m] has joined #armbian
solderfumes has joined #armbian
Michi[m] has joined #armbian
archetech has joined #armbian
archetyp has joined #armbian
chewitt has joined #armbian
Dagger has joined #armbian
hyphop1 has quit [Ping timeout: 272 seconds]
<chewitt>
IgorPec: ping!
psydroid has joined #armbian
<chewitt>
I'm sure I've seen mention of Radxa Zero and Armbian somewhere, do you have one?
<Armbian-Discord>
<IgorPec> pong
<Armbian-Discord>
<IgorPec> nope. i don't have it yet.
<Armbian-Discord>
<IgorPec> but there are people that have it and there is some merge request open on the topic
<chewitt>
ahh, I'm trying to get confirmation of which WiFi module is in the lower spec board
<Armbian-Discord>
<IgorPec> @hipboi might provide that info?
<Armbian-Discord>
<IgorPec> yes, that's it, but i am personally not involved much. was on vacations since a week ago
<chewitt>
I'm still on vacation .. doing some tinkering while the jetlag has me awake at funny hours :)
<Armbian-Discord>
<IgorPec> oh, nice. I was also productive on vacations but mainly on non-hw related things.
<hipboi>
@chewitt AP6256 for 2GB and 4GB model, AP6212 for 512MB/1GB model
<hipboi>
for the early engineering samples, AP6236 are used for 512MB/1GB model
<hipboi>
so probably we need to support 3 wifi modules
<chewitt>
@hipboi thanks, do you know what broadcom chip is in AP6236?
<chewitt>
for device-tree things are simple as long as they are all broadcom; they share the same 'compatible' and the driver selects the right firmware to load
<chewitt>
the moment you swap the broadcom chip for e.g. some cheap realtek part, everyone maintaining a distro hates you for making their life complicated :)
<hipboi>
@chewitt AP6236 is bcm43436b0
<hipboi>
we don't like realtek wifi too
<chewitt>
the other part on the schematic options list was QCA9337
<chewitt>
it's not a bad chip, but, I'm the person who upstreamed support for it
<chewitt>
that should scare you out of using it :)
<hipboi>
@chewitt hat off
<hipboi>
how about QCA9880/9882
<hipboi>
we are planning to use this for the upcoming 2.5G router
<chewitt>
no opinion on it from a hardware/capabilities perspective
<chewitt>
from the software support side, the beauty of broadcom chips is, the current device-tree compatible acts as a catch-all for 99% of their chips
<chewitt>
this means I get to ship a single distro image with a bundle of firmware/nvram settings and it all "just works"
<hipboi>
yeah, that's really good
<chewitt>
the moment you dabble with chips that need different compatibles; you have multiple device-trees to ship
hyphop1 has joined #armbian
<chewitt>
if there is anything in the board that allows u-boot to detect version and load the correct dts magically.. it's sustainable
<chewitt>
(see what HK does with C4/HC4/N2/N2+)
<hipboi>
hardware ID, we will use it for all new boards
<chewitt>
if not, users have to guess correctly and/or perhaps load the right u-boot overlay .. which adds to configuration
<chewitt>
not a massive challenge, but requires more experience than "write to sd card and boot"
<Armbian-Discord>
<Tonymac32> Yeah, the Tinker Board has some hardware ID built in, so does the 2. I thought it was a nice touch.
<Armbian-Discord>
<Tonymac32> Chewitt as long as the U-boot shenanigans don't require another U-boot source different from mainline, all is well. We have per-board patch directories for U-boot, so support for most things can be handled safely that way as long as it's based on mainline
<chewitt>
I have it booting mainline 2021.07 without issues
<chewitt>
two patches; one for dts and one for board config
<chewitt>
the other comment for usability would be .. don't preload the emmc with something, let users decide which distro/image to run
<chewitt>
this makes it trivial to write something to an SD card and boot
<chewitt>
provide images that make it simple to transfer the image to emmc from there, or via Amlogic burning tools etc.
<hipboi>
we should avoid the amlogic burning tools
<chewitt>
pre-installing (typically Android) makes it complicated for average users to exorcise vendor code to run their distro choice
<hipboi>
writing emmc boot0/1, troublesome for users
<hipboi>
android should only install to eMMC user partitions, user can easily to wipe it
<chewitt>
it took me a while to remember how to remove the write protection to overwrite the default image
<hipboi>
emmc boot0/1 is not easily accessible from linux
<hipboi>
maybe we should add this to our documents
<chewitt>
but you need to have booted from SD card first, else you're trying to erase the same device you're booted from
<chewitt>
I wasn't able to boot from USB (due to no USB-C adaptor) so had to get booted from SD card
<chewitt>
I was assuming the button on the board would work like shorting the emmc pins .. but I wasn't able to get an SD card to boot that way
<hipboi>
the button is not short eMMC
<hipboi>
is usb boot
<hipboi>
check the s905y2 datasheet
<chewitt>
but I was able to get to the u-boot console, then
<chewitt>
fatload mmc 0 1020000 s905_autoscript
<chewitt>
autoscr 1020000
<hipboi>
usbboot always has the highest priority
<chewitt>
on most Amlogic hardware it checks emmc first, then usb or sd (not sure which) so shorting pins disables emmc and it will find an SD card
<hipboi>
really?
<chewitt>
it's the ugly-but-works method needed when users burn the wrong ROM they found on freaktab to their tvbox device
<chewitt>
then you can experiment with sd cards loaded with different u-boot versions until you find something with the right ram spec to boot the box (acs.bin)
<chewitt>
it missed the cut-off for 5.15, so 5.16 will be first upstream kernel .. assuming patches are accepted
<archetech>
this thing in production yet and available ?
<archetech>
not is US yet
stipa_ has joined #armbian
stipa has quit [Ping timeout: 252 seconds]
stipa_ is now known as stipa
<Armbian-Discord>
<Tonymac32> Chewitt I just haven't had time to boot the one I have, there were some things needed cleaned up for the upcoming release first.
<Armbian-Discord>
<Tonymac32> I know the board will boot from mainline U-boot no problem, I was just referring to the PR in the system that is pulling new sources. I hesitate to approve those because of the absolute mess that happened in our Rockchip boards because of all the fragmented u-boots/ATF/blobs/etc.