rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
<apritzel> or even 5.12-rc2+ if you add the dummy NMI to the AXP DT node
<pnill> apritzel: here's a random question for you, what's a good place to write in DRAM for the file that I want to use to write to disk
<apritzel> pnill: I typically use $kernel_addr_r (0x40080000)
<apritzel> pnill: or 0x50000000, if you have a kernel already
<smaeul> apritzel: ok, I am using h616-v5 currently. I have to rebase it to drop this bad patch (which was later removed from sunxi-next):
specing_ has joined #linux-sunxi
<apritzel> smaeul: yeah, true, I bases that one on sunxi-next ...
<apritzel> smaeul: I can actually push my latest branch to github as well
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
shailangsa has joined #linux-sunxi
<smaeul> apritzel: that would be good, thanks
<apritzel> some hacks and preliminary patches still in there
<apritzel> pnill: basically most of DRAM is available in U-Boot, short from the last few MBs, where U-Boot lives
<apritzel> smaeul: does the MX10 have Gigabit Ethernet?
<apritzel> (I remember I saw it on eBay, but found a better offer with the X96)
<smaeul> apritzel: no, only 100M, there's no external PHY
<smaeul> do any of them have gigabit?
<apritzel> I didn't really find one, no
<apritzel> 100 Mbit means Ethernet won't work in Linux
<apritzel> (or U-Boot, for that matter)
montjoie has quit [Ping timeout: 240 seconds]
montjoie has joined #linux-sunxi
tuxd3v has quit [Remote host closed the connection]
tuxd3v has joined #linux-sunxi
shailangsa has quit []
<pnill> Wondering what's easier now, running SPL to get dram initialized and using sunx-fel to write my data into DRAM from there
<pnill> or using U-boot to load files from usb into DRAM then writing to ext4 that way
Mangy_Dog has quit [Ping timeout: 240 seconds]
<apritzel> pnill: depends on how big the file to upload is
<pnill> 2.2KBs and 288 bytes
<apritzel> yeah,then of course use FEL, since you use that already anyway
<apritzel> depending on the SoC, FEL runs at ~500KB/s, so if you need to upload multiple MBs, other solutions are much faster
<pnill> So I tried something like this: /sunxi-fel write 0x40080000 /home/crich/Desktop/a1up_mods/rc.local
<pnill> after doing sunxi-fel spl path-to-uboot-spl
<pnill> then used sunxi-fel uboot path-to-uboot-spl
<pnill> and tried to do md to read 0x40080000
<pnill> and it was random/junk data
atsampson has quit [Ping timeout: 250 seconds]
<pnill> did I screw up DRAM when I used uboot to boot back into the spl/did it clear that space.
<apritzel> pnill: if you use "uboot" you will start the SPL again, which will (re-)initialise the DRAM
<pnill> ahh ok
<pnill> so it'll clear it out.
<apritzel> just use it all on one command line
<pnill> Use it all on one command line?
atsampson has joined #linux-sunxi
<apritzel> sunxi-fel uboot path-to-uboot-spl write 0x40080000 /home/crich/Desktop/a1up_mods/rc.local ....
<pnill> oh, I didn't even know that was supported
<pnill> lol
<pnill> awesome! that worked, thanks again apritzel
<apritzel> I think the uboot command does the SPL part first, then uploads all the other payloads, and only at the end starts execution
<MoeIcenowy> apritzel: well re-initialize DRAM should be a UB
<MoeIcenowy> it could get the DRAM scrambled, or maybe something would be preserved
<apritzel> MoeIcenowy: we assert the controller's reset, don't we? So it starts from scratch
<MoeIcenowy> apritzel: DRAM is not a part of your SoC, it's an independent component
<apritzel> I managed to probe DDR3 vs LPDDR3 this way: try one, if that fails, reset DRAMC, try the other
<MoeIcenowy> BTW I think U-Boot now faces a problem
<MoeIcenowy> codes should be moved out of arch/arm/mach-sunxi as much as possible
<apritzel> MoeIcenowy: sure, but in my experience you can run the spl command as often as you like
<MoeIcenowy> as many
<MoeIcenowy> as we are now facing sunxi SoCs that is not of architecture "arm"
<apritzel> MoeIcenowy: yeah, I see
<apritzel> we could move them to board/sunxi, maybe?
<MoeIcenowy> maybe
<MoeIcenowy> BTW sunxi BSP now defines some macros for SoC generation
<MoeIcenowy> BTW some bad news, D1 have new memory map
<apritzel> yeah, I think smaeul mentioned NCAT before
mripard has quit [Ping timeout: 260 seconds]
<MoeIcenowy> (and sunxi BSP duplicated many source files into arch/riscv/mach-sunxi/ to support RV
<apritzel> MoeIcenowy: is that really a problem? We need new Kconfig symbols anyway, so can surely put new addresses there this way
<MoeIcenowy> well it's not a big problem
<pnill> hmm
<pnill> well, that didn't work how I would've hoped lol
<MoeIcenowy> but we may see new ARM sunxi SoCs with new memory map
<apritzel> MoeIcenowy: wouldn't be the first one to change that
<apritzel> I mean the H6 is already vastly different, so it's just one more #ifdef ;-)
<MoeIcenowy> well but to be honest I didn't start U-Boot work yet
<MoeIcenowy> I'm still struggling to make sunxi-fel a multi-architecture program
<MoeIcenowy> it embeds too many ARM machine codes
apritzel has quit [Ping timeout: 252 seconds]
mripard has joined #linux-sunxi
shailangsa has joined #linux-sunxi
<smaeul> MoeIcenowy: do you already have the D1 SDK?
<pnill> Hmm, ext4write isn't letting me overwrite one of the files wondering if it's due to fs permissions
shailangsa has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
shailangsa has joined #linux-sunxi
pnill has quit [Ping timeout: 252 seconds]
pnill has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Danct12 has quit [Remote host closed the connection]
buzzmarshall has quit [Remote host closed the connection]
<pnill> So is there an easy way to boot linux via sunxi-fel I don't see much about it on the wiki so far
<pnill> oh, I guess I could boot from USB or something
<pnill> That scares me
<pnill> lol
<pmp-p> it's just a few python code + sunxi fel tools
<pnill> Does it have support for H6
<pmp-p> it should support everything allwinner
<pnill> how is it handling sending the linux image over
<pmp-p> read the source ?
<pmp-p> it's really simple it writes bash code for you
<pnill> Everything it says on the page is H2/H3 specific
<pmp-p> because i don't have generics kernel+fex for A20/23 H5/H6
<pmp-p> you must add your own same for dtb
<pnill> oh, you wrote this?
<pmp-p> i did
<pmp-p> sunix tools could need refreshing i thing there was a patch for faster usb recently
<pnill> Is it just me or is the git for it empty
<jernej> pmp-p: that higher speed FEL patch didn't work for me on one of the newer SoCs, I just can't remember if it was H6 or H616
<pmp-p> ha good to know thank you
<pnill> seems the H3Droid setup just writes to DRAM
<pnill> which is what I was trying to avoid doing because I'd assumed it was gonna be slow over FEL
<pnill> lol
<pmp-p> it's usually around 1MiB/s
<pmp-p> some boards are faster than others idk why
<pnill> my linux image is like 32mb
<pnill> lol
<pmp-p> maybe use lzma compression i think a 4x kernel should be around 16MiB
<pmp-p> lzma is not a problem you have all ram avail for at boot ;)
<pnill> I tried just shoving it into DRAM, then using booti
<pnill> failed on some magic issue.
<pmp-p> the fel installer code should show you both mainline and legacy methods
<pmp-p> once booted you may want to have it's really handy
<pnill> just found this tidbit,
<pnill> I was only trying to upload the image
chewitt_ has quit [Quit: Adios!]
<pnill> hmm, not really sure what I'm doing wrong.
<pnill> Is the dtb generated by u-boot incompatible with the one used by the linux kernel?
ganbold has quit [Ping timeout: 252 seconds]
<pnill> yeah, no luck uploaded my kernel image into RAM then used bootm 0x4008000
<pnill> and it just throws "Wrong image Format for bootm command"
<pnill> "Can't get kernel image"
<pmp-p> you said kernel then it's booti
<pmp-p> ideally you would use booti on a lzma image + a bzip2 enabled uboot
<pnill> Why does the wiki under U-Boot#Compile_U-Boot suggest mainline kernel to use bootm
<pnill> Ok so booti 0x40080000 gets it to throw "Starting Kernel ..." then it's locked up.
<pmp-p> i have no idea, i try to keep things simple and separated send uboot/atf , send kernel, send ramdisk , send boot.scr with booti
<pmp-p> i guess bootm will find out kernel + rd address itself
<pmp-p> "Starting Kernel ..." sounds good maybe add some parameters to get earlyprintk and stuff
<pmp-p> also triple check your uart-ttl is working, it's depressing to look at ouput of an unplugged one :p
ganbold has joined #linux-sunxi
<pnill> it's working, this is board that already has firmware on it.
<pnill> and such
<pnill> I'm trying to boot from ram to modify the fs that's already there
<pnill> what would root= be set to if the fs is in ram?
<pmp-p> to the ramdisk device name
<pnill> I think it panicked
<pmp-p> yep and that's very early not my league
vagrantc has quit [Quit: leaving]
<pnill> looks like I got it now
<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
<smaeul> can you link the DTS you are using?
<pnill> - and this is the decompiled one from the device's stock setup
<pnill> I tried playing around with the mmc2 area
<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 = <&reg_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?
<pnill> Was trying to do this,
<pnill> but it seems like it's never looked at
<pnill> hmm, let me check if fel_scriptaddr is the same as scriptaddr
<smaeul> spl->fel_script_address should have been set by sunxi-fel
<pnill> yeah, I don't think it was set though
<pnill> => print fel_scriptaddr
<pnill> ## Error: "fel_scriptaddr" not defined
<pnill> Nothing like that in the boot log.
<smaeul> what is the output of `mkimage -l boot.scr` ?
<pnill> boot.scr was fine, I was able to source it manually
<pnill> from the memory address
<pnill> it just doesn't get executed on the boot
<smaeul> it looks like sunxi-fel will only print that info with -v
<pnill> ^ sunxi-fel output
BenG83 has joined #linux-sunxi
<apritzel> pnill: for sunxi-fel to detect the script, the U-Boot image has to have IH_TYPE_SCRIPT
<pnill> Is that something configurable from menuconfig, or do I write it in .config?
<smaeul> lol and it also has to be IH_ARCH_ARM, not AArch64
<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]
<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
<lightspot21> trace it? Thanks in advance.
dev1990 has quit [Quit: Konversation terminated!]
indy has quit [Quit: ZNC -]
indy has joined #linux-sunxi
afaerber has quit [Ping timeout: 245 seconds]
TEKrantz has joined #linux-sunxi
vagrantc has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
victhor has joined #linux-sunxi