<hanetzer>
anyone here with experience on kexec on arm64?
Kamilion has quit [Ping timeout: 240 seconds]
Kamilion has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
jbrown has quit [Ping timeout: 258 seconds]
shfil has quit [Quit: Connection closed for inactivity]
jbrown has joined #linux-sunxi
<suprothunderbolt>
sun my efforts so far to get my DSI panel working have not been successful. Anyone got DSI working okay? I'm using the amarula (Jagan Teki) patches and I'm getting "vblank wait timed out"
<suprothunderbolt>
s/sun//
<suprothunderbolt>
anarsoul, do you know if your patches and Jagan's are different / both work?
victhor has quit [Ping timeout: 252 seconds]
jstefanop has quit [Remote host closed the connection]
<lavamind>
I find it odd that it fails at exactly the 50% mark though
<lavamind>
I fixed the libmtd seek error by compiling with -D_FILE_OFFSET_BITS=64
<hanetzer>
hrm... no joy
jstefanop has quit [Ping timeout: 252 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
megi has quit [Ping timeout: 255 seconds]
NeuroScr has quit [Quit: NeuroScr]
<hramrach>
runtux: so pick it off the wiki and send it ;-)
<hramrach>
there is wiki edit history so you can find who wrote it originally
<anarsoul>
suprothunderbolt: use Jagan's patches for DSI
<suprothunderbolt>
okay, thanks.
<suprothunderbolt>
I'm attempting to use DSI-v9 from his github
<suprothunderbolt>
not sure if my panel driver code is the problem, my PCB design or the DSI code :)
<suprothunderbolt>
anarsoul, if you've got any advice on where to start debugging that I'd love to hear :) Most discussions seem to focus on PPL clock issues and my panel says it wants a 47000 clock.
<anarsoul>
suprothunderbolt: compare dsi and tcon regs with bsp kernel, address the differences
<suprothunderbolt>
okay, thanks.
lurchi__ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
lurchi_ is now known as lurchi__
GrimKriegor has quit [Read error: Connection reset by peer]
Wizzup has quit [Ping timeout: 244 seconds]
Wizzup has joined #linux-sunxi
jstefanop has joined #linux-sunxi
Wizzup has quit [Ping timeout: 255 seconds]
TheSeven has quit [Ping timeout: 252 seconds]
TheSeven has joined #linux-sunxi
jstefanop has quit [Ping timeout: 246 seconds]
Wizzup has joined #linux-sunxi
dddddd has quit [Quit: Hasta otra..]
<suprothunderbolt>
i haven't actually tried running using the BSP kernel. Any major downsides?
agraf_ has joined #linux-sunxi
agraf has quit [Ping timeout: 250 seconds]
agraf_ is now known as agraf
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
lurchi__ has quit [Quit: Konversation terminated!]
vagrantc has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 252 seconds]
<wens>
argh, systemd-shim package is dead :/
GrimKriegor has joined #linux-sunxi
GrimKriegor has quit [Changing host]
GrimKriegor has joined #linux-sunxi
lurchi_ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
AneoX has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
AneoX_ has quit [Ping timeout: 250 seconds]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 252 seconds]
selfbg has joined #linux-sunxi
NeuroScr has joined #linux-sunxi
lurchi__ has quit [Quit: Konversation terminated!]
<lavamind>
not sure if that's because of the -D_FILE_OFFSET_BITS=64 mtd-utils compilation flags... :/
lurchi_ has joined #linux-sunxi
cch has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 252 seconds]
airwind has joined #linux-sunxi
<suprothunderbolt>
attempting to build a BSP image so I can see if the panel works there, but now I need to work out how to setup a panel with the BSP...
cch has quit [Ping timeout: 250 seconds]
cch has joined #linux-sunxi
<cch>
curlybracket: I only have a few H3 boards in hand, OrangePi One, Nano Pi Core, RerVision H3 DVK board. Which A64 boards do you suggest for testing ?
<suprothunderbolt>
sopine is nice because it's got a lot of pins exposed
<suprothunderbolt>
everything should be in SOM format... :)
f0xx has joined #linux-sunxi
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 255 seconds]
Putti has joined #linux-sunxi
reinforce has joined #linux-sunxi
mknawabi has quit [Remote host closed the connection]
Putti has quit [Ping timeout: 268 seconds]
cch has quit [Ping timeout: 255 seconds]
chomwitt has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
<suprothunderbolt>
Still attempting to get DSI working, not sure what should come up on what pin during boot but I can't see any signals on the clock pins
nuuuciano has quit [Ping timeout: 255 seconds]
TheSeven has joined #linux-sunxi
GrimKriegor has quit [Ping timeout: 264 seconds]
clemens3_ has joined #linux-sunxi
shfil has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
clemens3_ has quit [Ping timeout: 252 seconds]
GrimKriegor has joined #linux-sunxi
GrimKriegor has quit [Changing host]
GrimKriegor has joined #linux-sunxi
cmeerw has joined #linux-sunxi
steev has quit [Read error: Connection reset by peer]
<bbrezillon>
lavamind: I did not try with ubiformat
<bbrezillon>
I just used flash_erase+ubi_attach (which is bad :))
<bbrezillon>
lavamind: "ubi0 error: ubi_compare_lebs: unsupported on-flash UBI format"
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 264 seconds]
<bbrezillon>
lavamind: problems with the seqnums
<bbrezillon>
I'd say the flash is not correctly erased
<bbrezillon>
and yes, the erase error at block 1023 is odd
cch has joined #linux-sunxi
megi has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
paulliu has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 252 seconds]
tnovotny has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<libv>
just commit fex file prs as is really was not option.
* libv
continues drudging through them
fkluknav has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
yann has quit [Ping timeout: 264 seconds]
t3st3rV2 has quit [Ping timeout: 256 seconds]
t3st3rV2 has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
<KotCzarny>
lol @ matrix annoucement
<libv>
it happens
<libv>
the private messages thing is a bit stupid
<KotCzarny>
yeah, adding layers often adds bugs, not security
<libv>
but there seems to have been 2.5 months between the cves and the breach being detected
<KotCzarny>
unless one wrote some script to check all cvs and compere against software he/she is using..
<libv>
i have no idea how big the matrix organization is
\\Mr_C\\ has joined #linux-sunxi
\\Mr_C\\ has quit [Excess Flood]
\\Mr_C\\ has joined #linux-sunxi
<libv>
meh, 9 files are utf-8
<libv>
i'm first going to continue with prs
<libv>
of course mixtile loft-q turns out to be a mess as well.
disik has joined #linux-sunxi
<runtux>
@hramrach: Yes I thought to submit it and already found out who did the wiki change unfortunately the wiki doesn't allow me to contact the person directly.
<libv>
that's indeed just stupid
<libv>
runtux: irc to the rescue
<libv>
runtux: Mirko Vogt affiliated to openwrt
<libv>
Mirko Vogt <mirko-dev@nanl.de>
<fALSO>
YO
shfil has quit [Quit: Connection closed for inactivity]
Rafael1980 has joined #linux-sunxi
victhor has joined #linux-sunxi
<wens>
anarsoul: I can't remember if I got mali-450 to run correctly with mali r7p0 blobs :/
<MoeIcenowy>
mripard: how could we deal with 2 sensors on 1 csi bus situation?
<MoeIcenowy>
(I think when 1 sensor is working another is forced to reset/powerdown state
<MoeIcenowy>
On many Allwinnner tablets, the front/rear camera is such a situation
Andy-D has joined #linux-sunxi
<KotCzarny>
i havent had a phone/tablet which had simultaneous front and rear recording
<libv>
MoeIcenowy: are there not gpios for reset used on like the bananapi m1 with its camera interface?
<libv>
MoeIcenowy: i have 2 official bpi cameras here as a run-up to fosdem hdmi input, so i know that these things are ready made
<libv>
and the schematic is available
<KotCzarny>
although i suspect in-car cameras do that
<MoeIcenowy>
KotCzarny: BTW the car recorder reference design of V3s uses a MIPI CSI camera and a USB UVC camera
<MoeIcenowy>
to reach simultaneous recording
<KotCzarny>
hmm
<KotCzarny>
then you have an answer i guess
<MoeIcenowy>
but what I want to do now is to support front/rear camera switching on PineTab
<wens>
libv: they use the same sensor with the same i2c address lol
<wens>
MoeIcenowy: is it the same situation?
<MoeIcenowy>
wens: no
<MoeIcenowy>
they're different model
<MoeIcenowy>
PT front cam is GC2145
<wens>
well that's better
<MoeIcenowy>
rear is OV5640
<KotCzarny>
MoeIcenowy: but do they have same i2c address?
<MoeIcenowy>
I think they have different
<libv>
usually an i2c address can be altered by pulling 1-2 pins up/down
<wens>
MoeIcenowy: then you'd simply have two remote endpoints from the CSI. Easy :)
<MoeIcenowy>
wens: but they're sharing the bus
<wens>
libv: nope, they didn't design that in
<MoeIcenowy>
and cannot work concurrently
<libv>
wens: of course :(
<MoeIcenowy>
ov5640 is a very clssical sensor
<wens>
MoeIcenowy: neither will media-bus allow you to use them concurrently
<MoeIcenowy>
its datasheet may be easy to find
<wens>
MoeIcenowy: IIUC you first use media-ctl to configure the endpoints and connection
<wens>
MoeIcenowy: then you capture from the active camera
<MoeIcenowy>
let me try single 5640 case first
<wens>
single case works. no worries there
<MoeIcenowy>
we have now even no usable driver for gc2145 in mainline
<MoeIcenowy>
and I don't think I need to use PineTab to selfie ;-)
<wens>
we have no drivers for gc*, period
<wens>
I was trying to port a gc20?? driver from some rockchip chromium tree to mainline.. didn't get very far
<wens>
(the sensor used on orangepi cameras)
<MoeIcenowy>
it's 2035
<wens>
right. anyway the driver used soc_camera, and no subdevice support, meaning I had to rip out a whole lot of code and try to replace it :(
<MoeIcenowy>
to be honest, I hadn't known GalaxyCore until entered Allwinner zone ;-)
<wens>
cheap stuff I suppose
<MoeIcenowy>
and Chinese stuff ;-)
<wens>
high end phones seem to like to use Sony sensors
<MoeIcenowy>
the HQ is said to be at Shanghai
<MoeIcenowy>
and low end ones seem to use OV
<wens>
OV seems popular, though their product range is very broad, with replacement models everywhere :/
<wens>
really hard to find drivers for very old or very new ones
<libv>
i have not looked into this yet, figured i would cross that bridge when i reach it
<libv>
but do we have csi0 for a20 upstream already, or is someone working on it?
<libv>
it seems from the conversation here that that might be the case already
<wens>
libv: there's a series (might be up to v5) from mripard
<MoeIcenowy>
WTF?!
<MoeIcenowy>
the two sensors have their address conflicted?
<wens>
congrats lol
<KotCzarny>
:)
<KotCzarny>
so, same i2c address?
<wens>
afaik some of the GC sensors have a register which you can use to program another I2C address
<wens>
haven't tried it though
<libv>
ok, cool, then i have a good basis for adding csi1 and seeing how that pans out and whether the 8bit bussed bpi cameras work with csi1 as well (for that the docs are not 100% consistent)
<libv>
wens: thanks
<wens>
libv: AFAIK csi1 is a trimmed down version of csi0, without the extra channels
<libv>
wens: csi1 allows for a full 24rgb bus
<MoeIcenowy>
good game
<MoeIcenowy>
both sensors use 0x3c
<libv>
so we will use that for hdmi input
<MoeIcenowy>
oops
<libv>
MoeIcenowy: play with gpios and reset lines.
<MoeIcenowy>
libv: yes
<MoeIcenowy>
it's the only way
<libv>
wens: but we might just get away with a single 8bit bus for ccir656
<libv>
which allows for a gradual path to getting csi1 up and running
<libv>
if it works
<wens>
libv: right, looks like it's called YUV444{R,G,B} in the CSI1 register defs.
<wens>
libv: same value is used for YUV422 16bit data bus for CSI0 WTF
<libv>
having both a freshly developed hdmi input board _and_ a previously untested soc block, that's just going to lead to trouble
<libv>
wens: it all feels a bit... hairy
<libv>
and some of the register level info is just copy pasted and conflicts with the capabilities claimed in the introduction(s)
<libv>
so wait and see
<wens>
only tests will reveil what actually is usable :|
<libv>
yeah
<libv>
hence me wanting to first go and try to use a known good hw camera module
<libv>
with a hand soldered .05" to FPC cable thingie (lime2), where i can just swap lines around
<libv>
will be noisy, and with no protection
<libv>
but better than trying to debug the whole
<wens>
well the ov5640 is probably the sensor you want
* libv
pulls out the bpi box from his pile of rubble
<wens>
or the ov7670, which does only VGA but sometimes comes on a board w/ proper 2.54mm pins
<libv>
5460
<libv>
is what bpi prefabricated
<libv>
so i can go verify functionality on csi0 on the bpi-m1
<wens>
I should probably write a CSI v4l2 usage mini howto
<libv>
wens: yes please!
victhor has quit [Ping timeout: 252 seconds]
shfil has joined #linux-sunxi
<megi>
I made bluetooth work on Orange Pi 3 :)
<megi>
it can't switch to higher baudrate for some reason yet, but it sees other devices, etc
<MoeIcenowy>
Finally got OV5640 of PineTab recognized
<MoeIcenowy>
but when trying to capture a photo w/ fswebcam
<MoeIcenowy>
I got `sun6i-csi 1cb0000.csi: Unsupported pixformat: 0x4745504a with mbus code: 0x2006!`
Mangy_Dog has quit [Remote host closed the connection]
<MoeIcenowy>
It means "GEPJ"?
<MoeIcenowy>
(thus is it MJPEG capture?
Andy-D has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
but the mbus code seems to be MEDIA_BUS_FMT_UYVY8_2X8...
<megi>
not supported by CSI ctl
<megi>
set pixfmt to V4L2_PIX_FMT_YUYV and mbus_format on subdev to MEDIA_BUS_FMT_YUYV8_2X8 or some such
<MoeIcenowy>
yes... maybe fswebcam does some weird thing
<MoeIcenowy>
oops
<megi>
hmm, csi code says V4L2_PIX_FMT_JPEG is supported
<megi>
but only for mbus fmt MEDIA_BUS_FMT_JPEG_1X8
<MoeIcenowy>
yes
<MoeIcenowy>
of course JPEG pix fmt needs JPEG mbus fmt
<megi>
so just try to set that on subdev
<megi>
and use V4L2_PIX_FMT_JPEG on /dev/video0
<MoeIcenowy>
megi: must applications be subdev aware to use this kind of pipeline?
<megi>
the final CSI driver doesn't try to autoselect subdev mbus formats
<megi>
so yes
<MoeIcenowy>
can CSI driver be made to autoselect subdev mbus format?
<megi>
previous iterations did the autosepection, but it was changed
<megi>
during upstreaming
<megi>
so I presume, it was rejected
<megi>
autoselection
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has left #linux-sunxi [#linux-sunxi]
Mangy_Dog has joined #linux-sunxi
<wens>
CSI mini-howto almost finished
<wens>
MoeIcenowy: the JPEG capture format still needs a bit of work
<wens>
MoeIcenowy: because the hardware can't tell how many bytes were captured, the full buffer is passed back to userspace
<wens>
MoeIcenowy: but FFMpeg doesn't trim off the unused portion if you tell it to just copy data through
<wens>
MoeIcenowy: and you'll end up with enormous JPEG files
<MoeIcenowy>
so I should temporarily revert 35deee14183457754f77e34dc92c588d93d40052 ?
<wens>
well, no, that means you can't use JPEG bus format
<wens>
JPEG bus format is only supported on a few sensors, such as OV5640, where the sensor does the JPEG encoding, and sends out the compressed file
<wens>
nice when you have bandwidth / cpu constraints
<MoeIcenowy>
now I understood why there's camera HAL in Android even if there's V4L2
<libv>
wens: :))))
<MoeIcenowy>
V4L2 totally failed to hide the details for SoC-attached sensor
<wens>
MoeIcenowy: the intent is actually to export that to userspace :)
<wens>
getting the desicion making out of the kernel and into the user's hands
dddddd has joined #linux-sunxi
<MoeIcenowy>
user is usually not so intelligent enough
<MoeIcenowy>
oh finally grabbed some image from this cursed ov5640
<MoeIcenowy>
BTW it's strange that CSI is always expecting 640x480...
<wens>
it's the default resolution, you can change it (and the bus format) using media-ctl
<KotCzarny>
640px will be enough for everyone!
<wens>
my howto covers it :)
jbrown has quit [Remote host closed the connection]
<MoeIcenowy>
BTW some strange behavior
<MoeIcenowy>
on my current boot
<MoeIcenowy>
which contains sun6i-csi and sunxi-cedrus
<MoeIcenowy>
/dev/video1 and /dev/media0 are cedrus
<MoeIcenowy>
/dev/video0 and /dev/media1 are csi
<wens>
issue with probe order it seems :/
<wens>
it happens on all my boards that have both enabled
<MoeIcenowy>
oh cursed when I set the ov5640 to 1280x720 mode
<MoeIcenowy>
the image is very pink
<wens>
you might want to check the data sample polarity
<megi>
ahh, bluetooth was failing, because the device needs longer time to come out of reset, than the mainline kernel gives
<wens>
megi: datasheet values?
<megi>
no idea
<MoeIcenowy>
btw I remember someone did bluetooth on rtl8723[bc]s
<megi>
no access
<MoeIcenowy>
who's him/her?
<MoeIcenowy>
anarsoul?
<megi>
I increased it from 10-20ms to 50ms
<megi>
and now it doesn't time out on trying to increase baudrate
<megi>
during probe
<wens>
MoeIcenowy: like three people did already, me, anarsoul, and some other guy
<megi>
wens: I've prepared some rtc patches for H6
<MoeIcenowy>
although to be honest I don't care a lot about BT
<megi>
H6 has special bit to enable exteral losc
<wens>
megi: ah cool, I never got around to it
<MoeIcenowy>
megi: in fact the H6 RTC is problemetic
<MoeIcenowy>
its power leak is much higher than expected
<MoeIcenowy>
so Allwinner suggests to add external RTC module if people really wants RTC
<megi>
and has a bit to bypass auto-switch to intosc if exterlan osc fails
<megi>
otherwise it's very similar to H5
<MoeIcenowy>
(so Pine H64 has a PCF RTC
<wens>
megi: annoying is that H6 has possible options for 2 24MHz crystals :/
<megi>
yeah
<wens>
as shown on page 349 of the manual
<wens>
which is why I mentioned it was slightly more complicated
<megi>
it's selected externally too
<megi>
btw, I'd rather not model ext_osc32k as a gated clock, just because aw decided to add enable bit in H6
<megi>
I just switch it on during re-parenting, for now
<MoeIcenowy>
wens: how to tweak the polarity?
<MoeIcenowy>
seems that every resolution > 640x480 has this problem
<MoeIcenowy>
but 640x480 is okay
<MoeIcenowy>
I tried 720x480, also very pink
<megi>
MoeIcenowy: hmm, that will not help the existing board designs
<megi>
MoeIcenowy: BT/WiFi is fed clock from the RTC
<megi>
MoeIcenowy: is it some hazard to use? or just a few mA?
<wens>
MoeIcenowy: pclk-sample property in DT
<wens>
the leak might be because the DCXO is still running even when everything is shut down
afaerber has joined #linux-sunxi
Wizzup has quit [Ping timeout: 264 seconds]
<MoeIcenowy>
wens: interesting
<MoeIcenowy>
libcamera has Android HAL support
<MoeIcenowy>
maybe it can be used when re-porting Android to Allwinner mainline kernel
<MoeIcenowy>
(but I still think the biggest blocker is lima
Wizzup has joined #linux-sunxi
airwind has quit [Quit: airwind]
<hramrach>
libv dhmi input sounds useful, What are the specs?
<libv>
hramrach: 1280x720@60 is the upper limit of the bus, and good enough for both the room camera and the speaker slides
<libv>
it remains to be seen whether we will actually hit that target
<libv>
at full 24bit rgb
<libv>
again, conflicting information
yangxuan has joined #linux-sunxi
<hramrach>
I am intereseted more like in 4k@1fps
gumblex has quit [Quit: ZNC 1.7.2+deb2 - https://znc.in]
gumblex has joined #linux-sunxi
<hramrach>
need pixel-perfect hi-res capture but don't need it fast. pre-made USB devices exist but they compress the image
<hramrach>
but capturing more data than the bus can transfer real-time would require some buffer somewhere and that probably does not exist in the device, right?
lurchi_ is now known as lurchi__
megi has quit [Ping timeout: 264 seconds]
<lavamind>
bbrezillon: any suggestions to debug ubiformat ?
yann has joined #linux-sunxi
<bbrezillon>
lavamind: did you try with flash_erase?
<lavamind>
bbrezillon: no not yet
<lavamind>
so flash_erase then try ubiattach ?
<lavamind>
of flash_rease + ubiformat
<lavamind>
or*
<bbrezillon>
flash_erase + ubiattach
<bbrezillon>
you'll loose erase counters
<MoeIcenowy>
hramrach, libv: remembered OPi3 is scheduling a H6 board w/ HDMI IN
<bbrezillon>
but at least we'll know if it's a problem in ubiformat or in the kernel implem
<MoeIcenowy>
(but as the CSI and RGMII is muxed on H6, the board features only FE, no GbE
<lavamind>
bbrezillon: I don't think the erase counters matter much, this NAND is practically new I've booted it like 4-5 times beofre this project
<lavamind>
flash_erase -N also hit a MEMERASE64 ioctl fail at the same eraseblock (50%)
<lavamind>
maybe the previous failed attempts at formatting the partition somehow damaged the block
jstefanop has joined #linux-sunxi
<wens>
MoeIcenowy: maybe android can use mesa + libdrm? :)
jstefanop has quit [Ping timeout: 250 seconds]
yangxuan has quit [Ping timeout: 252 seconds]
<bbrezillon>
lavamind: the block was marked bad
<bbrezillon>
the only way you can undo that is by using nand scrub in uboot
<lavamind>
bbrezillon: well flash_erase -N should ignore the BBT no ?
<lavamind>
ok I see
<bbrezillon>
lavamind: nope
<lavamind>
anyway, it doesn't really matter, it's only 1 block
<lavamind>
I'm going to try to actually try writing things to it now, but was missing UBIFS in the kernel heh
<bbrezillon>
still surprizing that ubiformat mess something up
<bbrezillon>
lavamind: was it working with a 2G part?
tllim has joined #linux-sunxi
<lavamind>
with the 2G part ubiformat was working out of the box, but I didn't try attach
selfbg has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
yangxuan has joined #linux-sunxi
megi has joined #linux-sunxi
<bbrezillon>
lavamind: ok, would be worth debugging ubiformat once you're done with your tests if you have a bit of time
<lavamind>
bbrezillon: I'd be happy to help with that
disik has quit [Ping timeout: 252 seconds]
<lavamind>
bbrezillon: I just rebooted the CHIP to load a new kernel, tried attaching again: "ubi0 error: ubi_add_to_av: two LEBs with same sequence number 3"
<bbrezillon>
duh
<lavamind>
bbrezillon: ok I think I know why
<lavamind>
after attaching the last time I did ubimkvol
<wens>
I won't get around to it, so if you see anything you like, feel free to pick them up
<wens>
oops... latest changes in mesa result in build fail for lima :(
<runtux>
@libv thanks for the email, I've sent mail.
<wens>
and, was fixed :|
<lavamind>
bbrezillon: I need to buy you a beer :P
<lavamind>
your patch fixed the ubiformat / ubiattach problem
<libv>
MoeIcenowy: hrm, that's the first i hear, but fosdem wants multiple things atm, and the a20 seems like a good fit
<lavamind>
now it works flawlessly, even after a reboot
<libv>
MoeIcenowy: we would miss out on sata for instance
<libv>
and a20 has the broadest software support currently
<anarsoul>
wens: I think you also need firmware-name for config in dt bindings
<KotCzarny>
libv: h3 isnt that much behind
<wens>
anarsoul: yeah, that part isn't finished
victhor has joined #linux-sunxi
shfil has quit [Quit: Connection closed for inactivity]
yangxuan has joined #linux-sunxi
reinforce has joined #linux-sunxi
random_yanek has quit [Quit: random_yanek]
Putti has quit [Remote host closed the connection]
<bbrezillon>
lavamind: great!
<bbrezillon>
would be even better if you could submit those patches :)
<lavamind>
bbrezillon: yes I'd like to do that
<lavamind>
but I'm wondering if it's even feasible since a) I'm not proficient in C even less kernel development and b) I'm not the author of the patches
<lavamind>
as I understand it, submitting patches isn't just sending an email with the patches attached, you need to answer questions and provide details
random_yanek has joined #linux-sunxi
yangxuan has quit [Ping timeout: 250 seconds]
<bbrezillon>
lavamind: yes
<bbrezillon>
:-(
<lavamind>
sorry... I'm happy to write some documentation though
<arc_phasor>
so it looks like my boot.cmd is doing a "fatload mmc 0 0x46000000 zImage". Is that loading the zImage file into an arbitrary space of DDR?
<arc_phasor>
I'm using an R16 and from the datasheet DDR starts at 0x40000000
<MoeIcenowy>
yes
<MoeIcenowy>
it's loading to DDR
<arc_phasor>
so why not load into 0x40000000, or 0x41000000... why was 0x46000000 chosen?
<MoeIcenowy>
I don't know
<MoeIcenowy>
usually it's loaded to 0x42000000
<arc_phasor>
am i missing out of 0x6000000 if i start it higher?
<arc_phasor>
67MB of ram just gone? wasted to the ether
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
shfil has joined #linux-sunxi
<lavamind>
bbrezillon: quite a large part of the patch set is "mtd: implement proper partition handling"
ganbold has quit [Client Quit]
Andy-D has quit [Ping timeout: 252 seconds]
ganbold has joined #linux-sunxi
<lavamind>
is that already working its way into mainline ?
Andy-D has joined #linux-sunxi
<lavamind>
if you're willing to sponsor it maybe I can help by porting that to linux-next ?
<lavamind>
if that goes in the rest of the patches are quite smaller
cmeerw has quit [Ping timeout: 250 seconds]
cmeerw has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
clementp has joined #linux-sunxi
<clementp>
arc_phasor: Maybe i will say something stupid but I think the start of the DDR is reserver for uboot itself (binary + memory)or could use it
<clementp>
if you load at 0x40000000 you will overwrite some u-boot memory and it may crash...
tnovotny has quit [Quit: Leaving]
<clementp>
0x6000000 is choose because it's a good size for uncompressing the Kernel if I remenber correctly
<clementp>
a minimal kernel for uncompressing is executed then the complete kernel will go at the start of the DDR
<arc_phasor>
clementp: makes sense to me, but is it right haha
random_yanek has joined #linux-sunxi
<mru>
the compressed kernel has to be loaded to a region that doesn't conflict with either u-boot or the final location of the decompressed kernel
<arc_phasor>
and then once it's decrompressed, that ram is cleared for other use. So it really isn't that critical on the initial location as long as it doesn't interfere with u-boot area
<clementp>
arc_phasor: Yes u-boot area + kernel uncompressed (as said by mru) One time I reduced this size, and a month after the kernel hangs up at boot because the kernel uncompressed was too big and overlap
clementp has quit [Quit: Page closed]
jstefano_ has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 240 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
shfil has quit [Quit: Connection closed for inactivity]