<apritzel>
now you just need to transfer the values into your defconfig. I think BrokenR3C0RD's latest branch has still some unused parameters, so use "0" if in doubt
<Kirby64>
Yup, already in progress. I had to define the paras as well since his provided defconfig didn't have para0/1/2
<Kirby64>
These are very different than what I was trying... so, hopefully it works haha
<apritzel>
I just merged the sunxi-fw A133 patches, so you can use the main branch now as well, has a slightly better formatting
<Kirby64>
Huh. still getting aliasing issues?
<Kirby64>
it seems to be getting the expected size correct
<apritzel>
this is on my TODO list, but not today anymore ;-)
<Kirby64>
hmmm, I'll take a look. Is the A133 code in mainline closer to H616? H616 and A133 arch code seems pretty different in the masterrecord branch
<apritzel>
there is no A133 in mainline yet, just some slightly massaged version in my local branch, being prepared for another post
<Kirby64>
Ah, ok
<apritzel>
eventually we hope that we can indeed unify some of that code, but that's a bit more work, and should not block the A133 support
<Kirby64>
I'm wondering if I break something by just nulling out RAM testing and seeing if it works
<Kirby64>
gonna try that first haha
<apritzel>
you cannot really make it worse than "it's not working" ;-)
<Kirby64>
I could somehow get the PMIC to output enough voltage to break everything in theory ;)
<Kirby64>
but yeah, likely not.
<Kirby64>
Hm, okay if I stub out the dram test code I get to 'Trying to boot from FEL' and nada
<Kirby64>
Well, DRAM appears to be initialized. If I just load the SPL, it reboots back into FEL
<Kirby64>
./sunxi-fel spl u-boot-sunxi-with-spl.bin kicks back to FEL, and I can read 0x40000000 without it crashing now
<Kirby64>
(and write to it)
<Kirby64>
so, something is working there...
<apritzel>
ah, nice
<apritzel>
when you use "-v -p" on the sunxi-fel command line, does it tell you more where it hangs?
<Kirby64>
oh. I think it was the BSS thing you made me change
<Kirby64>
I just commented that out, recompiled, and it looks like it made it past. It's not blasting UART with debug info. Need to comment that out now...
<Kirby64>
oh wait, hm
<apritzel>
you can also upload the bits separately (after it returned): sunxi-fel -v -p write 0x4a000000 u-boot-dtb.bin reset64 0x4a000000
<Kirby64>
it's repeatedly hitting 'Unhandled Exception in EL3'
<apritzel>
you can skip TF-A for now, at least should get you to the U-Boot prompt
<apritzel>
not sure which TF-A branch or build target you use, but that's all WIP
<Kirby64>
Yeah. I'm not, just doing eGON and it seems to be OK
<Kirby64>
So, I'm getting this right now over UART, repeatedly
<Kirby64>
isn't 'CONFIG_SPL_IMAGE_TYPE_SUNXI_EGON=y' the non-TF-A?
<Kirby64>
Or do I want to not even include BL31 as an argument?
<Kirby64>
(that might be my issue)
<apritzel>
that has nothing to do with that, it's just for the SPL image format
<apritzel>
you will eventually need TF-A, so you need to provide a binary location on the command line for a working image
<apritzel>
pick one of the A133 (mainline-based) branches floating around, or just use the mainline H6 build, which somewhat works (TM)
<apritzel>
or just skip TF-A entirely, by manually loading the components: sunxi-fel -v -p spl sunxi-spl.bin write 0x4a000000 u-boot-dtb.bin reset64 0x4a000000
<Kirby64>
Hm, alright, let me try that first then
<apritzel>
the dump was about an undef instruction somewhere early in DRAM, which is odd, as TF-A should run in SRAM, so something is fishy there with the setup
<Kirby64>
well, I got U-Boot boot screen with that command
<Kirby64>
(basically just mirroring what I compiled in I guess, and the DRAM tests)
<apritzel>
but not further? U-Boot relocates itself early, to the end of DRAM, so there might be still something subtly wrong with that
<Kirby64>
Nope. Just stalls there
<Kirby64>
Wondering if the memory init stuff isn't working quite right with 2GB? From reading all the past convos I don't recall seeing anyone test this with >1GB
<Kirby64>
but I might have overlooked one somewhere
<apritzel>
so does it have 1GB or 2GB? With the old checking code, we had the code often misdetect the size, reporting double the amount
<Kirby64>
It's 2. It's a 16Gb RAM chip
<Kirby64>
confirmed visually on the actual silicon part number
<apritzel>
you could limit DRAM with CONFIG_SUNXI_DRAM_MAX_SIZE=0x40000000, just as a test
<Kirby64>
yeah, I really don't need 2GB for what I want to do anyways...
<apritzel>
I doubt it, but maybe the pulled the old ZX Spectrum trick, and used DRAM chips that are faulty in one half ;-)
<Kirby64>
Anything to save a buck haha
<Kirby64>
Still reports 2GB even with limiting max size?
<Kirby64>
(also I tried 2000 0000 as well
<Kirby64>
and still stalls at same point
<Kirby64>
Anything I can add to just dump a bunch of debug messages maybe? See where it's failing?
apritzel has quit [Ping timeout: 480 seconds]
zamon has quit [Remote host closed the connection]
zamon has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
zamon has quit [Ping timeout: 480 seconds]
zamon has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
bauen1 has joined #linux-sunxi
Kirby64 has quit [Ping timeout: 480 seconds]
<Lightsword>
well I ported the vendor BSP i2c driver...and all requests just time out to i2c3....so guessing I'm still missing something
Kirby64 has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.6.1]
Daanct12 has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Kirby64 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
bauen1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
<junari>
dlan: yes, phy reset was necessary in my cases with walnutpi and x96qpro+
<junari>
don't know why, but snps,reset-gpio works bettet than reset-gpio in phy node
testaccount has joined #linux-sunxi
testaccount has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
radxanaoki has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 480 seconds]
paulk-ter has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
paulk has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
bauen1 has joined #linux-sunxi
gsz has joined #linux-sunxi
ndufresne has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
<apritzel>
dlan: montjoie: so who will be sending the patches for the A523 EMAC0 Ethernet support?
<apritzel>
we need a series with at least five patches: syscon binding, sun8i-emac binding, common a523.dtsi changes, patch for radxa .dts, patch for avaota .dts
<apritzel>
I am happy to contribute a patch that squashes the syscon default value warning (by removing that variable altogether), but need to test it still
<apritzel>
if we move now, there is a good chance it makes it still for 6.16
<montjoie>
I will not send anything, not author of anything. but I could retest any patch serie you want
<apritzel>
thanks, that would be useful for my dwmac-sun8i patch! Still not quite sure why we relied on having this default_syscon_value in there, but happy to have a discussion on the list
<montjoie>
would be a good test for my fresh bot-auto-build-boot-from-mailinglist
<apritzel>
ah, nice!
<dlan>
apritzel: most of the patches are copy-and-paste.. if you want me do it, then probably will slow, I'll get to it at later this week.. and may need some help to check somes detail, 1) if need fallback compatible, 2) reset pin isn't handled (not populated in DT), but maybe should ..
<dlan>
and if you want to take over, then I'm all good
Kirby64 has joined #linux-sunxi
<apritzel>
you did the work, so you deserve the patches ;-) If you could get the ball rolling still this week, that would be best.
<apritzel>
the binding patches should be easy, we just need the a523 specific name add to the list of ones also using the A64 compatible strings, for both syscon and emac
<apritzel>
and they should be the first to go, since they probably go through different trees, so would benefit from a head start
<apritzel>
for the actual DT patches we can talk to wens and jernej directly ;-)
<dlan>
ok, that would be fine
<dlan>
I could come up with an initial version for review
<dlan>
works on linux too, I'll roll out linux patch first, to get compatible reviewed first, then in uboot, we could copy them
<apritzel>
yes, U-Boot picks up DTs from the kernel repo now automatically (although with some delay), but anyway there is no support merged yet in U-Boot anyways, so it's a bit theoretical at this point
<montjoie>
ah ah ah ah it is alive, all sunxi patches will(should) be auto builded and booted
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<Lightsword>
apritzel, I just realized that twi3 in the working vendor BSP firmware doesn't even appear to be enabled at all in Linux
<apritzel>
Lightsword: lol, was already wondering how sure we are that it's actually I2C3 on those pins
<apritzel>
you could search github for sun50iw9 to see if you find some BSP code with DTs in it
gsz has joined #linux-sunxi
<apritzel>
just figured I could check in the X96 Mate vendor DTB. I2C3 is enabled there, on Pins A10/A11, with mux 2, so that checks out
zamon has quit [Remote host closed the connection]
<apritzel>
there is an ominous "ac200" pin, on PB0, pinmux 2, but not sure what this does. It's only referenced by some weird "clock" node, as: pll10 = <&ac200>;
<apritzel>
and some other ac200 node says: tv_used = <1>; tv_twi_used = <1>; tv_twi_id = <0x03>; tv_twi_addr = <0x10>; tv_pwm_ch = <0x05>;