<pnill>
need to figure out how to get mmc working so I can mount that now
gsz has joined #linux-sunxi
<pnill>
looks like it's failing while trying to configure pins for it
<pnill>
"[ 5.731419] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1 on device 300b000.pinctrl
<pnill>
"
<pnill>
uboot was able to initialize it so wondering why kernel has problems
<pnill>
"[ 5.976364] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back
<pnill>
"
<pnill>
that one specifically if I understand correctly should be the right one
<pnill>
but pin 65 is a bit weird.
cmeerw has joined #linux-sunxi
<pnill>
so I'm guessing the device tree is the issue but not entirely sure how to fix it.
warpme_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
tuxd3v has quit [Ping timeout: 252 seconds]
jstein has joined #linux-sunxi
Wizzup has quit [Ping timeout: 265 seconds]
Wizzup has joined #linux-sunxi
reinforce has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
<apritzel>
pnill: as I mentioned, the Wiki is not updated at places, and many instructions are for 32-bit systems
<apritzel>
pnill: I just updated FEL/USBBoot to cover 64-bit systems as well
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
<apritzel>
pnill: if you could name more Wiki pages that you found and used, I can check them as well
<apritzel>
pnill: re> Linux boot messages: some of them are e red ha
<apritzel>
pnill: re> Linux boot messages: some of them are a red herring
<apritzel>
sometimes prerequisites like pinctrl or regulators are still not loaded, so other drivers bail out, and are probed again later when all the other drivers are up
lucas_ has quit [Quit: Leaving]
lucascastro has joined #linux-sunxi
Danct12 has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
specing_ has joined #linux-sunxi
ChanServ has quit [shutting down]
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
ChanServ has joined #linux-sunxi
JuniorJPDJ has quit [Quit: authenticating]
JuniorJPDJ has joined #linux-sunxi
ChanServ has quit [shutting down]
ChanServ has joined #linux-sunxi
chewitt has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
gsz has quit [Remote host closed the connection]
Kwiboo has quit [Quit: .]
gsz has joined #linux-sunxi
gsz has quit [Client Quit]
vagrantc has joined #linux-sunxi
gsz has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
camus is now known as kaspter
Kwiboo has joined #linux-sunxi
lkcl has quit [Ping timeout: 265 seconds]
lkcl has joined #linux-sunxi
<jernej>
apritzel: did you try to use whole 4 GiB of RAM on your H616 TV box?
<apritzel>
jernej: not yet
<jernej>
I'm wondering if this is as easy as easy as adjusting SPL code
<apritzel>
yeah, this is a pure U-Boot software issue, right?
<jernej>
unless if drivers don't have dma mask set correctly
<jernej>
DE2/DE3 can work with 36 bit addresses, but driver needs adjustments
<apritzel>
IIRC most Linux device use a 32bit DMA mask by default anyway, don't they?
<apritzel>
the new MMC controller has its DMA address bits shifted by 2, so can cover 16 GB, but we still keep the DMA mask at 32 bits
tuxd3v has joined #linux-sunxi
<apritzel>
the EMAC DMA still seems to be limited to 32bit anyways
<apritzel>
jernej: do you expect big issues with this?
<jernej>
not really, but when I was working on initial SPL support, I didn't want to worry about that
camus has joined #linux-sunxi
buzzmarshall has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
<apritzel>
the MMC driver doesn't use DMA anyway
<apritzel>
but the EMAC driver seems to do, and U-Boot's heap is probably at the end of DRAM?
<apritzel>
but I bought this box for exactly this reason: to test 4GB, eMMC and the AC200 PHY ;-)
<jernej>
yeah, this is my reason as well :)
<tuxd3v>
what is that box guys? :)
<jernej>
btw, I wrote AC200 PHY driver over a year ago for H6, but I still didn't figured out how to properly design DT nodes
<jernej>
if you have any ideas, please tell :)
<apritzel>
jernej: yeah, I remember we talked about the AC200 DT before
<apritzel>
jernej: it's a bit annoying, since the actual register functionality is quite easy, IIRC
<jernej>
yes, you need also working PWM driver
<jernej>
which was actually not that easy to mainline, but anyway
<apritzel>
ah, using PWM passby to forward the 24MHz clock?
<jernej>
yes
diego71 has joined #linux-sunxi
<pnill>
So apritzel: I'm trying to get linux kernel running with a small busybox ramfs
<pnill>
Using your H6 WIP
<pnill>
and it's throwing stuff like ""[ 5.731419] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1 on device 300b000.pinctrl"
<pnill>
if I find any other Wiki pages btw I'll be sure to point em out
<pnill>
But that error message/there's no mmc devices in /dev/
<pnill>
so I'm wondering if it's the dts/how I can go about trying to correct it
<pnill>
Reading into other people getting the same error seems they had issues with their dts on a pine64 but I looked it over and didn't see anything that stood out
<pnill>
I guess it really has to be the device tree
<pnill>
because nothing else would make sense in terms of the driver or such imo
DrFrankensteinUK has quit [Read error: Connection reset by peer]
DrFrankensteinUK has joined #linux-sunxi
<pnill>
So far just kinda have things booting setting bootargs to root=/dev/ram0 and rootfstype=ramfs
DrFrankensteinUK has quit [Read error: Connection reset by peer]
<pnill>
then booti with the appropriate stuff.
DrFrankensteinUK has joined #linux-sunxi
<pnill>
[ 5.852249] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
<pnill>
I dunno if that's similar to the "axp dummy" bsp stuff uses
<smaeul>
the dummy regulator messages are harmless
<pnill>
and add like cap-cmd23; commenting out current cap
<smaeul>
pnill: your problem is that you are referencing the AXP PMIC regulators that don't exist
<pnill>
and appending cd-gpios
<pnill>
so do I just comment that stuff out?
<pnill>
That's the thing I really don't understand how this part works.
<smaeul>
vcc-pc-supply = <®_bldo2>; <-- this won't let any driver request pins on Port C until the regulator is enabled
<pnill>
and the only reference I have is the original
<smaeul>
pnill: yes, remove the whole r_i2c node and any references to reg_[abc]ldo? or reg_dcdc[abcde]
<smaeul>
the DTS describes the hardware components and the relationships between them, like what regulator powers which power domain
<pnill>
So in the case of this board what does it mean when a "dummy" regulator is used
<pnill>
like the SoC just handles everything itself in terms of power management?
<smaeul>
that means no regulator was provided in the DTS (the foo-supply property was missing), so the kernel assumes all needed power is always-on
<smaeul>
your DTS should probably look more like sun50i-h6-tanix-tx6.dts, which has fixed regulators instead of a PMIC
<smaeul>
though if you just need eMMC and UART to work, you may not need any regulators at all, just /aliases, /chosen, &mmc2, and &uart0
<pnill>
So, the current dts don't have any /alias or /chosen blocks like the original dts does
<pnill>
I mean to say the ones that have been created/exist within the kernel already.
<pnill>
that I've seen.
<pnill>
Are those included by the default sunxi file?
<pnill>
in any case I took the tanix one and just added a mmc1/mmc2 block
<pnill>
with the same regulator stuff from the mmc0 block
<pnill>
To see if that works, otherwise I also removed the stuff you mentioned from the orangepi one
<pnill>
smaeul: I love you.
<pnill>
Just saying.
<pnill>
In other words, that appears to have worked.
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
thefloweringash has quit [Ping timeout: 245 seconds]
psydruid[m] has quit [Ping timeout: 245 seconds]
davidebeatrici has quit [Ping timeout: 245 seconds]
Tooniis has quit [Ping timeout: 245 seconds]
kayterina has quit [Ping timeout: 245 seconds]
<smaeul>
pnill: the /aliases and /chosen nodes are used to set the default kernel console settings. they aren't strictly necessary since you can use console=... on the kernel command line as well
thefloweringash has joined #linux-sunxi
psydruid[m] has joined #linux-sunxi
davidebeatrici has joined #linux-sunxi
<smaeul>
the mmc2 node shouldn't match mmc0 exactly, though it may work like that. I'd recommend copying the &mmc2 node from the Orange Pi 3 DTS, minus the supplies
<smaeul>
for example, mmc2 won't have a CD pin because it's non-removable, and it should have bus-width = <8>; to get the full speed
Tooniis has joined #linux-sunxi
kayterina has joined #linux-sunxi
<smaeul>
though tbh if you only boot mainline once, just to update a few files, whatever works is good enough
<pnill>
yeah, I updated it that way (the way you described, and added non-removable and such)
<pnill>
Is there a configuration that has to be set within u-boot for it to use the boot.scr written to RAM at script_addr?
<apritzel>
smaeul: ah, indeed. pretty sure MoeIcenowy already has a patch for that ;-)
<smaeul>
pnill: recreate the script image with `-A arm` instead of arm64 and see if that works
<pnill>
Do I also need to re-compile u-boot after doing that?
<smaeul>
no, just mkimage on the script
<pnill>
Because the "IH_TYPE_SCRIPT" confused me lol
<pnill>
was looking into how to set that.
<smaeul>
it's part of the header added by mkimage
<pnill>
mkimage updates the u-boot spl image?
<pnill>
My understanding was that the sunxi-fel tool was looking at the spl image for the IH_TYPE_SCRIPT thing
<smaeul>
mkimage is used for a lot of things. one of them is wrapping your boot.scr
<pnill>
yeah, so I just used mkimage -C none -A arm -T script -d boot.cmd boot.scr
<pnill>
I didn't modify the u-boot image at all after doing that.
<apritzel>
mkimage can now also create the magic and checksum that the BROM requires, but as smaeul that is completely separate
<smaeul>
sunxi-fel looks for IH_TYPE_SCRIPT in boot.scr, and when it sees that, copies the address of boot.scr (from the command line) into the SPL header
<pnill>
ahh, ok
<pnill>
I misunderstood and though it was checking the spl header
<pnill>
for IH_TYPE_SCRIPT
<pnill>
*thought
<pnill>
Also didn't realize initially that sunxi-fel had to do some extra leg work in the process
<pnill>
had assumed that scriptaddr was just read from by u-boot itself
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 5.0.1, revision: 5.0.1+git-7433-0df9f22f2, build type: debug, sources date: 20160102, built on: 2019-12-08 19:19:20 UTC 5.0.1+git-7433-0df9f22f2 http://www.kvirc.net/]
<pnill>
awesome yeah,
<pnill>
making it arm vs arm64 worked
choozy has joined #linux-sunxi
choozy has quit [Client Quit]
BenG83 has quit [Quit: Leaving]
gsz has quit [Ping timeout: 260 seconds]
lightspot21 has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
cmeerw has quit [Ping timeout: 245 seconds]
<lightspot21>
hello, so I am trying to port linux to an Allwinner F1C100s device. Latest kernel and uboot have been ported and work correctly. However, I also need to initialize an LCD screen, with a driver already provided in source. Although it compiles, when I attempt to load it I get a segfault on dma_alloc_attrs. I have found the culprit line, and it is a DMA allocation (dma_alloc_coherent). What could be the cause? And how can I somehow