rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
Rafael1980 has quit [Quit: Konversation terminated!]
<catphish> seem to have run into the first totally undocumented part of the memory init process :( which is in fact the whole dram controller of the h3
<catphish> someone somewhere knows how it works because there's linux code for it, but no explanation
<catphish> jerry wang knows :)
<apritzel> catphish: Linux? DRAM controller?
<catphish> the code i'm reading is u-boot
<apritzel> catphish: take my advice: just use that code
<catphish> it initializes the dram with some magic constants :)
<apritzel> honestly: this is probably as best as it gets
<catphish> yeah, i guess i'll copy it and hope it works :)
<apritzel> and the H3/A64/H5/R40 DRAM driver has very little "magic" constants, comparably
<catphish> i'm trying to understand as much as possible as i go, but the h3 dram controller has no docs (community or official) at all
<catphish> so i'll just have to trust that the u-boot code is doing the right thing
<catphish> my code reads: mctl_ctl->clken = 0xc00e; // ????
<catphish> but it's ok, i thought there'd have to be a little of this
<apritzel> I understand this "I want to understand things", but if you follow this route, you won't finish any time soon
<apritzel> compare to this for instance: drivers/ram/mediatek/ddr3-mt7629.c
<apritzel> just a random pick, there are worse drivers
<catphish> wow
<apritzel> modern DRAM controllers are somewhat rocket science, and very complex, by nature
<apritzel> so even if you have full documentation, it's still daunting
<apritzel> if you just want to use DRAM and move on to your actual goal, then just take that code and don't waste your time
<catphish> i kinda rated my chances based on the number of lines of init code in u-boot :)
<catphish> and for the h3 it doesn't seem *that* bad
<catphish> so worst case i can just copy/paste the parts i don't understnd
<catphish> yeah, i'm understanding what i can and will try not to get bogged down by the undocumented parts
<apritzel> well, even with documentation you first need to understand what On-die-termination, ZQ values and DQS delay lines mean
<apritzel> I mean, having the A380 manual doesn't make you a seasoned pilot, you know? ;-)
<catphish> indeed, the docs i've read suggest that a lot of that stuff just needs to be copied from reference examples anyway
<catphish> "The actual values used here are taken from Allwinner provided boot0 binaries...so we go with those generic values for now..."
<catphish> etc
chomwitt has quit [Quit: WeeChat 1.6]
<catphish> just got to the next function, you're right, this isn't worth the time!
AneoX has joined #linux-sunxi
kever has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
<apritzel> catphish: why don't you actually just use U-Boot? That would save you many troubles, but still allow your own bare-metal code
aballier has quit [Ping timeout: 245 seconds]
<apritzel> catphish: you could even use the U-Boot API or the UEFI protocols for stuff like mass storage and network
<apritzel> tbh I would at least use the SPL
<catphish> apritzel: i actually started doing that, but a couple of things bothered me, the main one being the boot speed, a fully u-boot is slow
<apritzel> well, just use the SPL
<apritzel> and plant your code in the .img file instead of U-Boot proper
aballier has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
<apritzel> that solves DRAM init and loading
<catphish> the other being that i couldn't really know exactly what state the hardware was in, u-boot does some detection, so the state of the hardware isn't always predictable, for example if the hdmi is plugged in, u-boot initializes it, if it's not, it doesn't
<catphish> i'd be very very happy if i could work out how to use u-boot in a stripped down form that did only dram
<apritzel> I don't think the SPL touches any of this
<apritzel> that's the SPL, actually
<catphish> well u-boot SPL sounds good
AneoX has quit [Ping timeout: 268 seconds]
<catphish> i'd briefly considered it, but then just assumed i could do it myself
<catphish> since that's not the case, i think i will indeed look at u-boot spl
<apritzel> when using a FIT image it's quite flexible: you can let it load any number of binary data blocks (read: files) to arbitrary locations in memory
<catphish> it's hard to explain why i like doing things "tha hard way"
<apritzel> catphish: I understand this very well, but you have to be reasonable at some point ;-)
<catphish> is there some information about how to build such a thing?
<apritzel> build U-Boot for your board and look at the resulting u-boot.img file
<apritzel> that's in the "legacy" U-Boot image file format, basically just any code with a load address and an entry point
megi has quit [Ping timeout: 245 seconds]
<catphish> just building a new one now
vagrantc has quit [Quit: leaving]
<apritzel> so it's about just wrapping your code with mkimage, then putting it at sector 80 of the SD card
AneoX has joined #linux-sunxi
<catphish> well i have a boot.img
<apritzel> tools/mkimage -l u-boot.img
AneoX_ has quit [Ping timeout: 250 seconds]
kever has quit [Ping timeout: 268 seconds]
<apritzel> The SPL is very minimal, it just initialises what it needs: the basic clocks, DRAM, the needed pins, MMC most likely, and that's about it
<apritzel> it doesn't even remotely touch USB, Ethernet, HDMI or anything like that
kever has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
<catphish> i'm not quite sure i understand what i'm doing, i have u-boot.bin but it's that the full u-boot without the SPL?
AneoX has quit [Ping timeout: 245 seconds]
<apritzel> yes
<apritzel> the SPL binaries are in the spl/ directory
<catphish> ah, perfect, thanks
<apritzel> u-boot-spl is the ELF, u-boot-spl.bin is the binary version
<apritzel> sunxi-spl.bin is the eGON wrapped version you write to the SD card or load via FEL
<catphish> even better :)
<apritzel> u-boot-sunxi-with-spl.bin is what is says on the tin ;-)
<catphish> yeah i've used that previously, it worked great until i decided it was too slow
<apritzel> so I would take the info that mkimage -l gives you, then re-create the image file with you own code instead of u-boot.bin
<apritzel> or run make V=1 and check for the mkimage call
<catphish> oh, so i can replace u-boot.img with my own code, then pack it back together with the spl?
<apritzel> yes
<catphish> that sounds like exactly what i want, hadn't realised it would be so easy
<apritzel> "pack together" sounds more complicated than it is: you just put the image at sector 80 of the SD card
<catphish> initially i'd quite like it in a file i can pass to FEL
GrimKriegor has quit [Ping timeout: 240 seconds]
<apritzel> well, or that, sure
<catphish> ie "u-boot-sunxi-with-spl.bin" format
<apritzel> you can just do it like real man(TM): sunxi-fel spl sunxi-spl.bin write 0x4a000000 your-code.bin exe 0x4a000000
<catphish> marvellous
<apritzel> that loads and runs the SPL first, which returns to FEL so that you can load any other stuff, but now into the initialised DRAM
<catphish> that's actually the best imaginable outcome :)
<apritzel> you can have as many write <addr> <file> parts as you like
<apritzel> just one exe at the end of course ;-)
GrimKriegor has joined #linux-sunxi
<catphish> yeah i've been doing that previously to load various data :) cool tool
<catphish> one more thing: what is u-boot.img? i assume ultimately i will need to convert my own code to that format to have FEL autoload it?
<catphish> it's just the binary with a header that mkimage generates?
<apritzel> u-boot.img is u-boot-with-dtb.bin prepended with a "U-Boot legacy image format" header
<apritzel> just 64 bytes, IIRC
dddddd has quit [Ping timeout: 240 seconds]
kaspter has quit [Read error: Connection reset by peer]
<catphish> so if i want a full image, i can pack my own code into such a .img file, then combine it with the spl?
<catphish> i assume there's a script somewhere i can copy that does all this
kaspter has joined #linux-sunxi
<apritzel> well, it's well hidden and obfuscated in the Makefile
<apritzel> ;-)
<catphish> well "sunxi-fel spl sunxi-spl.bin write 0x4a000000 your-code.bin exe 0x4a000000" works perfectly
<apritzel> if the SPL is loaded from SD/eMMC, it expects an legacy U-Boot image file at sector 80 (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR)
dddddd has joined #linux-sunxi
<apritzel> if the SPL is loaded via FEL, it just returns to FEL and leaves to loading up to sunxi-fel
<catphish> oh, so u-boot-sunxi-with-spl.bin is just a file that cleverly lands u-boot legacy at the right location on the disk, and when it's read by sunxi-fel, the tool detects this and uploads it to 0x4a000000?
<apritzel> yes
<apritzel> there is some extra code in sunxi-fel to detect this case and pick the load address from the image header
<catphish> perfect, thanks for all your assistance, this is definitely a much saner direction to go in
<apritzel> if you get bored later on, you can still replace the SPL with your own code, but for now you can have colourful christmas trees on the screen much sooner ;-)
<catphish> indeed! sadly i need to rewrite my christmas tree code because i doubt my A20 display driver will work on the H3
<apritzel> I think the cmd line is: mkimage -A arm -T firmware -C none -O u-boot -a <load address> -e <entry point) -n <some name> -d your-code.bin your-code.img
<apritzel> if you pad sunxi-spl.bin to 32KB, then append your-code.img, you have your u-boot-sunxi-with-spl.bin
<apritzel> yeah, the H3 used "DE2", which is somewhat different
<apritzel> but U-Boot supports both, so you can pick up the differences by comparing the code there
<catphish> oh, your-code.img immediately follows sunxi-spl.bin, that makes things easier :)
<catphish> and yeah, i'll go have a look at the DE2.0 code in u-boot, i don't think the docs are great
<apritzel> "immediately follows" is only true if the SPL is 32KB, but yeah, that was the idea of using sector 80
<apritzel> I believe most 32-bit boards get away with a 24KB SPL (size is made multiples of 8K)
<catphish> my sunxi-spl.bin is actually only 24
<apritzel> that's why I said you need to pad it to 32KB
<catphish> oh, duh, yeah
<catphish> you did :)
<apritzel> the H6 SPL is about 32500 bytes, it's all very tight ...
<catphish> isn't the spl hardware limited anyway?
<apritzel> yes, 32KB
<catphish> oh yeah, though smaller on the older chips iirc
<apritzel> yes
<catphish> ah, 24k on a20
<catphish> anyway, i think i'm good for now, going to tidy some things up then i'll attack DE2.0
<catphish> hopefully i can write all this down too
<apritzel> I wanted to clean up and join those boot pages in the Wiki anyway
<apritzel> rellla, libv: can any of the Wiki admins change the "Log in" link at the top right corner to use https://
<apritzel> I tend to typically browse the wiki with http, but when I want to edit, Firefox warns me (rightfully) that my password would be send unencrypted after clicking on "Log in"
<apritzel> I guess the link just keep the current protocol, but can we force it to https?
drt1245 has joined #linux-sunxi
<catphish> just make it all https :)
<apritzel> or this, if the server can take it
Andy-D has quit [Remote host closed the connection]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 240 seconds]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 245 seconds]
anarsoul|2 has quit [Ping timeout: 250 seconds]
apritzel has quit [Ping timeout: 268 seconds]
<MoeIcenowy> montjoie: I realized a problem that a MDIO mux is not the best way to represent the mux on H3
<MoeIcenowy> it does not only mux MDIO but also mux MII
<MoeIcenowy> when a fixed-link is desired, MDIO is not used, but MII is connected externally
popolon has quit [Quit: WeeChat 2.3]
<wens> MDIO still needs to be routed externally in some cases where the switch chip connected on the fixed-link communicates using MDIO instead of I2C
<wens> plus, if you have MII routed externally, having MDIO routed internally doesn't make much sense
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 240 seconds]
anarsoul has joined #linux-sunxi
<MoeIcenowy> wens: however the problem is that when a fixed-link is used and the switch is I2C
<MoeIcenowy> the mdio-mux makes no sense
<MoeIcenowy> and dwmac-sun8i doesn't know how to mux it
<MoeIcenowy> should we add a property to force external PHY?
<catphish> is there a register to reset the whole SoC?
<catphish> or does one use the watchdog?
<MoeIcenowy> use watchdog it okay
<MoeIcenowy> set it to the lowest interval
<catphish> ok :)
Chank8 has joined #linux-sunxi
<MoeIcenowy> wens: the mux controls both MII and MDIO ;-)
Chank8 has quit [Ping timeout: 246 seconds]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 268 seconds]
<catphish> nice, i can actually use the watchdog for its intended purpose and restart my chip if i crash it :)
leviathanch has joined #linux-sunxi
<wens> MoeIcenowy: you're right
kever has quit [Ping timeout: 246 seconds]
kever has joined #linux-sunxi
nuuuciano has quit [Remote host closed the connection]
nuuuciano has joined #linux-sunxi
<smaeul> if you think half a second is too long to wait, you can get an immediate reset using the trusted watchdog :)
<catphish> it's ok, i can wait :) might look at the trusted watchdog though, i saw it in passing but had no immediate need
<catphish> well, i started over, i have mmu, serial and GPIO working https://github.com/catphish/allwinner-bare-metal/blob/master/main.c
<catphish> i should probably sleep now, tomorrow HDMI :)
nuuuciano has quit [Remote host closed the connection]
lurchi_ is now known as lurchi__
dddddd has quit [Remote host closed the connection]
nuuuciano has joined #linux-sunxi
<pmp-p> catphish: don't forget to baremetal this one too ;) http://linux-sunxi.org/AR100
<anarsoul> :)
<MoeIcenowy> pmp-p: crazy
<pmp-p> i'm sure there's room for micropython in there :p
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 268 seconds]
aballier has quit [Ping timeout: 245 seconds]
aballier has joined #linux-sunxi
aballier has joined #linux-sunxi
kelvan has quit [Remote host closed the connection]
merlin1991 has quit [Read error: Connection reset by peer]
merlin1991 has joined #linux-sunxi
kelvan has joined #linux-sunxi
return0e_ has joined #linux-sunxi
return0e has quit [Ping timeout: 246 seconds]
f0xx has joined #linux-sunxi
NeuroScr has quit [Read error: Network is unreachable]
IgorPec has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
reinforce has joined #linux-sunxi
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
victhor has quit [Ping timeout: 252 seconds]
victhor has joined #linux-sunxi
airwind has joined #linux-sunxi
NeuroScr has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 246 seconds]
aalm has quit [Read error: Connection reset by peer]
nuuuciano has quit [Ping timeout: 240 seconds]
nuuuciano has joined #linux-sunxi
paulliu has joined #linux-sunxi
AneoX_ has quit [Quit: Textual IRC Client: www.textualapp.com]
clemens3_ has joined #linux-sunxi
AneoX has joined #linux-sunxi
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
AneoX has joined #linux-sunxi
megi has joined #linux-sunxi
apritzel has joined #linux-sunxi
clemens3_ has quit [Ping timeout: 246 seconds]
tllim has quit [Read error: Connection reset by peer]
hanetzer has quit [Quit: WeeChat 2.3]
apritzel has quit [Ping timeout: 246 seconds]
hanetzer has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
msimpson has joined #linux-sunxi
msimpson has quit [Read error: Connection reset by peer]
BenG83 has quit [Ping timeout: 268 seconds]
msimpson has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
<catphish> pmp-p: i saw that processor, looks kinda cool, no idea if i'll find a use for it :)
qeed has quit [Quit: Leaving]
BroderTuck has joined #linux-sunxi
apritzel has joined #linux-sunxi
<BroderTuck> I read that gcc proper will get support for the or1k architecture that the AR100 uses, so soon(ish) one won't need the out-of-tree fork anymore.
apritzel has quit [Ping timeout: 250 seconds]
tnovotny has joined #linux-sunxi
airwind has quit [Quit: airwind]
aalm has joined #linux-sunxi
f11f12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<montjoie> MoeIcenowy: I do not have any board with fixedlink, so hard to work on this
<MoeIcenowy> montjoie: I tried to let a Banana Pi M2+ to work with fixed link ;-)
<plaes> libv: o/ could you switch linux-sunxi domain to https?
<apritzel> the AR100 might be a dying breed anyway: The A63 product brief lists a Cortex-M4 instead
<plaes> o_O
<KotCzarny> [']
<apritzel> I believe some company recently started bundling M cores with A cores ;-)
<MoeIcenowy> apritzel: H6 still use AR100 ;-)
<apritzel> MoeIcenowy: I know, I use it in ATF for powering off secondary cores
<catphish> M4 seems like a saner choice really
<libv> plaes: looking into it
<libv> the omap5 had 2 a15s with 2 m4?s
<libv> i was sent on an automotive project where the "architect" blackballed someone for pointing out that it only had 2 virtualizable cores instead of the 4 that the "architect" claimed it had
<KotCzarny> seems its going to be successful project
<KotCzarny> with happy users
<libv> that was in 2012
<libv> and crashed and burned pretty badly
<KotCzarny> oh, at least it worked out ok then
bauxit3 has joined #linux-sunxi
bauxit3 has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 246 seconds]
orhaneee has joined #linux-sunxi
orhaneee_ has joined #linux-sunxi
orhaneee__ has joined #linux-sunxi
orhaneee__ has quit [Client Quit]
orhaneee has quit [Ping timeout: 256 seconds]
orhaneee_ has quit [Ping timeout: 256 seconds]
Andy-D has joined #linux-sunxi
lurchi__ is now known as lurchi_
Rafael1980 has joined #linux-sunxi
RichardG867 has quit [Ping timeout: 246 seconds]
matthias_bgg has joined #linux-sunxi
<catphish> technical question in case anyone happens to know: does the H3 have any DE clock configuration, or is it hardwired to use the "PLL-DE"?
f11f12 has quit [Quit: f11f12]
Perlovka_ has joined #linux-sunxi
Perlovka has quit [Ping timeout: 268 seconds]
Gerwin_J has joined #linux-sunxi
AneoX has quit [Ping timeout: 272 seconds]
AneoX has joined #linux-sunxi
paulliu has quit [Ping timeout: 240 seconds]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 250 seconds]
BroderTuck has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 250 seconds]
Andy-D has joined #linux-sunxi
chomwitt has joined #linux-sunxi
<miasma> btw, the mediawiki/php backend also seems quite old @ linux-sunxi.org. maybe it's even running the php version that will be deprecated soon?
AneoX has joined #linux-sunxi
Mandragor_ has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 246 seconds]
Mandragor has quit [Ping timeout: 246 seconds]
reinforce has quit [Quit: Leaving.]
RichardG867 has joined #linux-sunxi
RichardG867 has quit [Changing host]
RichardG867 has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 250 seconds]
AneoX_ has quit [Ping timeout: 244 seconds]
dddddd has joined #linux-sunxi
AneoX has joined #linux-sunxi
reinforce has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
tllim has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
f0xx has quit [Ping timeout: 245 seconds]
aalm has quit [Ping timeout: 246 seconds]
pgreco has quit [Ping timeout: 268 seconds]
msimpson has quit [Quit: Leaving]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 272 seconds]
IgorPec has quit [Ping timeout: 246 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 245 seconds]
IgorPec has joined #linux-sunxi
BenG83 has joined #linux-sunxi
qeed has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 250 seconds]
lurchi_ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
lurchi_ has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
m4ssi has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 250 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 268 seconds]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
matthias_bgg has quit [Quit: Leaving]
\\Mr_C\\ has quit [Ping timeout: 246 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 240 seconds]
Putti has joined #linux-sunxi
NeuroScr has quit [Ping timeout: 250 seconds]
NeuroScr has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
Andy-D has joined #linux-sunxi
Putti has quit [Ping timeout: 272 seconds]
\\Mr_C\\ has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 250 seconds]
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #linux-sunxi
anarsoul|2 has joined #linux-sunxi
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
drt1245 has quit [Quit: Page closed]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 245 seconds]
tnovotny has quit [Quit: Leaving]
drt1245 has joined #linux-sunxi
pgreco has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
tllim has quit [Quit: Leaving]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 245 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 244 seconds]
catphish has left #linux-sunxi ["Leaving"]
popolon has joined #linux-sunxi
catphish has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<catphish> it seems after spending the say on it, the H3 display is beyond my programming ability, but maybe i can achieve something with the A20 instead, which has properly documented DE and HDMI
<KotCzarny> why dont you steal uboot code?
<KotCzarny> or just let uboot setup framebuffer and reuse it?
<catphish> stealing the DE2 code is non trivial, it's not just a simple setup function and you're done, i tried to copy it but there's far more interdependent functions than i can get my head around
<catphish> i suspect i'll have more luck with the A20
<miasma> is there a reason why you want to reimplement from scratch?
<catphish> sort of
<catphish> i don't like u-boot handing over the hardware in a state i dont fully understand
<catphish> mostly a personal preference
<catphish> i'm after a SoC i can properly understand and implement a minimal functional OS, it's mostly for educational / entertainment purposes :)
<KotCzarny> some people play the video games
<KotCzarny> some play code games
<KotCzarny> :)
<KotCzarny> best puzzle imaginable, how to make that friggin' piece of s....ardware work
<catphish> it's a shame really that it's not easier
<catphish> but as discussed, good, cheap, pick one
<catphish> and honestly, these allwinners are both good and cheap, it's just the programming complexity :(
<catphish> not everyone wants their product to take 20 seconds to boot linux
<KotCzarny> i suspect underlying tech is just complicated in itself
<KotCzarny> designed by engineers, not programmers
<catphish> well that is of course true
<KotCzarny> and you have bare innards exposed
<catphish> well i'll attack the A20 and see if i get on better
<KotCzarny> but at least you have good linux-sunxi folks that at least did some working path for the reference
<miasma> catphish: i'm been able to boot uboot/linux/systemd in < 2 seconds
<KotCzarny> which i'm very grateful, really good to have opensourced boxes running around the house
<miasma> catphish: using h3
<KotCzarny> miasma: including uboot?
<miasma> yes, iirc
<KotCzarny> nice
<miasma> but i haven't tried falcon mode yet
<KotCzarny> afair plain kernel boot takes some time when you need usb and friends
<miasma> just a very stripped down uboot
<KotCzarny> but i guess you can hide it under with delayed module load
<KotCzarny> just to satisfy user senses
<miasma> KotCzarny: my kernel boots in 690 ms
<miasma> hdmi disabled, but it has usb
AneoX_ has joined #linux-sunxi
<miasma> KotCzarny: i also use lz4 compressed kernel since i couldn't figure out how to boot uncompressed kernel
AneoX has quit [Ping timeout: 250 seconds]
<KotCzarny> mhm, anyway, not bad. nite!
AneoX_ has quit [Ping timeout: 240 seconds]
AneoX has joined #linux-sunxi
drt1245 has quit [Quit: leaving]
apritzel has joined #linux-sunxi
drt1245 has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<catphish> miasma: that's impressive, my u-boot takes much longer than that :(
<catphish> when i try to strip down u-boot i just get compile errors, i figured u-boot sunxi doesn't handle dependencies very well
<catphish> but still, this is very much supposed to be a bare metal attempt
apritzel has quit [Ping timeout: 250 seconds]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 246 seconds]
aalm has joined #linux-sunxi
<drt1245> Having trouble with with X11 using the modesetting driver on a Banana Pi (A20). X11 crashes on startup when connected to 1080p TV. Xorg.0.log doesn't really give much info. If I set resolution to 1280x720 in xorg.conf, it will start. But X crashes if I change resolution to 1920x1080 using xrandr. Also works fine when connected to 1440x900 monitor (instead of TV).
Andy-D has quit [Ping timeout: 244 seconds]
Andy-D has joined #linux-sunxi
vagrantc has joined #linux-sunxi
apritzel has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]