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*
asdf28 has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
<matthewcroughan> jernej: have you got a link to the patches in question?
jstein has joined #linux-sunxi
jstein has quit [Client Quit]
sunshavi has quit [Ping timeout: 272 seconds]
Mangy_Dog has quit [Ping timeout: 240 seconds]
sconcours has quit [Ping timeout: 272 seconds]
apritzel has quit [Ping timeout: 272 seconds]
sunilmohan has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
sunilmohan has joined #linux-sunxi
sunshavi has joined #linux-sunxi
victhor has quit [Ping timeout: 258 seconds]
macc24 has joined #linux-sunxi
jelly has quit [Ping timeout: 260 seconds]
macc24 has quit [Ping timeout: 272 seconds]
jelly-home has joined #linux-sunxi
chewitt has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
macc24 has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri_ is now known as ChriChri
_whitelogger has joined #linux-sunxi
alexxy has quit [Ping timeout: 240 seconds]
alexxy has joined #linux-sunxi
<tuxd3v> I am on OrangePi one Plus( H6 )
<tuxd3v> I just compiled a new uboot, and I get in the end of the compilation process( uboot_v2021.01 ) the following:
<tuxd3v> this is normal?
<tuxd3v> or should I go back to v2020.10?
<smaeul> tuxd3v: yes, this is normal. Like the message says, the SCP firmware (crust) is optional. you won't lose any functionality by upgrading. you can add additional functionality (i.e. suspend) by adding the firmware
<smaeul> and if configured appropriately, the ability to power on the board with an IR remote
<tuxd3v> :)
<tuxd3v> its a interesting project :)
<tuxd3v> I am seing the project page now :)
<tuxd3v> but a new toolchain is required to compile it
<smaeul> I didn't decide what CPU Allwinner put in there :)
lurchi_ has joined #linux-sunxi
<tuxd3v> true
<tuxd3v> :)
lurchi__ has quit [Ping timeout: 264 seconds]
<tuxd3v> the default baudrate is still 115200 to see uboot starting up?
apritzel has joined #linux-sunxi
<smaeul> tuxd3v: yes
<tuxd3v> many thanks :)
Asara has quit [Ping timeout: 264 seconds]
apritzel has quit [Ping timeout: 240 seconds]
Asara has joined #linux-sunxi
pgreco has quit [Ping timeout: 246 seconds]
reinforce has joined #linux-sunxi
hlauer has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
<tuxd3v> jernej, I added the patch 2-4, for haven't applyed the 6-9 above..
<tuxd3v> I am booting 5.10.13, and I get this error:
pgreco has joined #linux-sunxi
macc24 has quit [Ping timeout: 258 seconds]
reinforce has quit [Remote host closed the connection]
macc24 has joined #linux-sunxi
<montjoie> tuxd3v: on which bboard ?
<tuxd3v> on orange pi one plus
<montjoie> I launched a build to test
<tuxd3v> I only added the patchs 2-4
<montjoie> ah i believed it was vanilla stable
<tuxd3v> dwmac-sun8i changed a bit :)
<tuxd3v> tomorrow I will try his series 6-9 first, and then apply his 2-4
<tuxd3v> to check if I get ethernet :)
cmeerw has joined #linux-sunxi
<tuxd3v> I also have a patch to shutdown the ethernet on reboot
<Werner> cd
reinforce has joined #linux-sunxi
verz_broke has joined #linux-sunxi
verz_broke has quit [Quit: ZNC - http://znc.in]
kverz_broke has joined #linux-sunxi
cmeerw has quit [Ping timeout: 264 seconds]
asdf28 has joined #linux-sunxi
ldevulder_ is now known as ldevulder
ganbold has quit [Ping timeout: 272 seconds]
ldevulder has quit [Ping timeout: 246 seconds]
ldevulder has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #linux-sunxi
ldevulder_ is now known as ldevulder
matthias_bgg has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #linux-sunxi
jelly-home is now known as jelly
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
apritzel has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
\\Mr_C\\ has joined #linux-sunxi
wens has quit [Ping timeout: 256 seconds]
wens has joined #linux-sunxi
prefixCactus_ has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
prefixCactus_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
prefixCactus has joined #linux-sunxi
prefixCactus has left #linux-sunxi [#linux-sunxi]
prefixCactus has joined #linux-sunxi
kverz_broke is now known as kveremitz
prefixCactus is now known as prefixCactus
prefixCactus is now known as prefixcactus
<prefixcactus> Hi! I'm trying to get a Forlinx FETA40i devboard up and running with something other than the stock firmware. I have dmesg output via uart (or rather full RS232) and a shell via adb.
<prefixcactus> The alternative images provided by the manufacturer seem to be in some kind of proprietary format and the docs say they have to be flashed via what seems to be a likewise proprietary and windows-only tool (PhoenixCard/PhoenixSuit).
<prefixcactus> I'm trying to get something (anything else really) to boot via FEL right now to verify that I can in fact upload stuff to the board.
<prefixcactus> Do you suggest I go through all the steps with configuring a new board and compiling specific firmware, or just flash a precompiled firmware for a different board using the same SoC (e.g. bananapi)?
<mru> same soc isn't necessarily enough for it to work
<mru> at the very least, ram has to be compatible
<mru> and probably pmic
<mru> helps a lot if console is on the same pins
<mru> why don't you get a friendlier board anyway?
<prefixcactus> It isn't on the same pins as dmesg right now, if that's what you're talking about, but I suppose it depends on what's compiled into the specific image, right?
<mru> huh?
<mru> the kernel boot messages go to the console
<mru> it's the definition
<mru> the console=ttyS0,115200 or whatever on the kernel command line
<prefixcactus> well, there's no console on UART0 in the stock image for whatever reason
<mru> if the boards don't use the same uart muxed on the same pins, you won't see any output
<prefixcactus> Do you mean the same uarts can be on different pins depending on the config?
<mru> yes
<prefixcactus> OK, that might be a problem
<mru> most functions can be on any of several different pins
<prefixcactus> ok, looks like I'll have to config/compile first.
<mru> now many allwinner systems follow the reference designs fairly closely
<prefixcactus> Shall I create a page for the board now, or later?
<mru> so they do end up using mostly the same settings
<mru> a page?
<prefixcactus> er, the new device howto on the wiki says to create a wiki page for the device before doing anything to the hardware
<mru> why should you have to do that?
<mru> if you get it working, documenting the specifics is nice as a courtesy to others, of course
<mru> but I certainly wouldn't _start_ there
<mru> do you have schematics for the board?
<prefixcactus> As a matter of fact, I do
<mru> that's a start
<mru> which soc is it?
<prefixcactus> (as well as all the other documentation, which mostly doesn't help anyways)
<prefixcactus> The soc is A40i
<mru> compare the critical bits to some other board with the same soc
<mru> or just try and see
chewitt has quit [Quit: Adios!]
<prefixcactus> try what?
<mru> booting something
<mru> can it boot from sd card?
<prefixcactus> That I did, and it doesn't work
<prefixcactus> It's supposed to boot from sd, but I can't get it to.
<mru> not even official builds?
<prefixcactus> well, the problem with the official builds is that they're in a format I can neither recognize nor burn to the sd
<prefixcactus> (simply dd'ing them to it doesn't work)
<mru> that's annoying
<prefixcactus> the official docs say I have to use the "PhoenixCard" tool
<prefixcactus> which is proprietary and windows-only as far as I can tell
<mru> probably a waste of time messing with that
<mru> but if you have the schematics, it should be possible to make it run
<prefixcactus> so, since it has a convenient switch to get it into FEL mode, I think my best shot is to use that route
<prefixcactus> or burn something else onto the SD and try to boot that
<mru> is this what you've got? http://www.forlinx.net/product/58.html
<prefixcactus> Yeah, that's the one. But it's plugged into a larger dev board
<mru> the one pictured further down on that page?
<mru> hmm, the "hardware manual" link is dead
<mru> not a good sign
<mru> how did you end up with this board anyway?
<mru> why not use something a bit friendlier?
warpme_ has joined #linux-sunxi
<prefixcactus> er, it's at my workplace and we're planning to use the SOM in one of our projects
<mru> oh dear
<mru> too late to make a better plan?
<prefixcactus> Something friendlier would certainly be lovely, buuut
<prefixcactus> probably too late, yeah
<prefixcactus> re: the docs, I've got a dropbox with all of them
rzerres has quit [Read error: Connection reset by peer]
<prefixcactus> the stock images are there as well
<prefixcactus> and the tooling, and everything else
<mru> I don't see a schematic for the SOM
<prefixcactus> hm, looks like you're right
victhor has joined #linux-sunxi
<prefixcactus> I might be able to request it via Forlinx's official support channels though, if it really is necessary
rzerres has joined #linux-sunxi
<prefixcactus> It also looks like most if not all of the SOC's pins have been routed to the four sockets anyway
<mru> the docs you have are enough to tell how the peripherals are connected
<mru> but you need to know the RAM configuration
<prefixcactus> Can I pull it out of the official sources somehow?
<mru> somehow, probably
<mru> what ram chips does it have?
<mru> hmm, are there ram chips on the back of the board?
<mru> because that's a 2 Gb chip so two of them as pictured is only 512 MB
<mru> and they say the board has 1 GB (or 2 GB)
<prefixcactus> yep, two more of them on the underside
<prefixcactus> I've got the 1GB version
<mru> seems to have the same pmic as the bananapi m2 (axp221s)
<mru> I think it might be worth trying to load at least u-boot for the bananapi m2 and see what happens
<prefixcactus> okay
<mru> the basic ram parameters seem to be the same
<mru> they probably both copied the reference design
<mru> you'll be using a different carrier board eventually, right?
<prefixcactus> yep
<mru> fyi, the wifi chip on that carrier is EOL
macc24 has quit [Ping timeout: 256 seconds]
<prefixcactus> yes, and the ethernet PHY is 100M
<mru> sometimes that's enough
<prefixcactus> We're mostly going to use a GSM modem with it anyway
macc24 has joined #linux-sunxi
<mru> my advice: unless space constrained, include an ethernet interface regardless
<prefixcactus> Advice taken
<mru> development is much easier with a good connection
<mru> for production you can simply skip mounting those parts
<prefixcactus> Does it matter whether I use the m2 berry defconfig or the m2 ultra one?
<mru> the berry is probably just the ultra with bits removed
<mru> I'd try with the berry first
<mru> less risk of something conflicting
ganbold has joined #linux-sunxi
<prefixcactus> well, I compiled it and wrote to SD, but it loads the allwinner uboot from emmc anyway.
matthias_bgg has quit [Ping timeout: 240 seconds]
<prefixcactus> I noticed the dd commands in the wiki include "seek=8"
<prefixcactus> What should be in the first 8K?
<mru> doesn't matter
<mru> usually there will be a partition table there
<prefixcactus> I suppose that means I have to enter FEL differently
<prefixcactus> trying to boot over FEL produces "usb_bulk_send() ERROR -7: Operation timed out"
<mru> I've never bothered fighting with FEL
<mru> (which incidentally is swedish for error)
Mangy_Dog has joined #linux-sunxi
<prefixcactus> I've entered the allwinner-uboot console however
matthias_bgg has joined #linux-sunxi
<mru> is that on the emmc?
<prefixcactus> I think so
<mru> which mmc interface goes where on this board?
kaspter has quit [Ping timeout: 240 seconds]
<prefixcactus> #2 is emmc, and I think 0 is microsd
kaspter has joined #linux-sunxi
<mru> what does u-boot output when starting up?
<prefixcactus> U-Boot 2014.07 (Jan 19 2020 - 05:27:12) Allwinner Technology
<prefixcactus> uboot commit : ffae925c54abddcfc8f616c65bb6eb8a3076b947
<mru> can you put all of it in a pastebin?
<prefixcactus> sure, gimme a sec
<mru> ok, that's apparently on mmc2
<mru> so mmc1 should be the removable card
<mru> normally the rom tries mmc1 first, then mmc2
<prefixcactus> except the docs state that the removable card is mmc0
<prefixcactus> (and the full-size sd slot is mmc3)
<mru> probably just confusion over whether to number from 0 or 1
<prefixcactus> maybe, maybe not. the hardware manual does list four mmc buses numbered 0 through 3
<prefixcactus> (page 11)
<prefixcactus> anyway, the question is what can I do with it
<prefixcactus> mmcinfo prints the following:
<prefixcactus> no mmc device at slot 0
<prefixcactus> [mmc]: MMC Device 0 not found
<mru> try "mmc dev 2"
victhor has quit [Ping timeout: 246 seconds]
<prefixcactus> mmc dev 2 yields "mmc2(part 0) is current device". all other mmc devices are not found
<prefixcactus> and it is indeed the emmc
lucascastro has joined #linux-sunxi
<mru> good
<prefixcactus> Why is the microsd not detected, though?
<mru> oh, you have a uSD card inserted?
<prefixcactus> yes
<mru> strange
<mru> this is where I'd send that board to the recyclers and try a different one
<prefixcactus> okay, a flash of genius hit me and I tried inserting the same card into the fullsize sd slot, and looks like it's booted from it. At least it says "U-Boot SPL 2020.10 (Feb 04 2021 - 14:44:33 +0300)"
<mru> oh, that's promising
<mru> does the full u-boot also load?
<prefixcactus> It also says "DRAM: 0 MiB" and "### ERROR ### Please RESET the board ###" though, so I guess I'll have to reconfigure it
<mru> oh
<mru> so the ram config is bad
<prefixcactus> looks like it
<karlp> mru: the wifi chip you said is EOL, it's just an RTL8723BU from the part numbers, it's just been replaced by the DU, which is equivalent right?
<karlp> (I'm actually planning on using them for something...)
<karlp> (and have some ..BU modules on the way for prelininary testing)
<mru> RTL8723BU is EOL, replaced by RTL8723DU
<mru> which is similar but not quite compatible
<mru> which is good because it actually works
eduardas has joined #linux-sunxi
<mru> the -BU is hopeless
<karlp> in which ways?
<karlp> I mean, it's not xr819 hopeless right?
<mru> no, not that bad
<mru> the wifi part mostly works
<karlp> it's allowed to be mediocre wifi, I onl yneed it for basic hotspot config.
<mru> we never could get bluetooth to behave
<karlp> very much want to use BT though..
<karlp> ahh.
<karlp> problems :)
<karlp> is DU better enough?
<mru> seems so
<karlp> that's what I'd expect to use finally anyway, just have BU modules coming for early tests as I found them first
<karlp> I can asume that the DU will let me do "anything" as it's all just hcd right?
<mru> both are supposed to work with the normal btusb driver
<mru> the -bu just doesn't want to talk to other devices very much
<karlp> well, fun times ahead then for me I guess :)
<karlp> Ive got very little BT experience, and we're planning some trickiness.
<karlp> the 8723xu was appealing s it's usb only, instead of needing a uart for bt as well as usb, or as well as sdio
<mru> huh, there's no uart on the bu or du
<karlp> exactly, that's what I like about it
<mru> oh, that's what you meant by x
<mru> we're using fn-link modules, btw
<karlp> know any other easily available usb only wifi+bt parts?
<mru> I don't know of any wifi/bt that doesn't totally suck
<karlp> have you tried the mt7668u or rtl882[12] from fnlink? (the faster ones)
<karlp> I don't need the extra wifi speed, but curious in general
<karlp> are you suing thiese ones? http://www.fn-link.com/product/14.html
<mru> yes, that's what we'll be using from now on
<mru> it's physically a drop-in replacement for the old one
<mru> F23BUUM13
<mru> I have a test board with fn-link 6221E-UUC (RTL8821CU) as well
<mru> and a 6222D-UUB
<mru> also an rtl88xx iirc
fl_0 has quit [Quit: STRG + Q]
<karlp> https://www.aliexpress.com/item/32843823199.html is what I got for eval, but it's a little different pacakge.
<karlp> 8821 is the 1x1 AC wifi right?
<karlp> and 8822 is 2x2 or something
<mru> possibly
pcactus has joined #linux-sunxi
<pcactus> mru: so... where do I go next in order to make u-boot compatible with my memory setup?
<mru> you were using the bananapi m2 config, right?
<prefixcactus> yes, the berry one
<mru> try the other one, just in case
<prefixcactus> is there something I should set in menuconfig, btw?
<mru> if there's a defconfig for the board, just use that as is
<prefixcactus> nope, same thing
ganbold_ has joined #linux-sunxi
<mru> which configs did you build?
<mru> bananapi_m2_berry_defconfig?
<prefixcactus> yes. And Bananapi_M2_Ultra_defconfig
<mru> CONFIG_DRAM_CLK=576 is the only ram related entry there
<libv> prefixcactus: it also makes sense to create a wiki page for this device, following the new device howto, so that you can document your progress
<libv> and that others can add to it as well
<prefixcactus> I've asked about whether I should do that now earlier :)
<mru> doing that won't help you get it working
ganbold has quit [Ping timeout: 276 seconds]
<mru> it's just a distraction
<libv> mru: really?
<mru> yes, really
<libv> ok
<mru> writing a fucking wiki page won't make the device boot
<libv> mru: so how did you get into sunxi stuff then?
<mru> not by reading the wiki for sure
<libv> mru: did you pull it all out of thin air?
<libv> i wonder why we keep it up there then
<mru> maybe it's useful to some people
<libv> mru: not for allknowing you?
<libv> mru: so explain how you got your device(s) to work then
<libv> magic?
<mru> reading documentation and adapting existing configs
<libv> which documentation would that be?
<mru> datasheets, schematics, etc
<libv> oh, and those datasheets and schematics were always available everywhere then
<mru> the schematics generally come from the manufacturer directly
<libv> really?
<mru> really
<libv> what a nice world you live in
<libv> you must've come very very late to this party.
<mru> maybe we choose to only do business with somewhat sane companies
<libv> such as...
<mru> ones that supply schematics
<mru> and yes, I'm "late"
<mru> we wouldn't have even considered allwinner a few years ago
<libv> and how did we get to this place?
<libv> magic again?
<libv> allknowing individuals?
<mru> LET ME LICK YOUR BOOTS AND KISS YOUR ARSE, OH GLORIOUS LIBV
<libv> really.
<mru> isn't that what you wanted to hear?
<libv> why would you think that?
<libv> without anything in the wiki, no progress anywhere would have been made
<libv> so stop telling people to steer clear of the wiki
<mru> I never did
<libv> and definitely stop talking crap about it
<libv> 15:05 < mru> it's just a distraction
<mru> I suggested he focus on getting things working first
<libv> 15:05 < mru> doing that won't help you get it working
<mru> _then_ document it
<libv> that's a sure fire way to never document anything
<mru> and how you've wasted 10 minutes of my time that I could have spent helping our friend
<libv> and to shoot yourself in the feet
<libv> we've been here before, and you keep it up
<libv> stop trashing the wiki
mru has left #linux-sunxi ["bye asshole"]
<libv> saves me some trouble
<libv> pcactus: while to some it might seem a waste of time, you will find that you make up for it as you go along
<libv> and you will be very glad to be able to come back to it in 2ys time when the vendor decides to no longer be in business or to no longer sell this hw
<apritzel> prefixcactus: what are the RAM chip(s) on that device, can you read that?
<prefixcactus> the code checks out
pcactus has quit [Quit: Quit]
<apritzel> prefixcactus: and you have four of them, for a total of 1GB?
dev1990 has quit [Quit: Konversation terminated!]
<prefixcactus> that's right
<libv> apritzel: prefixcactus posted a dropbox link with schematic and everything: https://www.dropbox.com/sh/mg4683te1j09nbn/AABZ5a3JuIGWB-lOUGUHUFkba?dl=0
<libv> ah, no carrier board only
<libv> still using .fex
<prefixcactus> Is there a good way to pull working settings from the manufacturer's sources?
<apritzel> libv: thanks, but yeah, can't find the SoM schematics in there
<apritzel> prefixcactus: no a *good* way ;-)
<libv> prefixcactus: .fex :)
<apritzel> the beginning of boot0 contains some encoded DRAM parameters, typically
<apritzel> prefixcactus: if you post a hexdump of the first KB somewhere, I could have a look
<libv> so meminfo has atrophied it seems :(
<prefixcactus> no meminfo in the fw I've got
<libv> meminfo is part of sunxi tools that we used all the time when the sunxi market was still mostly tablets and settop boxes
<prefixcactus> apritzel: https://pastebin.com/b4v56GkK
<apritzel> ah, it looks like those are x16 chips (judging by the chip number), if you have four of them, that would mean dual rank, I guess?
<prefixcactus> libv: I've compiled it from sunxi-tools and uploaded; it says "Error: unknown or unhandled Soc: 0x1701"
<apritzel> and our sunxi-dw DRAM driver says: /* Currently we cannot support R40 with dual rank memory */
<prefixcactus> hrm.
<prefixcactus> does that mean I'm stuck with legacy U-boot then?
<apritzel> prefixcactus: it's not the end of the world, it just means that there was no board with dual rank so far
<prefixcactus> mhm
<libv> prefixcactus: yeah, sorry, atrophied and no longer useful
<apritzel> maybe MoeIcenowy or jernej know more about it
<apritzel> prefixcactus: do you have the schematic for the SoM, by any chance?
<prefixcactus> It appears I do not.
<apritzel> prefixcactus: thanks for the boot0 dump, I spot the parameters in there, but need more time tonight to dig out the details
<prefixcactus> I suspect I could request it from Forlinx, though
<prefixcactus> You're welcome :)
<apritzel> prefixcactus: can you confirm that the label on the RAM chips reads "9LK17 D9PSK"?
<prefixcactus> It reads "OCK15 D9PSK". The first line is a date code, I think
<apritzel> prefixcactus: and you could try to lower the DRAM clock freq, that sometimes helps to work around timing issues
<prefixcactus> I did it just now (to 312), didn't help
reinforce has quit [Quit: Leaving.]
<apritzel> prefixcactus: thanks, was worth a try
<apritzel> prefixcactus: but you don't see any messages like "Dual rank memory not supported" (with mainline), do you?
<apritzel> prefixcactus: which could mean it's just a matter of the delay timings: https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sunxi_dw.c#L717
<apritzel> (which are encoded in the boot0 header)
<prefixcactus> er, I don't see any messages at all
<prefixcactus> beside "U-Boot SPL 2020.10 (Feb 04 2021 - 16:54:38 +0300) // DRAM: 0 MiB // ### ERROR ### Please RESET the board ###"
<prefixcactus> apritzel: would the boot0 uart log be of any value?
<apritzel> prefixcactus: yes, at least it doesn't hurt ;-)
<apritzel> *sometimes* there is interesting info in there
<prefixcactus> apritzel: here you go then: https://pastebin.com/2XTZzz3K
<apritzel> prefixcactus: interesting, is that the boot0 you dumped? because the hexdump suggests LPDDR3 at 648 MHz, but the bootlog says DDR3 @ 576 MHz
<prefixcactus> might be a different one, hold on.
<prefixcactus> the one I dumped was from an sd card image; the log was taken when booting from emmc
<prefixcactus> I can dump the emmc boot0 as well
<prefixcactus> I can dump the emmc boot0 as well, I think
<prefixcactus> that said, given that the sd image was supposed to burn a new firmware (and successfully did it), it might have overwritten it in the process
<prefixcactus> Yep, it did
<prefixcactus> apritzel: Here's the boot log from the flashing process and an emmc boot with the new boot0: https://pastebin.com/jKGR0Mja
paulk-leonov has quit [Ping timeout: 272 seconds]
paulk-leonov has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<prefixcactus> libv: should I create a page for the SOM itself, or for the whole devboard?
kaspter has quit [Quit: kaspter]
<apritzel> prefixcactus: do the whole board, for a start
<jernej> I don't have experience with common DW DRAM driver, but I guess principle can't be that different to the H6 one
akaWolf has quit [Ping timeout: 240 seconds]
<apritzel> prefixcactus: thanks, this log lists the DRAM parameters explicitly (line 538+), I think this overrides the builtin boot0 header parameters
fl_0 has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #linux-sunxi
akaWolf has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
pcactus has joined #linux-sunxi
victhor has joined #linux-sunxi
fl_0 has quit [Ping timeout: 276 seconds]
fl__0 has joined #linux-sunxi
chewitt has joined #linux-sunxi
fl_0 has joined #linux-sunxi
fl__0 has quit [Ping timeout: 272 seconds]
<pcactus> apritzel: Thanks! How do I know which parameter number corresponds to what, though?
<apritzel> pCactus: you don't ;-) I have some notes somewhere ...
<libv> prefixcactus: the devboard is your companies own, right?
<libv> or is this the devboard of forlinx?
<libv> btw, the hw manual for this devboard on this vendor page is already a dead dropbox link...
<apritzel> dropdeadbox?
pcactus has quit [Read error: Connection reset by peer]
pcactus has joined #linux-sunxi
<libv> :)
pcactus has quit [Ping timeout: 240 seconds]
pcactus has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
pcactus has quit [Read error: Connection reset by peer]
pcactus has joined #linux-sunxi
<pcactus> libv: This is Forlinx's devboard, but we intend to design our own carrier board, too
JohnDoe8 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 258 seconds]
<libv> ah, then that would be valuable for our wiki as well
chewitt_ has joined #linux-sunxi
\\Mr-C\\ has joined #linux-sunxi
chewitt has quit [Ping timeout: 276 seconds]
\\Mr_C\\ has quit [Ping timeout: 276 seconds]
sam23 has joined #linux-sunxi
sam23 has quit [Client Quit]
matthias_bgg has quit [Ping timeout: 246 seconds]
\\Mr-C\\ has quit [Quit: (Read error: Connection reset by beer)]
\\Mr_C\\ has joined #linux-sunxi
eduardas has quit [Quit: Konversation terminated!]
vagrantc has joined #linux-sunxi
JohnDoe8 has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
macc24 has quit [Ping timeout: 258 seconds]
macc24 has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
lurchi_ is now known as lurchi__
mauz555 has joined #linux-sunxi
lurchi__ is now known as lurchi_
hlauer has quit [Ping timeout: 265 seconds]
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
cmeerw has quit [Ping timeout: 240 seconds]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
mauz555 has quit []
sunshavi has quit [Remote host closed the connection]