<naobsd>
I have to try another method :( probably send '2' to UART is needed
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
gianMOD has quit [Read error: Connection reset by peer]
solarnetone has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<naobsd>
same result with '2' method :(
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
Eppie has joined #linux-sunxi
p_rossak has joined #linux-sunxi
<KotCzarny>
castrated to the point of no return?
<naobsd>
I can read sram and some registers area, so fel is working properly
<naobsd>
only DRAM area cannot be accessed :(
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
futabachannel has joined #linux-sunxi
premoboss has joined #linux-sunxi
nik has joined #linux-sunxi
nik has quit [Client Quit]
<wens>
naobsd: then dram init is not working
<naobsd>
wens: I don't know why :(
<naobsd>
send '1' to UART is not working (normal boot), I have no idea to init dram
gianMOD has quit [Remote host closed the connection]
<naobsd>
should I try mainline u-boot with spl (for another a33 board)...?
<naobsd>
or felix does better?
Net147 has quit [Quit: Quit]
jbrown has quit [Ping timeout: 250 seconds]
<ssvb>
naobsd: just reading DRAM will not do anything good for you, unless something reads the FEX file into it
<ssvb>
still the data is retained in the DRAM for a little bit, so you can boot the stock firmware on this device, then reset it and try to read DRAM
gianMOD has joined #linux-sunxi
<ssvb>
it might still contain the FEX data then
<ssvb>
the DRAM init code in the U-Boot SPL is supposed to be generic and should work on any A33, at least that's how noname tablets are handled
<ssvb>
you can try to reduce the DRAM clock speed if it happens to be unreliable
<ssvb>
and nobody has checked the reliability of DRAM on A33 in general, so I would not expect it to be entirely problem-free on tablets or any other supposedly supported devices
gianMOD has quit [Read error: No route to host]
jbrown has joined #linux-sunxi
<ssvb>
still, that's only a risk of a little bit of random corruption here and there, rather than the DRAM failing in a really obvious way
Putti has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<naobsd>
what I expect is, boot1 does something, then read dram via fel
<naobsd>
ssvb: DRAM can be read w/o boot0/1(i.e. FEL mode just after BROM)?
gianMOD has quit [Read error: No route to host]
<naobsd>
DRAM access hangs both 'press & hold RESET' / 'send 2 to UART' method :(
Eppie has quit [Ping timeout: 260 seconds]
mzki has joined #linux-sunxi
<ssvb>
DRAM is not initialized after entering FEL mode, it needs to be initialized explicitly
<naobsd>
oops, u-boot-sunxi nightly latest for a33 is not built... (err)
alexxei has quit [Ping timeout: 248 seconds]
<ssvb>
you can try to initialize DRAM by running "sunxi-fel spl u-boot-sunxi-with-spl.bin"
<ssvb>
then try to read from 0x43000000
<naobsd>
I see
<naobsd>
20160902 binary is enough new?
<ssvb>
yes, it should be good
<ssvb>
a binary from some generic A33 tablet
<ssvb>
if it does not deadlock and you can read/write something, then the DRAM is initialized properly
<ssvb>
one of the most interesting things to check is whether the interrupts from the perfomance counter unit can be supported properly on H5
<ssvb>
it's already nice to have a bugfixed revision of Cortex-A53 in H5
<ssvb>
IgorPec: thanks!
<ssvb>
NiteHawk: Can we push H5 support to the sunxi-tools git? Do you have an Orange Pi PC 2 board yourself?
<MoeIcenowy>
ssvb: have you tried returning back to FEL by mainline SPL?
<MoeIcenowy>
or have apritzel tried?
JohnDoe_71Rus has joined #linux-sunxi
<ssvb>
MoeIcenowy: apritzel has successfully booted Linux via FEL, so I guess that returning back to FEL works too
<MoeIcenowy>
ssvb: okay...
<MoeIcenowy>
I'm still waiting for jernej's de2 u-boot driver
<NiteHawk>
ssvb: unfortunately no. but i don't see anything that would prevent us from merging, the parts are are expected to work have all been checked by now, right?
<NiteHawk>
i only have the older H3-based Orange Pi PC (1)
<MoeIcenowy>
as A64's HDMI is proven to be like H3's and H5's is proven to be identical to A64's
<ssvb>
NiteHawk: I see that you removed the refactoring patch from the pull request for now, so let's merge it
<MoeIcenowy>
DE seems to be a little different
<NiteHawk>
"Pull request successfully merged and closed" :)
<MoeIcenowy>
congrats
<ssvb>
thanks!
<NiteHawk>
and MoeIcenowy successfully assimilated as sunxi-tools contributor ;)
<MoeIcenowy>
I used to push a patch that disable the fex ver error
<MoeIcenowy>
seems to be not merged
<MoeIcenowy>
I remembered sunxi-fexc used to check the "ver"
<MoeIcenowy>
but some new boards have ver = 100
<ssvb>
jemk, beeble, wens: could any of you have a look at the A80 support for uart0-helloworld in sunxi-tools? I don't have the hardware, and now I see that the MIDR based runtime detection check is likely wrong
<MoeIcenowy>
there's both A33 and R16 which is 0x1667
<MoeIcenowy>
on A33 tablets usually only uSD breakout is available as debugging UART
<MoeIcenowy>
but on R16 boards another UART0 can be used (at least for parrot)
<ssvb>
we can probably differentiate A33 and R16 via checking some SID bits (in the same way as A10s and A13)
<MoeIcenowy>
but someone here have reported that the UART connector on parrot is using UART0 @ PF
<MoeIcenowy>
(a.k.a. UART0 muxed with SDC0)
<ssvb>
as for the use of uSD breakout, the uart0-helloworld binary is checking the boot media
<MoeIcenowy>
and one of my A33 tablet also has UART pads (tagged RX and TX) with PF
<MoeIcenowy>
so the standard A33 debugging UART may be PF
<MoeIcenowy>
(my tablets' official boot0,u-boot also use PF as output)
<ssvb>
we could route UART to the uSD pins in the FEL boot case, and avoid doing this when booting from the SD card
<ssvb>
does this make sense to you?
* ssvb
does not have any A23/A33 hardware
<MoeIcenowy>
I have no parrots.
<MoeIcenowy>
so I cannot test UART0 @ PB
<MoeIcenowy>
and even on parrot the standard UART is @ PF (the PB uart is accessible on GPIO pinout, but the PF uart is available in connector tagged "UART")
<MoeIcenowy>
I have heard that Tina cannot even boot from SDCard
<naobsd>
is R16 SID needed?
<MoeIcenowy>
naobsd: if you can provide one
<MoeIcenowy>
but we need more than one to detect which bit is necessary
<majosa>
I'm reading H5 datasheet and comparing with the product brief released in the allwinner page and the datasheet forgets things that was supoused to be included like audio encoders
<MoeIcenowy>
my boards stucks before "HDMI connected"
<MoeIcenowy>
either with or without a cable
<jernej>
MoeIcenowy: Then some setting doesn't work together with CONFIG_VIDEO
<MoeIcenowy>
have you or other ones tested on opi one/lite?
<MoeIcenowy>
I tried orangepi_2_defconfig, cannot work too
alexxy[home] has joined #linux-sunxi
Eppie has quit [Ping timeout: 260 seconds]
<jernej>
MoeIcenowy: Yes, it was tested on 512 MiB RAM board too (check that armbian link, whole thread)
alexxy has quit [Ping timeout: 260 seconds]
afaerber has quit [Quit: Ex-Chat]
<jernej>
MoeIcenowy: Please try without VIDEO_SW_CURSOR, if you added it to defconfig
<MoeIcenowy>
tried, not work
<MoeIcenowy>
maybe my gcc is problematic?
<MoeIcenowy>
what's your gcc ver
leviathanch has joined #linux-sunxi
<jernej>
MoeIcenowy: Ok, I must go now, but later that day I can upload my u-boot and you can try it.
<jernej>
MoeIcenowy: Latest from Arch repo, so 6 something
<MoeIcenowy>
mine is 4.9
<jernej>
MoeIcenowy: Worth a try... Bye for now
<MoeIcenowy>
bye
jernej has quit [Quit: Page closed]
gianMOD has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
futabachannel has quit [Quit: Leaving...]
<MoeIcenowy>
jernej: if you read the log, please take care: my code died at sun8i_hdmi_hpd_detect
cnxsoft has quit [Ping timeout: 260 seconds]
cnxsoft1 is now known as cnxsoft
cnxsoft has quit [Quit: cnxsoft]
<MoeIcenowy>
then died at sun8i_hdmi_phy_init
alexxy[home] has quit [Quit: No Ping reply in 180 seconds.]
<naobsd>
well, 2 more R16 SID...useless?
alexxy has joined #linux-sunxi
<MoeIcenowy>
we mostly want one from another device :-(
<MoeIcenowy>
s/ :-(/ :-)/g
<NiteHawk>
but feel free to add them, of course :)
gianMOD has quit [Read error: No route to host]
<stachu>
Hi, how to enable 1GB ram on some A10s hdmi dongle? I use mainline u-boot with mk802_a10s_defconfig. Now it shows: DRAM: 512 MiB and I see on the pcb are 4 dies 2GB capacity each.
<tkaiser>
cyAndi: I thought CSI would be the missing piece. But I might be wrong. At least GR8 is more or less an A13 so in case you have code from Stone Age it should still run?
oliv3r_ has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<tkaiser>
jernej: thanks. This resolution stuff should now also work with mainline kernel and with A64 and H5 too?
<cyAndi>
tkaiser: I see, thanks
gianMOD has joined #linux-sunxi
Putti has joined #linux-sunxi
<jernej>
tkaiser: It seems that all newer SoCs, excluding A80 and A83T, has same HDMI controller. H5 has some additional setting, which is easy to fix
<jernej>
tkaiser: This U-Boot driver could be used on mainline kernel through simplefb
<jernej>
tkaiser: which is quick method to make display work while we are waiting on proper DRM driver
<jernej>
tkaiser: but everything learned here could be applied to DRM driver too. Actually, I found additional trick to more easily reuse HDMI driver already included in mainline kernel
<tkaiser>
jernej: That sounds pretty cool :)
Putti has quit [Ping timeout: 256 seconds]
<jernej>
tkaiser: Anyway, it is better to use J. F. Moine's DRM driver on Linux, if user has HD or HD ready screen
<tkaiser>
jernej: Ok, maybe I built 4.9 today with his driver included. But since I use only headless H3 and H2+ devices since a while... ;)
<jernej>
tkaiser: That's why I talked in general :)
petr has quit [Ping timeout: 260 seconds]
<beeble>
ssvb: no uart output on a80. even after disabling the detection path by setting soc_id directly to 0x1639 and fixing the missing pinmux. but haven't had any more time looking into it yet
<jernej>
tkaiser: If anyone request support non standard resolution, we can instruct user how to properly devise a patch and script.bin settings from debug output printed by this U-Boot driver
<MoeIcenowy>
jernej: when will you send out your patchset?
<jernej>
MoeIcenowy: After I clean it up.
<MoeIcenowy>
jernej: expect it!
<MoeIcenowy>
and do not forgot to reserve the extensibility to sun50i
<jernej>
Yeah, I know, that is also the part of the clean up.
<jernej>
I'll see how much time I will have in next days or weeks
<MoeIcenowy>
and after I got properly set up my toolchain, I will test to port your driver directly to sun50iw1 (A64)
petr has joined #linux-sunxi
<jernej>
MoeIcenowy: Be careful with HDMI clock settings (check limits for factors in sunxi_lcdc_pll_set())
<MoeIcenowy>
clock... a magical zone that I now do not dare to touch
matthias_bgg has quit [Quit: Leaving]
jstein_ has joined #linux-sunxi
<jernej>
MoeIcenowy: Don't be scared, just read every bit description. What is sometimes confusing is that some info could be misleading or not complete.
jstein_ is now known as jstein
<beeble>
ssvb: quick check against the manual, CCM base is different on A80, offset for uart0 gating too
<MoeIcenowy>
jernej: it's my toolchain's fault
<MoeIcenowy>
succeeded with linaro's gcc 6.1.1
<beeble>
ssvb: will try it with the other addresses later if i can finish my other work in time
<jernej>
MoeIcenowy: That still doesn't mean that code is ok. It might just work because of some side effect...
<MoeIcenowy>
jernej: you may review sun8i_hdmi_phy_init
<MoeIcenowy>
it's where I used to die
<jernej>
MoeIcenowy: Could you add some printf in between commands, just to see where it fails exactly? Probaby somewhere at the beginning
<MoeIcenowy>
yes
<MoeIcenowy>
I debugged in this way before :-(
<MoeIcenowy>
ohh too many tasks for myself: rebuild cross toolchain for my distro, debug u-boot, push mainline h2plus support
<jernej>
I can wait :)
IgorPec has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
<jernej>
tkaiser: You might just issued DDoS on Armbian with that comment on HaD :)
<MoeIcenowy>
jernej: what's the theory of hdmi_read_lock()?
<MoeIcenowy>
I find no lock
<MoeIcenowy>
only 4 reg writes
<jernej>
This is something from original BSP driver
<jernej>
We don't know exactly what it does, but it seems that it needs to be called before reading some register and lock it afterwards.
IgorPec has joined #linux-sunxi
<jernej>
You can put multiple reads in between.
<jernej>
This is still part of yet not well understood registers
<jemk>
jernej: it works perfectly well (in my tests) to unlock the registers once after reset and never lock them again, that makes it easier
<jemk>
ssvb: beeble: since a80 boots on A7 core reading MIDR won't help to differentiate i think.
leviathanch has quit [Remote host closed the connection]
<jernej>
jemk: That test was on my todo list. Thanks for confirming assumption.
<ssvb>
jemk: wens mentioned that it is possible to read the SoC ID from the BROM data area
afaerber has joined #linux-sunxi
my123 has quit [Ping timeout: 245 seconds]
andi_sp has quit [Quit: andi_sp]
<wens>
MIDR? MPIDR?
<ssvb>
beeble: thanks for trying it, too bad that A80 is so much different from anything else
<jemk>
jernej: and a single writel of the magic-word is ok too, no need to do it byte-wise
<jernej>
jemk: Maybe that's wrong with my U-Boot code. Or do you think it could be really a compiler issue (if you read today's backlog)
<jernej>
?
<jemk>
jernej: no idea, bytewise should work too, its what aw does
<jernej>
jemk: ok, then I will try to reproduce it and check assembly
<beeble>
whats about 0x00800024 on !a80 platforms? at least a look into to manuals showed it's not used, but i don't have a board available right now to test it
chomwitt has joined #linux-sunxi
<jernej>
MoeIcenowy: Can you please upload sun8i_display.o compiled with the older driver? I would like to check assembly to see what is different
Putti has joined #linux-sunxi
<jernej>
I mean older gcc
<MoeIcenowy>
jernej: should I delete my bonus printf's?
<jernej>
no need
<jemk>
ssvb: i don't have the a80 board here at the moment, but if nobody else did it till then i might check next week
<tkaiser>
mhlavink: nobody knows since those morons do not test the interesting things (GbE performance and SATA performance). They simply don't know what they're doing.
<MoeIcenowy>
I think at least allwinner will provide a new SoC
<MoeIcenowy>
not a quad-core A20
<tkaiser>
MoeIcenowy: ?
<MoeIcenowy>
I remembered the pin number of R40 is not equal to A10/20
<tkaiser>
I thought it's the one nove spotted a few months back? Was called A20E back then
<MoeIcenowy>
oh finally got a sdio card to be recognized on opi0
<MoeIcenowy>
tomorrow I will try to port xradio driver to mainline
<tkaiser>
MoeIcenowy: You ran into troubles accessing an SD card?
<buZz>
wasnt allwinner promissing a quadcore pincompatible A20 followup?
<MoeIcenowy>
tkaiser: not a SD card.
<tkaiser>
Ah
<MoeIcenowy>
I mean the "XR819" sdio card
<MoeIcenowy>
it uses a gpio-controlled fixed regulator to provide its voltage and a gpio to enable it
<tkaiser>
buZz: Allwinner didn't promise anything, Tsvetan from Olimex spread rumours back in July 2015
<buZz>
ahhhh
* buZz
shakes fist
<buZz>
:)
* buZz
having way too much fun with this R8 board
<MoeIcenowy>
pushed 3 patches about H2+ support in mainline
<MoeIcenowy>
and one patch is pending on my hdd (for lack of both mainline H2+ dt and xradio driver
<buZz>
did you see, their (nextthing's) image now has version: r6p0-01rel0-0581113
<buZz>
of mali binary
<buZz>
i think the first r6 in the wild?
<MoeIcenowy>
buZz: first mali 400 r6
<MoeIcenowy>
first r6 is Linaro HiKey's, but for mali450
<MoeIcenowy>
good job the allwinner xradio driver is GPLed
<buZz>
ah ok, cool
<MoeIcenowy>
I even run the NTC mali blob on my A33 tablet
<MoeIcenowy>
everything is OK except one bug exists in xf86-video-armsoc fork and sun4i-drm driver
<buZz>
NTC's image lacks DRM support completely atm :(
<buZz>
can only do gles on fbdev
<buZz>
which sux
<MoeIcenowy>
ok now time for me to go bed
<MoeIcenowy>
tomorrow I will try to port xradio
<buZz>
sleep tight
<MoeIcenowy>
opi0 is a good board, compared with nano pi neo, it have onboard wifi and spi-flash-capable
<tkaiser>
MoeIcenowy: And faster than RPi 3!! ;)
<MoeIcenowy>
tkaiser: R U JOKING
cptG has joined #linux-sunxi
<tkaiser>
MoeIcenowy: All the time. But according to RPi foundation's own methods, OPi Zero is faster (they use sysbench to demonstrate the performance of the various RPi generations and this tool pretty much sucks)
<buZz>
well, armv6 also sucks
<buZz>
so that matches
<buZz>
:)
<deskwizard>
hehe :)
cptG_ has quit [Ping timeout: 250 seconds]
<buZz>
hi weskdizard \o
<buZz>
one day i'll stop doing my compiles natively ;(
<deskwizard>
lol ZzUb :P o/
<buZz>
whats the point of a deskxeon if you keep compiling on the armboard itself :P
<miasma>
ew
<miasma>
it's not hard to set up cross compilers
<buZz>
i know
<buZz>
just .. lazy
<miasma>
i started with rpi so i had no choice :D dunno, 4-5 hours for kernel compilation?
<buZz>
why no choice?
<MoeIcenowy>
my first ARM development device is... Huawei Ideos X5 mobile phone :-(
<buZz>
my first arm sbc was a IGEPv2
<buZz>
i love all the omaps
<deskwizard>
mine was fkin Meson3, never again.
<miasma>
buZz: you don't want to compile all day long if it takes one minute on desktop :)
<buZz>
TI should just buy allwinner and continue the omap line further :P
<MoeIcenowy>
buZz: I love omaps too
<buZz>
erryone loves omaps
<MoeIcenowy>
I still keeps a omap3-n900 mobile phone
<buZz>
MoeIcenowy: did you preorder the hipster omap5 laptop? :P
<MoeIcenowy>
the only games I ever tried to play with allwinner devices are three: Nethack, Pingus and a traditional Chinese game "Legend of Jinyong novels"
<MoeIcenowy>
Pingus runs so well on my iNet D978 Rev02 unbranded A33 tablet, until I broke its touch panel :-(
<buZz>
well
<KotCzarny>
MoeIcenowy: i love tetris and match3 (jewels)
<buZz>
pcsx_rearmed runs like a -dream- on allwinner R8
<MoeIcenowy>
someone can make a list of gaming on Allwinner chips (or other low-performance ARMv7/8 SoCs) with or without 3D blobs
<MoeIcenowy>
it's said that with the 3D blob it's even possible to run a full Minecraft (via GL4ES) (although I think it will be a disaster on Cortex-A7)
IgorPec has joined #linux-sunxi
<buZz>
it works on armv6 , so doubt a7 would have issues with it
<buZz>
although i dont consider minecraft to be in any way a hard game to run
<KotCzarny>
hacking that nes classic would provide pretty nice gaming rig
<MoeIcenowy>
not mcpi
<KotCzarny>
ie. controller and everything is ready
<MoeIcenowy>
In fact I wonder whether we can attach a NES Classic gamepad to an ordinary aw deivce with I2C
<MoeIcenowy>
or even to any device with USB to I2C
<KotCzarny>
it has also pretty case :P
massi has quit [Remote host closed the connection]
<buZz>
seems there are some i2c joystick drivers in liux
<KotCzarny>
offtopic, anything nice going on for chinese black friday?
<buZz>
well, bought that 8bitdo for it ;)
<buZz>
25 euro , vs 49 euro it would cost me from germany
apritzel has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
<KotCzarny>
5usd off opi+2e on ali orange's store
gianMOD has joined #linux-sunxi
<KotCzarny>
well, 6usd
<KotCzarny>
29usd + 4usd shipping
<KotCzarny>
not a bad price for 2GB/4core/16GB/wifi/eth/3+1usb box
<KotCzarny>
*board
JohnDoe_71Rus has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
gianMOD has quit [Remote host closed the connection]
afaerber has quit [Quit: Ex-Chat]
IgorPec has quit [Ping timeout: 246 seconds]
my123 has quit [Ping timeout: 252 seconds]
my123 has joined #linux-sunxi
my123 has quit [Changing host]
my123 has joined #linux-sunxi
<willmore>
I've finished reading scrollback! I'm realtime again! All that H2+ and H5 hacking took forever to read. Great work, everyone! I ordered boards because of it.
<KotCzarny>
well, h2+ is really h3-lite
<willmore>
I noticed that.
<willmore>
and the H5 is a H3/A64 mashup.
<KotCzarny>
and h5 is wtf
<willmore>
LOL
<willmore>
Oh, yeah, the nintindo thingy happened, too. That was some good reading.
<willmore>
I'll have an Opi0 and an OpiPC2 here shortly. So, that'll be fun.
<willmore>
Oh, and I ordered a bunch of 16Mb SPI NOR flash.
<tkaiser>
willmore: the WiFi on Opi Zero looks quite capable, already wonder how many people will build out of this thingie and a step-down converter cheap PoE powered access points
<willmore>
tkaiser, I have no PoE gear or I'd stick on a little one and try it.
<willmore>
Oh, and tkaiser keep trolling that comment thread. I was impressed with how many people replies with "WTF, have you never heard of linux-sunxi and/or armbian?"
<tkaiser>
willmore: Passive PoE rulez. Cheap, power efficient and also good chances to fry devices
<willmore>
LOL
<willmore>
I have a bunch of little DC stepdown boards, so that part's no big deal.
<willmore>
I really love to see that they're putting a little NOR SPI flash chip (or at least pads) on these boards.
<willmore>
It's quite exciting to think of how much pain that could remove from supporting little SBCs like these.
<tkaiser>
willmore: I hope Xunlong can be convinced to solder SPI flash also on OPi Zero. As an option only it's not that great
<willmore>
agreed, but at least they put the pads on the 0 so that those of us who want to get the software environment set up can do testing. Once it can be demonstrated how useful it is, I think they can be convinced.
<willmore>
What was the comment? a 16Mb SPI NOR chip in volume is $0.04. They can afford that. As long as the value of that part can be shown.
<willmore>
Does uboot have a scripting language in it? It would make sense to leverage all that code to make the boot/configuration UI. I don't want to call it a BIOS as most of what the BIOS did was provide a kind of HAL/toolkit for other software.
<KotCzarny>
a bit
<willmore>
If it has conditionals, looping, and some simple console I/O, that's enough.
<KotCzarny>
dont know about looping, if/else/endif is there
petr has quit [Ping timeout: 244 seconds]
<ssvb>
willmore: Nowadays U-Boot provides UEFI API and can run UEFI applications. For example, Grub2 is an UEFI application. You can ask agraf for more details.
petr has joined #linux-sunxi
<ssvb>
I'm referring to the soon-to-be-implemented boot/configuration UI as "something like a PC BIOS setup" because it's probably familiar to many people and this way they can understand why it is useful :-)
<majosa>
Has uboot usb hid implementation?
<ssvb>
yes
<ssvb>
USB keyboards are supported in U-Boot on Allwinner devices, and you can type commands in the U-Boot command line prompt
agraf has quit [Ping timeout: 252 seconds]
agraf has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<KotCzarny>
ssvb: graphical? 3d?
<KotCzarny>
now we know what we need mali for!
<KotCzarny>
some pc bios do those setups pretty eyecandish ;)
<ssvb>
3D is surely not necessary
<ssvb>
as for the GUI toolkits (Qt and friends), not much can fit into the available space in SPI NOR
<KotCzarny>
ssvb, ever seen those 64kB compos? ;)
<KotCzarny>
even 4kB ?
<majosa>
Is there any status page of UEFI implementation in uboot?
<ssvb>
well, how much time do they spend developing and polishing them?
<KotCzarny>
life, i guess
<ssvb>
majosa: you can check the U-Boot documentation and sources
<KotCzarny>
but possible fame? group name being in every armbios ?
<KotCzarny>
otoh, i wonder if there are demo groups specializing in arm machines
<ssvb>
we are somewhat lucky to have 16Mbit (2Mbyte) of SPI NOR size in Orange Pi PC 2
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-7017-g48dacdb, build type: debug, sources date: 20160102, built on: 2016-11-10 06:12:27 UTC git-7017-g48dacdb http://www.kvirc.net/]
<KotCzarny>
ssvb: as you've said, it might be temporary 'better price for 2MB chips'
<ssvb>
if it turns out that 2MB is actually necessary for some advanced features, then it may be set as a requirement
<ssvb>
in fact something like this has happened with routers
<KotCzarny>
thinking of running os from rom?
<ssvb>
first revisions tend to have more on-board flash, but later revisions optimize the cost by reducing it to the very minimum
<KotCzarny>
ahm.
<ssvb>
a kickass feature would be to support downloading an OS image from the Internet and installing it on a blank SD card
<ssvb>
this way the user may be completely dumb, but still manage to get the system up and running by simply following the on-screen instructions :-)
Andy-D has quit [Ping timeout: 250 seconds]
<ssvb>
it's hard to estimate the exact size requirements now
<KotCzarny>
but that requires stable distro that wont go away in a 5 years etc
<ssvb>
yes
<KotCzarny>
not to mention bandwidth
<KotCzarny>
though that could be done via mirroring
reinforce has quit [Quit: Leaving.]
<NiteHawk>
reminds me of etherboot project (PXE-related), iirc they can download images via http :)
<beeble>
seeing 8mbit as minimum will come more common soon
<beeble>
a lot of 4mbit devices are EOLed now
<apritzel>
doesn't U-Boot provide an API for bare-metal apps?
<apritzel>
either we use that for the setup application
<apritzel>
or make it an UEFI app
<beeble>
with 8mbit you get at least a uboot with ethernet, usb, fastboot, scripting, fit
<beeble>
last time i checked
<apritzel>
also those 128 MBit (=16MB) chips seems to be somewhat cheap, as they were/are heavily used in PC BIOSes
<beeble>
mmc of course too
<apritzel>
beeble: for this 4Mbit would be sufficient today
<apritzel>
so there is some room with 8MBit
<beeble>
we run into some problems with 4mbit and all the features i mentioned. could have been improved, but with default settings it was a little bit over 4mbit
<apritzel>
the build I have there are somewhat like 450KB, including all U-Boot bling
<apritzel>
beeble: yeah, possibly, but fortunately 8Mbit seems to be the minimum people are talking about these days
Andy-D has joined #linux-sunxi
<apritzel>
I checked yesterday, typical UEFI variable storage seems to be 64KB
<beeble>
as i said, 4mbit is getting harder to source anyway. so pretty much no price difference now
<apritzel>
so that doesn't break the bank either
yann-kaelig has quit [Quit: Leaving]
<beeble>
ah and don't forget some some storage for uboot env either
<beeble>
you want to be able to saveenv
<beeble>
(not a fan of uboot env in emmc text files)
<apritzel>
beeble: but that wouldn't be much, more like 1-4 KB?
<beeble>
depends on the insanities you are planning :)
<beeble>
but yes quite small
<apritzel>
btw: I managed to put U-Boot SPL + ATF + U-Boot proper + kernel + initrd on a 128 MBit SPI NOR flash
<beeble>
but you have to reserve at least one erase page
<apritzel>
so could boot completely from there, on the Pine64
<beeble>
so its depending on the nor type
<beeble>
we do that on a31 with spi boot in the minimal version
<apritzel>
beeble: how much space is ther?
<apritzel>
e
<beeble>
sorry didn't finished to read your line
<beeble>
stopped after u-boot :)
<beeble>
minimal was 4mbi, its 8mbit now
<beeble>
and we put spl, uboot and env there
<apritzel>
anyway, 8 MBit seems to be good enough for now, even if we have a fancy U-Boot (with USB gadget stuff like fastboot or mass storage)
<apritzel>
and some tailored setup application
<beeble>
yes, 8mbit is good enough with some space to spare
<beeble>
even had full secure boot in 4mbit in the past (on another platform)
<NiteHawk>
i'll just push it to master without jumping through the PR hoop :)
<ssvb>
apritzel: 4Mbit is needed just for U-Boot + ATF alone, and it even may exceed this size in the future
<ssvb>
then we have the UEFI app, which may need some fancy features
<ssvb>
having 16Mbit is definitely better than 8Mbit right now, and we may adjust the requirements later
alexxei has quit [Read error: Connection reset by peer]
<apritzel>
sure
<ssvb>
just asking too much could have resulted in this feature not being implemented at all
<apritzel>
does Ethernet work in U-Boot on some GBit H3 OrangePi?
<ssvb>
but we got 16Mbit and it's very nice
<beeble>
just make it that the default config uses a bit more then 8mbit, than the board vendors who don't want to put any software efforts into it will have put a 16mbit on it anyway :)
<apritzel>
beeble: that's a plan
<ssvb>
beeble: btw, are you saying that you already have an A31 board with SPI NOR flash?
<ssvb>
I thought that the Orange Pi PC 2 was the first
<KotCzarny>
im afraid of those vendor bioses..
<KotCzarny>
secure, locked and boot order changed to boot to spi first
<beeble>
but we are in a different market with that kind of board. most tinkers are more interested in SBCs then SoMs
<beeble>
ssvb: thanks, we are trying to improve on that
<KotCzarny>
oooh, cheap, community enhanced board from eu based location?
<beeble>
depends on your definition of cheap. we are cheaper then competitive boards, but more expensive than a raspi for example can be. makes no sense for us to get into that market
<beeble>
but if you want to build your own device with just a simple baseboard device we are a good fit
<beeble>
-1x device
<beeble>
but about that keeping it hidden. today we announced our new module. probably not the right channel to promote that since it will feature a rk3399
<KotCzarny>
i just need 5-10usd device with 2 (or more) native sata ports and 2 eth ports
<KotCzarny>
ok. make it 10-20 usd ;)
<beeble>
then you will have to go with marvell. don't know anyone else who would have that peripheral mix
<KotCzarny>
yeah, but marvel is much more expensive, and rightly so
<beeble>
but could not tell you a cpu partnumber
<beeble>
also having two ethernet will drive you above 20 usd
<KotCzarny>
well, r40 is said to have 2 eth ports that could be driven independently
<beeble>
but that one has only 1 sata right?
<beeble>
sata port multipliers are not fun :)
<KotCzarny>
:)
<KotCzarny>
that espressobin board was interesting, but ~62usd, though its much better than bpi-r1 i've got for a bit more (when i knew nothing about allwinner)
<beeble>
a 3 port ethernet switch can be quite cheap (for the right definition of cheap)
<KotCzarny>
there must be one separated port
<beeble>
so if you can live with only a single uplink that could be a solution
<apritzel>
beeble: the RK3399 sounds nice, is it available now?
<beeble>
vlan tagging would solve that
<apritzel>
RK kept talking about for quite a while now ...
<KotCzarny>
beeble, only if you can make it persistent
<beeble>
KotCzarny: switch come up in ports off mode and you have to configure it first. with the right bootstrap settings
<beeble>
if you don't want to configure it via mdio you can put an eeprom with static configuration on
<beeble>
apritzel: i have a eval board and i got the mass market notification
IgorPec has quit [Ping timeout: 240 seconds]
<beeble>
apritzel: the a72 is blazing fast
<apritzel>
beeble: you bet ;-)
<apritzel>
reportedly FP has been improved much (not sure you care, though)
* willmore
just got a new phone with some A72s in it. Yes, well faster than the A53s in the old phone.
<apritzel>
beeble: the SoC has 4 PCIe lanes, right?
<beeble>
we can outperform helix2 in a lot of cases with only two cores
<beeble>
apritzel: yes
* apritzel
still waits for a cheap board with GICv3 and ITS ;-)
<beeble>
it seems that i'm not that fast in pushing the layout out then my chinese friends (that always have a little bit of a headstart too)
<beeble>
still not sure what they plan to do with the second m0
<beeble>
i have some ideas for it but they don't have anything running on it yet
<beeble>
with our own offloading m0 on the board, we will have a total of 3 M0s :)
<beeble>
9 core cpu!
<apritzel>
beeble: I see a bright future for you in the marketing department ;-)
<apritzel>
beeble: but you forgot the GPU cores !1111!!11
<beeble>
oh right!
<apritzel>
but with that extra on-board M0 you woul
<apritzel>
will be leading the market
<beeble>
haha, will tell that apm next time. they can forget their 32 cores
<willmore>
Don't corrupt beeble.
<beeble>
the extra m0 is a nice gimmick even if we use it quite useful i think
<beeble>
it acts as a fan controller, battery backuped rtc and CAN controller
<beeble>
and it's programmable via usb and i2c
<beeble>
ah and you can debug it via swd on the allwinner
<beeble>
thanks to openocd
<willmore>
What brand of M0 do you use, beeble?
<beeble>
stm32
<beeble>
f072 to be exact
<willmore>
Ahh, okay. I have some of their M3 based chips. They seem quite nice. I've been out of uC development for a bit and I was last using PIC16F parts. Much nicer to have an ARM core instead. But the Microchip peripherials were very nice.
Mr__Anderson has joined #linux-sunxi
<beeble>
the stm32 family is nice because they have such a wide variety of parts with compatible peripherals, useable libs and sometimes even pin compatible
<beeble>
and having a full gcc toolchain is a killer argument for development
<willmore>
That's much like the PIC families, then.
<willmore>
Yep.
<willmore>
Though I programmed in assembly. But, I'm older and don't have time for that anymore. :)
<beeble>
i don't like the microchip ecosystem that much. but they do have nice parts
<willmore>
I didn't use any of their software. I was using all OSS tools on Linux and a programmer I built myself.
<beeble>
i did that to on with the 16f family. but that was a long time ago
<willmore>
Every time I try to use their software I get frustrated and give up and go back to vi. :)
<apritzel>
beeble: do you know if people are still using the ARM compiler?
<beeble>
now i'm spoiled
<willmore>
beeble, agreed.
<beeble>
apritzel: your keil stuff seems still to be around in a lot of companies
<willmore>
I do mean to get back into assembly and I intend to do it on AARCH64.
<beeble>
apritzel: and i still have to keep a machine running that has is license bind to some IAR version that is able to compile some special code we get from a customer
<beeble>
*its
<beeble>
ah and thinking about numbers of cores on the boards
<beeble>
i can increase the total number of cores on the a80 board with the attiny i had to put on there to workaround their faulty BROM
<apritzel>
beeble: I was just curious, personally I can hardly imagine why one wouldn't use GCC
<beeble>
there is no sane reason not to switch to gcc
<apritzel>
beeble: I was thinking so, but apparently people still keep paying for that ...
<beeble>
thinking about how aweful our development cycle would be on our m0 only products
<beeble>
pushing code via git into gerrit, tiggering jenkins build that test it on devices is helping a lot to avoid regressions
gianMOD has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
mzki has quit [Ping timeout: 244 seconds]
Putti has quit [Ping timeout: 244 seconds]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
dh1tw has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dh1tw has joined #linux-sunxi
<apritzel>
MoeIcenowy: ssvb: H5 update: Ethernet works, we have to set PD6 as a high GPIO, as one the H3 OrangePis with GBit
<apritzel>
I couldn't find how this is supposed to be done in U-Boot, so I did it in ATF
gianMOD has quit [Remote host closed the connection]
<apritzel>
tftpboot worked fine, SD card as well, Ethernet in Linux works as well (just apt-getting)
<naobsd>
about NES classic, it should be able to get DRAM param and script.bin now(not yet tried),
<naobsd>
but I heard that it's not enough for A33/R16, something in firmware image or on shell on running device is required.
<naobsd>
what's 'something' for A33/R16?
<naobsd>
MoeIcenowy: could you tell me detail about it?
Mr__Anderson has quit [Quit: Leaving.]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]