rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
sunshavi has joined #linux-sunxi
<libv> a lot of it is explaining their .fex settings and even some .dts info
minicom has quit [Quit: Ping timeout (120 seconds)]
minicom has joined #linux-sunxi
AneoX has joined #linux-sunxi
gediz0x539 has quit [Quit: Leaving]
<libv> then some ref board schematics which definitely will help .dts conversions
tl_lim has quit [Ping timeout: 250 seconds]
<megi> yeah schematics are useful, I thought you were talking about PCB routing level detail
<sunshavi> megi: i am plannig apply this patch on top of archlinux 5.5-rc1 https://megous.com/dl/tmp/0001-drm-sun4i-Mark-one-of-the-UI-planes-as-a-cursor-one.patch. would that be okay
<megi> you'll probably need the other one too
<sunshavi> which one?
<megi> the one that fixes plane setup commit
<megi> these are the latest version of those two patches
<sunshavi> megi: then i am going to apply both of them
<megi> what do you mean by archlinux 5.5-rc1, btw?
<sunshavi> kernel 5.5-rc1 with the patches apply by archlinux
<megi> just something personal or for some kernel that will be distributed with arch linux arm?
popolon has quit [Quit: WeeChat 2.6]
<sunshavi> no. archlinux has the equivalent to dpkg-source for compiling pkgs. so I just download the source code for that kernel with all the patches on top of it I am going to apply both of your patches
<megi> ok, I understand
dev1990_ has joined #linux-sunxi
dev1990 has quit [Ping timeout: 265 seconds]
tlwoerner has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
lurchi__ has quit [Ping timeout: 268 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 246 seconds]
ChriChri_ is now known as ChriChri
Mangy_Dog has quit [Ping timeout: 240 seconds]
dev1990_ has quit [Remote host closed the connection]
dev1990_ has joined #linux-sunxi
tl_lim has joined #linux-sunxi
megi has quit [Ping timeout: 268 seconds]
cnxsoft has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
aloo_shu has quit [Ping timeout: 246 seconds]
lurchi_ is now known as lurchi__
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
tl_lim has quit [Ping timeout: 250 seconds]
tl_lim has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 265 seconds]
tl_lim has quit [Ping timeout: 245 seconds]
tl_lim has joined #linux-sunxi
TheSeven has quit [Ping timeout: 250 seconds]
[7] has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lykt has quit [Quit: leaving]
lurchi__ has quit [Ping timeout: 265 seconds]
lykt has joined #linux-sunxi
tl_lim has quit [Ping timeout: 250 seconds]
lkcl has quit [Ping timeout: 240 seconds]
tl_lim has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-sunxi
lkcl has joined #linux-sunxi
JohnDoe3 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 250 seconds]
tl_lim has quit [Read error: Connection reset by peer]
\\Mr_C\\ has joined #linux-sunxi
florian has joined #linux-sunxi
RichardG867 has quit [Ping timeout: 250 seconds]
dddddd has quit [Remote host closed the connection]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
suprothunderbolt has quit [Ping timeout: 265 seconds]
\\Mr_C\\ has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
AneoX has quit [Ping timeout: 250 seconds]
AneoX has joined #linux-sunxi
reinforce has joined #linux-sunxi
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
gaston1980 has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 276 seconds]
warpme_ has joined #linux-sunxi
megi has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
suprothunderbolt has joined #linux-sunxi
gediz0x539 has left #linux-sunxi [#linux-sunxi]
gediz0x539 has joined #linux-sunxi
Putti has joined #linux-sunxi
Putti has quit [Changing host]
Putti has joined #linux-sunxi
gediz0x539 has quit [Remote host closed the connection]
gediz0x539 has joined #linux-sunxi
aloo_shu has joined #linux-sunxi
gediz539 has joined #linux-sunxi
gediz0x539 has quit [Remote host closed the connection]
gediz539 is now known as gediz0x539
gediz0x539 has quit [Quit: Leaving]
gediz0x539 has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
RichardG867 has joined #linux-sunxi
<warpme_> guys: quick Q regarding u-boot: I have multiple H6 baords and I'm using sunxi-custodians u-boot. is there way to configure u-boot build to produce single u-boot bin for multiple h6 boards?
dddddd has joined #linux-sunxi
gediz0x539 has quit [Quit: Leaving]
ldevulder__ has joined #linux-sunxi
AneoX has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 252 seconds]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
reinforce has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
<smaeul> warpme_: generally no. you can share u-boot proper across boards if you don't use any of the legacy pinctrl options (or if they work on all boards)
<smaeul> that either involves setting CONFIG_OF_LIST, to add multiple DTBs to the same image, or concatenating the various DTBs to u-boot-nodtb.bin
<smaeul> but which DTB to use, and therefore which board the image works on, is determined by (and hardcoded in) the SPL image
<smaeul> if there is some hardware feature you can use to distinguish the boards, you can modify SPL to choose the machine name at runtime
<smaeul> if this is for your personal boards, you can use the serial number from the SID; otherwise you can look for something like a GPIO that is pulled differently between boards
<smaeul> so if you want a single SD card with U-Boot on it to boot on multiple boards, that's ^^ how you need to modify SPL
<mru> or an i2c eeprom for maximum flexibility
<smaeul> the "ideal" way is to install U-Boot on SPI flash, and not on the SD card. then the SD card can work in any board
tllim has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
popolon has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
_whitelogger has joined #linux-sunxi
lurchi_ is now known as lurchi__
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 250 seconds]
megi has quit [Ping timeout: 268 seconds]
JohnDoe3 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
lurchi__ is now known as lurchi_
The_Loko has joined #linux-sunxi
megi has joined #linux-sunxi
ez has joined #linux-sunxi
ez has quit [Client Quit]
ezdiy has joined #linux-sunxi
<ezdiy> could someone run `locate Draco_H3_SDK_20150601_lichee.zip` please for me if you played with h3 in the past?
<ezdiy> (or even better, sdk for b288 or at least its fex, though google comes up utterly empty for that)
sunshavi has quit [Remote host closed the connection]
Putti has quit [Ping timeout: 240 seconds]
sunshavi has joined #linux-sunxi
<sunshavi> megi: https://termbin.com/ik4y
<sunshavi>
<megi> nice :)
florian has quit [Ping timeout: 276 seconds]
<sunshavi> 20h compiling on device itself
<megi> ezdiy: you can extract fex file from a running device
<ezdiy> oh?
<megi> yup, check out sunxi-tools
<ezdiy> megi: if you mean parsing egon headers, thats an issue
<ezdiy> nobody has reversed the new format, ditto for sunxi-package
<ezdiy> i can more or less get dtb, buts probably it
<megi> I don't know how it's done, but I've extracted fex file several times using sunxi-tools
<megi> from a running kernel
<ezdiy> ah, interesting
<megi> if we're talking about the old 3.4 bsp kernel, that is
<ezdiy> megi: yea, ultimately those need to be passed over to kernel by uboot
<ezdiy> nah, this is 4.5
<ezdiy> err, no, 3.10.65+
reinforce has quit [Quit: Leaving.]
<megi> bsp kernel?
<ezdiy> no idea what that is. im proud of this one, a perfectly good gpl violation
<ezdiy> such a shame to touch it in places
<megi> it may still work, if 3.10 still uses fex
<ezdiy> ye i'll look at what the tools are poking
<ezdiy> $ ./bin2fex < secript
<ezdiy> E: fexc-bin: Malformed data: too many sections (8388608).
<ezdiy> welp, doesnt look too good
<ezdiy> megi: is there a know-good script somewhere, just to know what to look for in memory dumps?
<ezdiy> nah, its just dumping random part of memory, its different every reboot