<MasterR3C0RD>
Drops the PHY patch, and replaces it with just falling back to the D1 configuration. Will submit in a few days, as I'm waiting to see if I get any more feedback on the other patches
<apritzel>
I changed TPR11,TPR12,PARA1,PARA2 to use the values reported by boot0 after the eye scan, hence the slightly different aliased value (and the report about 16 instead of 14 rows)
<apritzel>
that's 2GB of LPDDR4 DRAM, btw
<MasterR3C0RD>
apritzel: Thank you! Yes, the numbers printed matched up with 2GiB of RAM (2 << (cols + rows + banks + bankgrps + ranks) * (full_width == 1 ? 4 : 2) is the relationship; before it would have only initialized 512MiB of RAM)
<MasterR3C0RD>
The differences at +200d0 imply that there's a different MR value being used as that correlates with mctl_ctl->init[]; I'll check which MRs those relate to. Next diff is DRAMTMG[0] and DRAMTMG[1]; I'd be interested to see if you get different results using the H616 timings
<apritzel>
parthiban: btw: I hacked up a boot0 binary grabbed from some update image to go to FEL after the DRAM init, so one can now upload payloads (U-Boot, kernel) into DRAM
<MasterR3C0RD>
s/DRAMTMG[0] and DRAMTMG[1]/DRAMTMG[2] and DRAMTMG[6]/
<MasterR3C0RD>
Interesting; I'm writing `0xd05` to init[2], but that isn't reflected in your dump
<MasterR3C0RD>
Looks like MR11 should be 0x0003 instead of 0x0004
<MasterR3C0RD>
Ah wait, I've been misreading the diff
<MasterR3C0RD>
Everything I've said is in reverse LOL
<MasterR3C0RD>
Aside from slight differences, which could be from as little as different boot0 versions, the only differences I see seem to relate to potential differences in DRAM parameters
<MasterR3C0RD>
Actually, I did find another difference; I was writing vref to the wrong place
ftg has quit [Read error: Connection reset by peer]
Parthiban has joined #linux-sunxi
parthi has joined #linux-sunxi
Parthiban is now known as Guest7693
parthi is now known as parthiban
Guest7693 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
JohnDoe_71Rus has joined #linux-sunxi
hipboi has joined #linux-sunxi
junari has quit [Remote host closed the connection]
MasterR3C0RD has quit [Quit: Bye-bye!]
MasterR3C0RD has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<MasterR3C0RD>
apritzel: I reviewed your register dumps; most of the differences appear to be related to calibration or differing parameters, but I did catch one issue where the VREF value was being written to the wrong offset. I'm surprised it didn't affect DDR4, but seeing it gets written to two places it might imply something interesting about the result you
<MasterR3C0RD>
were getting during the RAM test
<MasterR3C0RD>
More precisely, the RAM test writes 0x1234567 to RAM at a few places and then reads it back; the result in the diff was 0x1230000. Perhaps when using LPDDR4, the two VREFs are used, and somehow one's related to the upper addresses, while the others are related to those lower
apritzel has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
The upper address bits were getting read correctly since the writes were little endian; the upper bytes would hold `0x2301` but the lower bits would read nothing
<MasterR3C0RD>
parthiban: ^, if you get a chance it'd be cool to see if my latest U-Boot changes fix DRAM init on your board now
<parthiban>
MasterR3C0RD: I should be able to check in next hour.
Schimsalabim has quit [Ping timeout: 480 seconds]
<parthiban>
which branch or tree should I try this time?
<MasterR3C0RD>
My branch still, BrokenR3C0RD/u-boot branch allwinner-a133
<MasterR3C0RD>
If it errors out, let me know what the value it reads from 0x40000000 (I added a change that should print that out, something like 0x40000000 = ...)
Schimsalabim has joined #linux-sunxi
<MasterR3C0RD>
It's just about 5AM where I'm at, so I'll see it in a few hours. I feel pretty hopeful though considering it was getting very close on apritzel's board during our last testing session
<parthiban>
Not sure, pastebin wasn't happy because of the size. uploaded to my gihub
<parthiban>
s/gihub/github
<MasterR3C0RD>
The odd bit is that considering the para1 was different I would expect at least columns to change in your output
<MasterR3C0RD>
Or rows
<parthiban>
I have the part number of the LPDDR4. Will that help?
<MasterR3C0RD>
It might, but I'm still confused. You're certain you rebuilt after changing the parameters? And it still said it had exactly 10 columns, 14 rows, and 3 banks even after changing out the PARA1 value?
JohnDoe_71Rus has joined #linux-sunxi
<MasterR3C0RD>
The para1 value from sunxi-fw would come out to 10 columns and 14 rows; on the other hand the value in your config should have come out to 10 columns and 16 rows
<apritzel>
MasterR3C0RD: please consider replying to the comments on the mailing list, and be it to acknowledge them and announcing a fix in v2
<apritzel>
It's important to keep the conversation on the list, for archival purposes and to help later research
<apritzel>
you can also add more insight, or challenge some comments, if you think you have a better idea
warpme has joined #linux-sunxi
<loki666>
apritzel I'll also respond on the list for your PLL patch
warpme has quit []
<apritzel>
ah, yeah, thanks!
montjoie_ has joined #linux-sunxi
<MasterR3C0RD>
apritzel: Will do; I just wasn't sure if responding to the emails is the preferred way to go about it
montjoie has quit [Ping timeout: 480 seconds]
<apritzel>
yes, definitely, that's basically required for the history in the archives. It can be very terse, and typically you briefly reply before sending out a new version
<MasterR3C0RD>
Alright; sounds like basic protocol then. Doing everything through email just makes everything feel a lot different
<apritzel>
yeah, it's the equivalent of some "Resolved" check mark in gerrit or such
<parthiban>
MasterR3C0RD: eMMC works, but am still figuring to get the WiFi working with sdio line. Firmware loading fails in my end still.
<MasterR3C0RD>
parthiban: Did you have it working before?
<dok>
hi, i am trying to boot linux on a A64 (Pine64-Plus) but i am having HW traps exceptions, I believe this is cause by the cpu clock speed beeing too high. Any idea on how to lower the cpu clock speed when booting/via bootparams ?
megi has joined #linux-sunxi
<apritzel>
dok: what kernel are you running? Is that something mainline or an official distro kernel or some kernel specifically made for the Pine64+?
<dok>
just recompiled a kernel 6.6.49
<dok>
using the config from alpine linux
<dok>
but also booting from barebox instead of u-boot
<apritzel>
and what do you mean with "HW traps exceptions", exactly? Typically random crashes are more DRAM related, I wouldn't know about issues with too high clock speed
<apritzel>
so that's not from the kernel, but from the bootloader, I guess barebox in your case?
<dok>
yes
<dok>
but this is when trying to boot
<dok>
but this issue is also present when i set the cpu-pllx to 1.2Ghz
<dok>
so it might just be a broken DRAM initialization
<apritzel>
I don't think it has anything to do with CPU speed, really
<dok>
okay
<apritzel>
so yes, DRAM might be an issue, but it might also be something else. Does that happen reliably, with the same report?
<dok>
i happen almost all the time when clock speed is higher
<dok>
but with different exception address
<dok>
also it says PC Alignment exception (ESR 0x8a000000) at 0x4500400641109057
<dok>
but this address isn't valid
<apritzel>
why 1.2 GHz, anyway? Isn't 1.152GHz the max for the A64?
<dok>
i should try to use u-boot for dram initialization only so i could confirm the issue is related to DRAM
<dok>
uh, i though it was 1.2GHz
<apritzel>
maybe I missed that, but does barebox actually support Allwinner chips with Arm cores? I only found the D1 (RISC-V cores)
<dok>
not yet ^^
<apritzel>
it's 1.152GHz, and you need the appropriate voltage. Anything else is asking for trouble
<dok>
okay i need to double check all of this
<dok>
where should i look for the correct/uptodate information ?
<apritzel>
U-Boot keeps the default AXP803 voltage, which is too low even for 1.152GHz, IIRC
<dok>
uhm!
<apritzel>
that's why we start with a lower frequency (816MHz), and leave the higher speeds for Linux to enable
<apritzel>
which knows about the OPPs and also how to control voltage and frequency properly
<dok>
i also sets the pll-periph to 1.2GHz
<dok>
is this an issue ?
<apritzel>
that's fine, that's the recommended frequency for that PLL, anything else would be troublesome
<apritzel>
it's divided down for the various peripherals (hence the name)
<dok>
ok great, i am going to try again with 816Mhz
<apritzel>
the CPU PLL is separate, and defaults to 408 MHz, out of reset
<apritzel>
if you look for the voltage/frequency values: sun50i-a64-cpu-opp.dtsi is your friend, for instance in the kernel tree, or anything importing that
<dok>
thanks, i missed this .dtsi
<apritzel>
the AXP default seems to be 0.9V for DCDC2, so that's already a stretch for even the lower frequencies
<dok>
yeah it didn't worked either, i am going to try with the default one
theslowcoder has joined #linux-sunxi
<apritzel>
but again I doubt it's the frequency, looks like a random pointer corruption to me (mind those high bits set)
<dok>
i am having the same issue when booting at 408MHz
<dok>
i will have to look at dram initization
<dok>
thanks for your help apritzel
<dok>
i am running a memory tester but so far it didn't shows any issue, i will keep you updated if it does
<apritzel>
did you copy the DRAM code from U-Boot?
<theslowcoder>
I've been working on some patches to get some basic support for the V851S in mainline kernel. Some minor work still left (pinctrl names verification, checkpatch, etc), but it's working nicely on my custom PCB. Its been "a while" since I've submitted to the kernel, and they've changed procedures a few times since then. How can I avoid making the sunxi community looking like complete noobs? I assume there's no sunxi specific ma
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<MasterR3C0RD>
theslowcoder: I'm definitely one of the noobs heh, but there is a linux-sunxi kernel list I submitted my patches to: https://lore.kernel.org/linux-sunxi/
<theslowcoder>
MasterR3C0RD: Huh, I thought that list was abandoned. Pretty sure I read it on the website. But obviously it's not
<MasterR3C0RD>
Aside from that the only thing I had really forgotten to do was check my bindings and DTS files, which otherwise doesn't get picked up by checkpatch
<apritzel>
theslowcoder: that list is very much alive, there was an older list, on some googlegroups server, which is not in much use anymore
<MasterR3C0RD>
apritzel: I had thought the Google groups one was the current one initially, as that's what the wiki page pointed to
<theslowcoder>
Ah, yes, regarding the DTS files. My board is very custom and not available to the public. I assume it's okay to just publish a "sun8i-v851s.dtsi" and no board-specific DTS ?
<dok>
apritzel: yes i copied the DRAM code from U-Boot, but i had to modify the code so it can link with barebox
<apritzel>
as MasterR3C0RD said: run as many checks as possible, checkpatch, DT bindings checks, then make sure you have good commit messages and a cover letter
<apritzel>
then double check everything, send emails to yourself first, then to the people and lists shown by scripts/get_maintainer.pl
<theslowcoder>
apritzel: Ok. Seems like what I was planning to do anyways. After sending to the sunxi list, will the maintainer move it to mainline, or is that something I'll have to do myself?
jernej has quit []
jernej has joined #linux-sunxi
<apritzel>
you send to all people and lists at the same time, there is no extra step
<apritzel>
be warned: upstreaming a new SoC is quite tedious, you would at least need quite some breath
<theslowcoder>
Oh, so it's straight to lkml as well? No intermediate step possible where I can have it reviewed?
<apritzel>
no, it's full in, but don't worry
<theslowcoder>
breath?
<apritzel>
I'd say it takes about half a year until things will get merged, if things go well
<theslowcoder>
Holy heck. Don't think I'll be able to follow up on that on a chip that we've already decided not to use..
<apritzel>
well, send the patches anyway - maybe someone else is interested and can pick it up
<theslowcoder>
Just figured I'd "quickly" get the patches upstreamed, so someone else could have some use for them
<MasterR3C0RD>
Essentially your patches get be reviewed by maintainers/reviewers once it's on the list. Once you get feedback and implement it, you submit a new version. Then you'll get feedback on the new patches, and the cycle continues
<theslowcoder>
Ah, so, basically use lkml as an archive ?
<apritzel>
... as happened to MasterR3C0RD, who updated some patches for the A100/A133, originally sent a fews years back
<theslowcoder>
MasterR3C0RD: Yep, been studying that
<apritzel>
lkml is actually mostly that: an archive. Most development and review happens on specialised lists, where the maintainers and reviewers are subscribed
<theslowcoder>
Well, if I'm being honest with myself. While it would be nice to get a kernel submission, I'm much too busy and scatterbrained to follow up in a decent way.
<theslowcoder>
So. If someone feels they have the time+energy, I've got some hardware I can send your way, as well as patches to make it go
<apritzel>
you could at least post them. It wouldn't be very nice to immediately abandon it, but still much better than not posting it
<theslowcoder>
Sidenote: The reason we started looking at V851S is because the V3s is NRND from AllWinner, and they recommended the V851S as a replacement. (Nope, no NDAs signed with them)
<MasterR3C0RD>
theslowcoder: How large is the patch series?
<MasterR3C0RD>
Approximately
megi has quit [Quit: WeeChat 4.4.2]
megi has joined #linux-sunxi
<apritzel>
MasterR3C0RD: excellent replies on the list, many thanks!
<theslowcoder>
Well, in my tree it's 1 patch, but it need to be broken up. It touches 20 file in total. 4 are just one-liners. 5 Kconfig/makefile. 1 entirely new dtsi file. 3 new files (and accompanying headers) for CCU and pinctrl. 5 dt-bindings files
<apritzel>
so that's the basics, what about the other peripherals? USB, MMC, Ethernet, ...
<theslowcoder>
Those would be the oneliners and dtsi files. All peripherals are identical to other already supported sunxi chips. Just different base-address, clocks, etc, which is dealt with in the dtsi
<theslowcoder>
USB, SDHC, SPI, I2C, UART are all confirmed working on my hardware
<apritzel>
so basically you need to find someone who bites the bullet and reviews the clock driver, as that's the biggest beast
<theslowcoder>
Yep. Especially on this bastard. Two CCUs, as it's an ARM+RISC-V chip. (No R5 support in my patchset though)
<MasterR3C0RD>
apritzel: Thank you! Still feels like I jumped into an ice-cold pool, but I'm starting to get used to it HAHA
<MasterR3C0RD>
theslowcoder: What about U-Boot; did you have any luck getting mainline up-and-running, or did you just use the vendor tree?
<theslowcoder>
MasterR3C0RD: We gave it a shot, but we're far from impressed by the organization of the uboot code. We were using awboot to boot it
<theslowcoder>
MasterR3C0RD: Basically a big contributor to us moving to the T113 instead. Also, much more grunt in the T113 and wider choice for displays
<theslowcoder>
Hmm. Maybe I should at least start with brain-dumping on the wiki about what we've learned
<apritzel>
theslowcoder: yes, thanks, that would be much appreciated!
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
if you could at least post the CCU driver, that would save other people a lot of work
<theslowcoder>
I can send-and-forget to the sunxi list, if that's enough?
parthiban has quit [Read error: No route to host]
parthiban has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
not ideal, but better than nothing, yes
<theslowcoder>
Regarding documentation. I'm not completely comfortable uploading leaked PDFs. But the datasheet is out there, just a short google away
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
ftg has joined #linux-sunxi
<MasterR3C0RD>
theslowcoder: Which compatible is used for the USB PHY?
<MasterR3C0RD>
Does it require a new config structure or is it similar to another device's?
<theslowcoder>
MasterR3C0RD: I had to create my own. Didn't find one that fit
<theslowcoder>
MasterR3C0RD: It's exactly like the sun20i_d1 config, but with num_pyhs=1 instead
<parthiban>
I just noticed that the helper board A133 comes with AW869A, which I doesn't upstream support? or this IC uses broadcom/realtek/marvel? Not much documentation I can't find with quick search.
<parthiban>
s/doesn't/doesn't have/
<jakllsch>
sounds like maybe another Allwinner chip?
<parthiban>
Got it, there are firmwares as well. Not too old.
<parthiban>
Aicsemi, new to me.
<MasterR3C0RD>
I'll have to try and get WiFi running on my device; I remember when I took apart my device I saw a Realtek chip so I'm somewhat hoping that's what's in use
jernej has quit [Remote host closed the connection]
ungeskriptet is now known as Guest7790
ungeskriptet has joined #linux-sunxi
ungeskriptet is now known as Guest7791
ungeskriptet has joined #linux-sunxi
apritzel has joined #linux-sunxi
Guest7790 has quit [Ping timeout: 480 seconds]
<apritzel>
MasterR3C0RD: so with you latest changes the test reads 0x1c59a68 from 0x40000000
Guest7791 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
apritzel: Interesting; and that's a stable result?
<apritzel>
ah no, not really, hitting reset a few times also gives: 0x1c54568 and 0x1234568 (twice)
<MasterR3C0RD>
Second one's very interesting, it looks like it's really trying its hardest
<apritzel>
yeah, I thought as well, getting closer ...
<MasterR3C0RD>
But the changing results I think point to a non-address mapping issue
<MasterR3C0RD>
Have you tried with the H616's timings?
<apritzel>
was just about to ask: how compatible are they?
<MasterR3C0RD>
I think they're the same, with minor differences where mine checks a few extra quirk flags in TPR13
<apritzel>
can I just compile/hack them in? Or are some registers different?
<MasterR3C0RD>
No register differences, I already have the ability to choose them enabled in Kconfig
<MasterR3C0RD>
Which does point to the possibility that we can unify the two drivers at a later point
<MasterR3C0RD>
That would necessitate a H616 board to touch any of that code though, I wouldn't want to break anything on the already working driver in the process
<apritzel>
yeah, I very much look forward to that, happy to help here. Maybe gamiee can arrange to send a Chameleon to you
<apritzel>
I got quite some H616 boards, with DDR3, LPDDR3 and LPDDR4, so happy to test, but first lets get this A133 LPDDR4 working ;-)
<MasterR3C0RD>
That would be hugely useful. On the A133 front, I'll likely pick up an A133 "Plus" device so I can figure out if there's more OPP fun to have; will order that end of week potentially. But yes, working DRAM init on these boards is what I want to start with
<apritzel>
I had my eye on one of those cheap Liontron A133 boards on Aliexpress ...
<MasterR3C0RD>
As you mentioned, the more boards spread among us, the better
<MasterR3C0RD>
Btw, apritzel: what does the DRAM diff look like now? Is the diff growing smaller? Some will remain different simply because I believe those are results from read gate calibration and DX/CA deskew, but at the very least I think a few of the offsets at the start might be related to state?
warpme has joined #linux-sunxi
warpme has quit []
<loki666>
btw: I'm thinking to send one of my H700 device to whomever feel like chasing this crash issue, as I'm unable to help
<apritzel>
mmh, the diff differs ;-) anything in particular I should look out for? I guess the measured values are in the PHY section? So focus on the first part?
<apritzel>
loki666: so do you see this issue on multiple devices? All the same model, or different types?
<MasterR3C0RD>
I believe the issue is with the PHY at this point; I'm rebuilding the PARA0, TPR11 and TPR12 that boot0 is using for calibration, which should reduce the diff significantly
<loki666>
I have 3 differents models, and they all have the DRAM detection issues (some more than others) and they all have the kernel crash when a dynamic gov is enabled
<loki666>
maybe these issues are linked, I really have no ideas
<MasterR3C0RD>
apritzel: Double checking, as I pulled this together from your last diff's mainline dump; is PARA0 = 0x231F1B23 in your config?
<MasterR3C0RD>
For U-Boot
<apritzel>
I have CONFIG_DRAM_SUN50I_PARA0=0xd0a050c, from sunxi-fw, boot0 doesn't print this value, I think
<MasterR3C0RD>
Hmm curious
<MasterR3C0RD>
I suppose those are probably being updated by the PHY then
<apritzel>
but I got the very same number as you when piecing this together from the mainline dump
<apritzel>
let me check boot0 ...
<apritzel>
same
<apritzel>
wait... do you actually write val2?
<MasterR3C0RD>
GAH
<MasterR3C0RD>
You can try fixing the latter 4 writes to use val2...
theslowcoder has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
I kept slipping over that one because when I had written a broken version before, DDR4 boot would straight up fail
<MasterR3C0RD>
And since it was working, it must be correct right? :(((
<MasterR3C0RD>
Considering the VREF fix made things better, it's probably safe to assume it's another case where LPDDR4 depends on extra value sets
<apritzel>
YES! DRAM simple test OK.
<apritzel>
2048 MiB
<MasterR3C0RD>
HOORAY!!!
<apritzel>
so many thanks, awesome work!
<MasterR3C0RD>
Thank you for finding that bug
<MasterR3C0RD>
Not far off from "j = 0; i < 10; ..."
<apritzel>
lol, yeah
<apritzel>
good teamwork, I'd say
<apritzel>
actually the compiler probably saw that and happily optimised away para0 ;-)
<MasterR3C0RD>
HAHAHA
<apritzel>
"stupid humans"
<apritzel>
alright, let me enable MMC and USB now ...
<MasterR3C0RD>
You should be able to just copy over the DTSI from my patches
<MasterR3C0RD>
And enable the nodes in your device's DTS
<apritzel>
yeah, that's the plan
<MasterR3C0RD>
In terms of USB, driver model being incompatible with MUSB tripped me up for a few hours the other day, as well as some issues specifically because my device uses an A-to-A connection for FEL and doesn't have a VBUS detect or ID detect GPIO
<apritzel>
A-to-A is shockingly common, and I think there was a patch for MUSB DM a few months back, but that dried up at some point
<apritzel>
I have a super cheap hub with switches per port, which actually just disconnect Vcc, so that's perfect for those kind of devices
<MasterR3C0RD>
Ah I never thought about that; I have one of those too
<MasterR3C0RD>
I did notice it would get reversed power from some devices, so I shouldn't have been surprised that's all it's doing...
<apritzel>
I leave that switch off, but of course USB peripheral mode (incl. FEL) still works
<apritzel>
yes, both sides driving 5V is asking for trouble, but in practise I rarely had issues, at least not with decent host ports, like in x86 laptops
<apritzel>
I guess they are resilient enough to just ignore that, or the builtin Vcc regulator fights that off somewhat naturally
<apritzel>
the other solution is to just slice the cable open and cut the red wire
<MasterR3C0RD>
My solution to connect the devices together is already a hack; my partner has a USB-C female to USB-A male adapter that they used to connect a USB-C webcam to their laptop
<MasterR3C0RD>
So I just plugged a USB-C to A cable into that
<apritzel>
lol, USB-C female to A male? hilarious ...
<MasterR3C0RD>
Yeah, weirdest little adapter I've ever seen. Never thought there'd be another use for it but here we are HAHA
<apritzel>
I have some proper USB-A to USB-A cables, which blatantly violates the USB spec, and should never be allowed to bear a logo. Yet they of course do ...
<MasterR3C0RD>
It's a wonderful world
<MasterR3C0RD>
Anyways, the next few steps for the DRAM driver would be figuring out bank group auto-detection, and then merging this into the H616 driver; both tasks I'd like to take when I have a couple more devices I can work with
<MasterR3C0RD>
Well, the first would be nice to figure out sooner, but I haven't yet figured out how to decipher the bank group aliasing pattern
<apritzel>
ah, thanks for updating your repo, was already wondering what comes after "even morer fixes" ;-)
<apritzel>
not sure about the bank group auto-detection, but you should definitely post the DRAM driver as is to the U-Boot list, rather sooner than later
<apritzel>
I was actually wondering if we follow the D1 driver, and put that in drivers/ram. Then we can later move the H616 over, by merging it into the A133 one
<MasterR3C0RD>
That would be a good idea, though then we'll have DRAM parameters being pulled from mach-sunxi's DRAM config. We could move the parameter definitions to the driver/ram/sunxi Kconfig instead for the A133 driver, and then move other drivers over to there as we go. Additionally, considering the oddities with PARA1/TPR13, I might like to hold off
<MasterR3C0RD>
submitting for a little bit; with bank group detection we'd be able to get rid of a few of the parameters, and it would hopefully help with consistency
jernej_ has quit []
jernej has joined #linux-sunxi
jernej has quit []
jernej has joined #linux-sunxi
jernej has quit []
jernej has joined #linux-sunxi
jernej has quit []
jernej has joined #linux-sunxi
<apritzel>
yes, less parameters would be better
<MasterR3C0RD>
I just wish the aliasing made sense; I'll try again and see if I can crack the puzzle