<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:
<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>
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
<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?
<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!]