<freemangordon>
any hint where shall I start from in regards to uboot/usb?
<freemangordon>
I guess I shall pull latest master first, no?
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
BenLand100 has quit [Quit: s/BenLand100//]
<parazyd>
btw. on friday I'll do a talk about Leste on Bitreichcon gopher://bitreich.org/1/con/2021 gopher://bitreich.org/0/usr/20h/phlog/2021-06-13T16-57-32-547583.md
<parazyd>
2000 CET
<Pali>
freemangordon: yes, pull latest master and build u-boot via 'make'
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
<Pali>
it prints deprecated warning about rx51 and USB
<Pali>
and this needs to be resolved
<Pali>
make nokia_rx51_config && make CROSS_COMPILE=arm-linux-gnueabi-
<parazyd>
uvos: So regarding fbkeyboard, do you want it for devices like D4 and N900 too?
BenLand100 has quit [Quit: s/BenLand100//]
<mighty17[m]>
uvos is omap_drm supposed to be a module, I have it =y
<mighty17[m]>
Omap2plus defconfig didn't boot for me (don't know why no log just black screen)
<mighty17[m]>
So back to using my config (for now)
<uvos>
parazyd: no
<uvos>
parazyd: just no kbd deivces, but we need a way to boot to fbkyboard shell thats not dependant on the bootloader offering some kind mulitboot feature
<uvos>
mighty17[m]: jeah no shit it dosent work then
<uvos>
mighty17[m]: your not building the pvr module
diejuse has joined #maemo-leste
BenLand100 has joined #maemo-leste
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
belcher_ is now known as belcher
BenLand100 has quit [Quit: s/BenLand100//]
<mighty17[m]>
uvos: it works in pmOS xD
adc_ is now known as adc
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
uvos has quit [Quit: Konversation terminated!]
diejuse has quit [Quit: Leaving.]
joerg is now known as DocScrutinizer05
diejuse has joined #maemo-leste
<freemangordon>
Pali: thanks
<mighty17[m]>
@uvos: using drm as module, display doesnt seem to be working
<Pali>
freemangordon: warning message says that it is needed to migrate to DM USB... but I'm not sure if this is the right way as DM USB is for host mode (connecting USB disk to n900), but U-Boot uses USB only for periperal mode (exporting USB TTY to computer)
<Pali>
and it seems that neither musb peripheral drivers nor usbtty driver use DM USB
<freemangordon>
Pali: ok, will see
<Pali>
and I'm not sure what to do with it
<Pali>
plus DM USB depends on migration to device tree which n900 uboot does not use (device tree increase uboot size upper limit and does not have any advantages; so currently it is not used)
<freemangordon>
Pali: what benefits we have if n900 is kept upstream?
<Pali>
bug fixes, new features etc...
<Pali>
now we should be able to boot directly zImage kernels
<Pali>
without converting it to uImage
<freemangordon>
I see
<Pali>
fixed nand access, etc...
<freemangordon>
Pali: BTW, "[PATCH] nokia_rx51: Make onenand working" is merged, right?
<Pali>
yes, it should be!
<freemangordon>
ok
<freemangordon>
Pali: what about CONFIG_WDT?
<Pali>
for CONFIG_WDT I have sent patch months ago
<freemangordon>
Pali: hmm, it seems we shall enable CONFIG_USB_MUSB_GADGET and some serial gadget
<freemangordon>
n900 appears as a serial device now, right?
<Pali>
yes it appears as usbtty
<Pali>
USB CDC ACM
<freemangordon>
there should be serial gadget IIUC
<freemangordon>
Pali: seems we shall port f_acm from linux
<Pali>
why? there is already usbtty code working
<freemangordon>
as a gadget?
<Pali>
not as gadget but as a driver
<Pali>
which is already in use
<Pali>
I have fixed bugs in it half year ago
<freemangordon>
ok, lemme see what is going to happem
<freemangordon>
*happen
<Pali>
(I do not see reason/benefit for backporting additional driver if there is already one which is working and which was debugged to work properly)
<freemangordon>
ok
<freemangordon>
lemme try to enable that DM_USB first
<Pali>
new driver = new issues = new debugging
<freemangordon>
sure
<Pali>
I guess enabling DM_USB would not work because n900 does not use CONFIG_OF
<Pali>
and also I do not see any benefit for rewriting n900 code to CONFIG_OF - it does not bring any functionality, only bugs
<freemangordon>
but it will be dropped otherwise :)
<freemangordon>
also, how does i2c_dm works then?
<freemangordon>
didn't you send patches about that?
<freemangordon>
I don;t see them upstream
diejuse has quit [Quit: Leaving.]
<freemangordon>
oh, wait
<freemangordon>
it is there
<Pali>
DM I2C is there
<Pali>
DM I2C works with and also without CONFIG_OF
<Pali>
we are using variant without CONFIG_OF and data for i2c are stored in C struct
<Pali>
at the end of the file board/nokia/rx51/rx51.c
<Pali>
but DM USB somehow does not to load data from support C struct ... and therefore depends on CONFIG_OF
nohit has joined #maemo-leste
diejuse has joined #maemo-leste
<freemangordon>
ok, will look into it
diejuse has quit [Quit: Leaving.]
diejuse has joined #maemo-leste
peetah has quit [Read error: Connection reset by peer]
peetah has joined #maemo-leste
DocScrutinizer05 is now known as joerg
* enyc
meows
diejuse has quit [Read error: No route to host]
<enyc>
good to see channels all nicely active on libera now for all sorts, and interestingly [m] matrix connections here
<enyc>
but not main #matrix channles etc last I checked ;/
Buttercat has quit [Quit: Leaving.]
diejuse has joined #maemo-leste
diejuse has quit [Client Quit]
joerg is now known as DocScrutinizer05
freemangordon has quit [Ping timeout: 272 seconds]
DocScrutinizer05 is now known as joerg
freemangordon has joined #maemo-leste
<freemangordon>
Pali: so, you want migration to DT avoided?
<Pali>
DT is big, we do not have size for its support
<freemangordon>
but, we can;t have DM_USB without OF, IIUC
<freemangordon>
OF == DT, right?
<freemangordon>
DM_USB requires CONFIG_OF_CONTROL
<freemangordon>
ok, DT increases binary size by ~100k
<freemangordon>
and we have 256k, right?
<freemangordon>
Pali: ^^^
<Pali>
looks like that, but question is why DM USB needs OF control
<freemangordon>
Pali: did you hear from the maintainers after your last mail?
<Pali>
no
<Pali>
for other drivers there is DTS to Cstruct conversion function, so drivers works with DTS or without DTS
<Pali>
therefore devices can be initialized automatically from DTS
<Pali>
or manually by specifying them in board c file (like for rx51 i2c)
<freemangordon>
not usb it seems
<freemangordon>
maybe we shall patch it
tvall has quit [Ping timeout: 244 seconds]
venji10[m] has quit [Read error: Connection reset by peer]
ajr has quit [Read error: Connection reset by peer]
mighty17[m] has quit [Read error: Connection reset by peer]
scops has quit [Read error: Connection reset by peer]
tvall has joined #maemo-leste
scops has joined #maemo-leste
mighty17[m] has joined #maemo-leste
venji10[m] has joined #maemo-leste
ajr has joined #maemo-leste
<freemangordon>
but, if you look in the Makefile, it explicitly requires CONFIG_OF_CONTROL for USB
ikmaak2 is now known as ikmaak
<freemangordon>
Pali: do you define board_fdt_blob_setup() somewhere?
<Pali>
it defines probably because there is no conversion function... like for i2c
<Pali>
board_fdt_blob_setup is not defined, we do not have FDT = DT blob
<freemangordon>
so, we shall implement one, no?
<freemangordon>
(conversion function)
<Pali>
maybe?
<Pali>
but I still do not know if DM USB should / can be used for rx51 usbtty
<freemangordon>
where it is defined for i2c?
<freemangordon>
understandable, but what are the options?
<Pali>
omap_i2c_of_to_plat()
<Pali>
maybe other option is look how to use usbtty code without that "deprecated" warning
<freemangordon>
hmm, this looks like i2c is not converted to DT
<freemangordon>
that's why they use conversion function
<Pali>
omap_i2c_of_to_plat() is used for converting DTS to plat code
<Pali>
in rx51 we use plat code directly
<freemangordon>
exactly
<freemangordon>
i2c driver itself does not use DT, but plat struct
<freemangordon>
that
<freemangordon>
's
<freemangordon>
why the conversion
<freemangordon>
while DM_USB ises DT directly
<Pali>
and maybe it should use C structs too?
<freemangordon>
not sure
<freemangordon>
maybe
peetah has quit [Remote host closed the connection]
<freemangordon>
Pali: hmm, actually it seems the only places CONFIG_DM_USB is usb.c itself and 2 board files
<freemangordon>
so this is the same code, just trying to get its data from DT
peetah has joined #maemo-leste
<freemangordon>
BTW, any clue why DT support code is so big? 100k for parsing some binary blob seems like an overkill to me
<Pali>
because they are using standard fdt library for it, which is big
<Pali>
and also fdt blob itself is big for omap3/n900 (look into kernel)
<freemangordon>
hmm, OF_PLATDATA seems to be available, but for SPL/TPL only
<freemangordon>
hmm, they say DT overhead is 3k
<Pali>
this is also too big
<freemangordon>
ok, why don;t you ask the maintainers what to do there, as it is obviously that we have some size constrains
<Pali>
I have already wrote to ML... I'm not getting any responces to my patches and my emails
<Pali>
it look half of year once somebody respond
<freemangordon>
maybe ping thm
<freemangordon>
*them
<freemangordon>
I'll reply to your latest mail with my findings, lets see
<Pali>
I was sending periodic pings last year...
<Pali>
ok, try to write reply, maybe you will get responce more quickly
<freemangordon>
mhm
<freemangordon>
Pali: sorry, can;t recall, where this 256k limit comes from?
<Pali>
kernel starts at 256k offset
<Wizzup>
so this is for supporting attached kernel?
<freemangordon>
Pali: I guess we shall give up on that (attached kernel)
<Pali>
and does it makes sense to include tons of useless glue code?
<freemangordon>
no, for sure
<freemangordon>
ok, lemme write that mail and see
<Pali>
this looks like somebody really wants to remove n900 code from uboot...
<Pali>
...patches are waiting on ML without review/comments for half of year...
<freemangordon>
could be, seems FOSS is not what it used to be, see Xorg
<Pali>
... and a patch for removal n900 was sent prior reviewing/commenting pending patches...
<freemangordon>
Pali: any clue why it needs 100k for DT parsers? again, they say it should be 3k
<Pali>
I do not know
<Pali>
I know that DT parser and big DT blobs are also problem for boards with SPL builds
<Pali>
where space for SPL is also limited
<Pali>
due to this reason Marek worked on LTO support in U-Boot, to reduce final u-boot mage binary size
<freemangordon>
please have a look at of-plat.rst
<freemangordon>
oh, this linked
<freemangordon>
247312
<Pali>
"approximately 3KB on Thumb 2"
<freemangordon>
yes
<Pali>
but we do not use thumb2
<freemangordon>
so, 5k
<Pali>
so it is even bigger
<freemangordon>
ok, but not 100k
<freemangordon>
and I think we shall be able to shave 5k
<freemangordon>
if it comes to it
<Pali>
well, enabling DTS means to convert whole n900 code to DTS
<Pali>
which is tons of work
<freemangordon>
no, we can use OF_PLATDATA
<Pali>
plus, there would be issues like how to disable code which should not be touched by u-boot (as whole hw initialziation is done by nolo)
<freemangordon>
look at usb.c, DM_USB just changes the way it gets HW data from
<freemangordon>
nothing more
<freemangordon>
no code is being added/removed
<Pali>
but it looks like that ./common/usb.c contains code for USB host mode
<Pali>
all these we do not need
<Pali>
we do not use it in u-boot
<freemangordon>
so you say that usb.c is not compiled if DM_USB is not defined?
<Pali>
it is
<freemangordon>
so, what is the difference then?
<Pali>
I'm saying that most of that code is not used
<freemangordon>
host mode code is there with and without DM_USEB
<freemangordon>
sure
<freemangordon>
so? adding DM_USB_ROLE?
uvos__ has joined #maemo-leste
uvos__ is now known as uvos
<uvos>
Wizzup: im here if you are ready wrt mce
<freemangordon>
to not build hostmode code?
<Pali>
so looks like we just need something like U_BOOT_DRVINFO() for usb periphal mode
<freemangordon>
yes
<uvos>
Pali: forced move to OF is painfull for sure, but it seams to have done the kernel a lot of favors, so i can understand why uboot would like to follow
<freemangordon>
but it seems this works only if SPL is enabled
<freemangordon>
Pali: I see "select OF_LIBFDT if !OF_PLATDATA"
<Pali>
uvos: but u-boot is not operating system, for most boards it is just small bootloader
<uvos>
it still has to deal with the same shit as the kernel to initalize the hw
<uvos>
so it has the same problems as are solved by of in kernel
<Pali>
SPL binary is just for loading u-boot
<Pali>
uvos: yes, but n900 is somehow special as most of hw init is done by nolo... and we need this stuff to not be touched by u-boot
<uvos>
sure on n900 that may be true
<freemangordon>
Pali: yes, the point is that u-boot on n900 is not SPL
<Pali>
due to this stiff there were issues with emmc, i2c, onenand and freezes
<freemangordon>
hmm, wait, how U_BOOT_DRVINFOS() work in n900 board file?
<freemangordon>
Pali: ^^^?
<freemangordon>
according to doc it should not
<Pali>
no idea... it works fine
<Pali>
I just used same construction which was used in other board files
<freemangordon>
yes, I see, but...
<freemangordon>
Pali: I would say it does not
<freemangordon>
(work)
<freemangordon>
most probably because i2c is setup by nolo it works fine
<Pali>
both i2c, mmc and wtd is working fine!
<Pali>
I have tested it
<Pali>
and checked that relevant code is called
mardy has quit [Read error: Connection reset by peer]
<Pali>
I did it about half year ago (maybe more)
<Pali>
so it is possible if something was changed, then it does not work now
<Pali>
but at that time it for sure worked
mardy has joined #maemo-leste
<freemangordon>
look at i2c-uclass, it has #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) all over the place
<Pali>
and __omap24_i2c_setspeed is called during probing i2c driver
<freemangordon>
Pali: the point is that I think U_BOOT_DRVINFOS() in rx51_c are simply not compiled or ignored. Unless I don;t understand how is that supposed to work
<Pali>
they are not ignored for sure
<Pali>
otherwise my watchdog patch would not work
<Pali>
but I have tested that it correcly initalize and is reset function periodically called
<freemangordon>
hmm
<Pali>
so U_BOOT_DRVINFOS() in rx51.c must be compiled and loaded
<freemangordon>
ok, seems I need more time to think about that
<Pali>
U_BOOT_DRVINFO expands to ll_entry_declare which expands to __section(".u_boot_list_2_"#_list"_2_"#_name)
<freemangordon>
mhm
<Pali>
so something which is used by linked script
<freemangordon>
seems AM335X board code has something similar to what we need
<freemangordon>
Pali: how to check in Makefile is some config option is n?
<Pali>
ifeq ($(CONFIG_XYZ),y)
<freemangordon>
thanks
<Pali>
and then on next line endif
<freemangordon>
yeah
<Wizzup>
uvos: can we aim for say 1930?
lioh_ has joined #maemo-leste
<lioh_>
hi all. I am trying to follow the instructions on the wiki for my N900 but I always get this message: https://termbin.com/73ar
<lioh_>
do you have any idea what i am doing wrong?
<freemangordon>
you should be holding F while powering-on the device
<freemangordon>
sorry, 'U', not 'F'
<freemangordon>
lioh_: ^^^
<lioh_>
Thanks, worked now.
<lioh_>
Is there a way to increase the brightness in the tty?
<mighty17[m]>
@uvos ping, more updates tried mmc fix by tmlin.d doesnt seem to work, same rootfs issue, next is it necessary to build CONFIG_DRM and CONFIG_DRM_OMAP as modules as with that there is no display (maybe coz of mmc randomness)
Buttercat has joined #maemo-leste
<mighty17[m]>
can i flash maemo to emmc? would make things easier :P
<lioh_>
I have flashed it using the following command sudo ./0xFFFF -m test/u-boot-2013.04-2.bin -f and on boot i still have to always type run sdboot. Is there a way to automate that?
<uvos>
\me i think these kinds of statemens break it by creating invalid chars
<Wizzup>
uvos: finishing dinner here at a friend, 2030 ok, or too late? can also do earlier
* uvos
or rather these
<uvos>
this causes browsers to treat it as data instead of text
<uvos>
parazyd: maybe sanitize your input
<uvos>
Wizzup: that should be fine
<uvos>
parazyd: i also lack authority to build charge-mode please kick it and also give me rights.
<uvos>
mighty17[m]: this and omap2plus_defconfig not booting suggests you have not installed the modules properly as has been mentioned manny times allready
<uvos>
the modules should be in /lib/modules/$(uname -r)
<parazyd>
uvos: You can build it from IRC
<uvos>
parazyd: no i cant
<parazyd>
I haven't seen you try
<uvos>
it saies not authorized
<mighty17[m]>
uvos: it is in there (there used to be 5.10.x from the original img of d4 i placed 5.11.0 (exactly the uname -r) of the kernel there)
<mighty17[m]>
im still sus about the mmc randomness breaking and thus modules dont load or smth, can i flash in emmc?
<uvos>
sure you can flash it anywhere you want
<uvos>
as long as you change cmdline apropriately
<mighty17[m]>
how do i flash in emmc
<uvos>
mighty17[m]: fastboot
<uvos>
you can just flash the image of just the rootfs (not with boot and the mbr) via fastboot
<uvos>
to whereever
<mighty17[m]>
uvos Samsung has no fastboot
<mighty17[m]>
It's own Download mode
<uvos>
then i have no idea
<uvos>
right samsung uses its own propriatary bootloader setup instead of basing something of the common andorid bootloader system
<mighty17[m]>
What would be the fastboot cmd?
<mighty17[m]>
Or rather with twrp?
<uvos>
fastboot flash whatever image
<uvos>
no
<uvos>
whatever being a partition
<uvos>
twrp is mainly a piece of crap best avoided :P
<mighty17[m]>
Ugh I can try heimdall ig
<mighty17[m]>
Will try putting it in system partition
<mighty17[m]>
I don't think 2gb will fit there tho, don't wanna wipe my userdata
<mighty17[m]>
dont think heimdall supports .img :( well im stuck
lioh_ has quit [Quit: Leaving]
<uvos>
Wizzup: hi
<Wizzup>
hi!
<Wizzup>
let's chat mce
<uvos>
sure
<Wizzup>
should we go over the PRs one by one?
<uvos>
sounds sane
<Wizzup>
ok
<uvos>
ok starting with #32. this one simply makes devlock and tklock a lodable module and contains no functional changes]
<uvos>
actually thats not true
<uvos>
it also removes the kp event disable
<uvos>
this was a feature
<uvos>
where mce disabled the evdev devices using a kernel interface that was added to the n900 kernel by nokia
<Wizzup>
right, the /disable part
<uvos>
right
<Wizzup>
merging it locally now
<Wizzup>
sce
<Wizzup>
sec*
<uvos>
also i removed the usb_cable_trigger, this removes the device unlocking of the device on usb plug
<uvos>
this is a temporary thing only
<uvos>
i later added this to a common/different module
<uvos>
but that was after cmake
<uvos>
so for now merging the prs would make this not work
<uvos>
(note pluging in usb will still wake the device just not unlock it)
<Wizzup>
ok
<Wizzup>
ok, that merged
<Wizzup>
uvos: what's next?
<uvos>
i thought we where going in order
<uvos>
ok so the next one is #34
<uvos>
this makes dsme support a module
<uvos>
and contains no functional changes. the only major thing here is taht the request_*() functions
<Wizzup>
uvos: what's next => what is next in order, what number is what I meant
<uvos>
where turned into a data pipe system_power_request_pipe
<uvos>
this touches a lot of code
<uvos>
but its mostly a trival change
<uvos>
this is so that we can later have a more coherent plugin interface
<Wizzup>
righr
<Wizzup>
makes sense
<Wizzup>
let me review it briefly
<uvos>
also the --debug-mode flag of mce is gone
<Wizzup>
hm, it doesn't rebase cleanly on master
<uvos>
this simply disabled dsme support before
<Wizzup>
(makefile changes)
<uvos>
the same thing is now accived by not loading the module
<uvos>
Wizzup: ok
<Wizzup>
should be trivial
<uvos>
shal i rebase you will you?
<Wizzup>
maybe you can, if you have a moment
<uvos>
sure
<Wizzup>
the conflict is in the Makefile
<Wizzup>
between master and git://github.com/IMbackK/mce.git dsme-module
<uvos>
Wizzup: sure sec
Langoor has joined #maemo-leste
<Langoor>
Hey all! I'm having some issues with the pre-built images on the N900.. Flashed it to a microSD and it seems to boot fine, but the desktop enviroment seems to be broken.
<Langoor>
I get a lockscreen but only on the left-half of the LCD, when swiping to unlock the screen goes black