10:42 <Kwiboo> Tartarus: I am pretty sure that Merge patch series "pxe: Allow extlinux booting without CMDLINE enabled" broke booting using extlinux, at least my aarch64 test kernel no longer boots with "ERROR: booting os 'Invalid OS' (0) is not supported", looks like images.os.os is no longer set

13:05 <marex> Kwiboo: send a fix ?

13:28 <Kwiboo> marex: not sure how to fix it properly, the old code called do_booti() that would set images.os.os/arch, new code no longer calls do_booti(), it looks like images.os.os/arch may not be set in some situations because of this change

13:29 <Kwiboo> my local fix was just to rebase to a commit prior to that merge :-)

14:48 <CounterPillow> A good fix would be submitting a revert of the commit until its author acknowledges that it is not other people's duty to investigate and fix their broken code

16:08 <Tartarus> Kwiboo: Please post to the ML, thanks.

17:00 <Kwiboo> Tartarus: mail sent, digging little bit deeper it was not fully related to images->os.os being 0, instead an initial bootm_run_states(bmi, BOOTM_STATE_START) call no longer happens

17:01 <marex> CounterPillow: in other words, make other busy people even busier while you wait and demand them to fix your issue ... instead of lending a helping hand ...

17:02 <marex> Kwiboo: that is appreciated, really

17:08 <marex> Tartarus: you might wanna update the topic

17:19 <Tartarus> Kwiboo: thanks

17:20 <marex> Tartarus: thanks

17:33 <CounterPillow> marex: Yes.

19:04 <marex> CounterPillow: which is exactly how community based collaborative development cannot work, those contributors are not free of charge 24/7 available support engineers. Instead, it is up to the contributors to put effort into the project to keep it sustainable, if everyone was just taking from the project, it would fall apart.

19:04 <marex> its like an investment fund in a bank, people put in money, and eventually they get more money in return ; if people only pulled money out of it, they would end up with nothing in the end

19:06 <CounterPillow> I'm sure all the other people in your metaphor will be delighted when you invest some regressions into their code and then play by finders-keepers rules with the bugs.

19:12 <marex> frankly, I just fixed three bugs in ST code for them, they also fixed random stuff for me over the years, this is what I am talking about in collaborative development

19:15 <CounterPillow> Thank you for explaining the basic principles of free software to me, I was unaware. What does this have to do with you being made aware of a regression by your patch but then not caring about it because it's merged already and therefore somebody else's problem now?

19:16 <marex> CounterPillow: I never wrote people shouldnt report issues, just that they should try and help out fixing them as well.

19:17 <CounterPillow> I'll be sure to tell that to the maintainers reviewing my patches next time I submit something, it'll go over swimmingly.

19:19 <Tartarus> Can't, or won't fix. No, it's not appropriate to revert the changes just yet, the merge window hasn't even closed.

19:19 <Tartarus> And the linux kernel is not an ideal model for anything, arguably not even the linux kernel

19:29 <CounterPillow> I won't beat this dead horse any further because I don't want to turn a conversation I wasn't even involved in until I piped up into a needless flamewar, but if your attitude towards regressions in your patches changes as soon as a maintainer applies it then I don't think you're held to any noble principles of collaborative development, you've just stopped caring as soon as you no longer faced any consequences yourself.

19:30 <Tartarus> ... it wasn't marex's patch series? Is that the confusion point here perhaps?

19:33 <CounterPillow> Oh, okay that makes it a lot clearer

19:34 <CounterPillow> Yes just to be clear, I think the original *author* of the patch should own the regressions they introduce or get a revert before the release, not like random maintainers and contributors of u-boot.

19:35 <Tartarus> Ah, yes. I am hopeful Simon will take a look soon, and if not I might take a look as well, just not today.

19:35 <Tartarus> Kwiboo provided enough details it shouldn't be too hard to figure out what call got dropped where

19:37 <CounterPillow> (Had 2 hours of sleep followed by a 12 hour road trip so my context inference and tone are both at an all time low)

19:54 <yann-kaelig> Hello

19:55 <yann-kaelig> Well. I have upgraded u-boot to the last release and things have changed for my hdd-raid cubietruck subboard, for better but not for something that is working. Maybe I have missed an option in uboot ? This is what I get when I run scsi reset

19:56 <yann-kaelig> Reset SCSI > scanning bus for devices... > Target spinup took 0ms. > AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode > flags: ncq stag pm led clo only pmp pio slum part ccc apst > timeout exit!

19:57 <Tartarus> yann-kaelig: I would suggest using "git bisect" to track down what commit introduced the problem, since you're able to reproduce it, thanks

20:00 <yann-kaelig> Tartarus: Hi. Never use thar. How am I suppose to debug the issue. Do I need a serial connection, and more ? Do you have a link for an explanation ?

20:03 <yann-kaelig> An official u-boot link which will allow me to set up the base to subsequently collect the information usable by the devs

20:05 <yann-kaelig> I'm ok to do it, but not without knowing where I'm going, I have no time to waste

20:11 <marex> yann-kaelig: I vaguely recall some discussion about SATA PMP some time ago

20:11 <marex> yann-kaelig: but that must have been years

20:11 <marex> yann-kaelig: does it work if you plug in single SATA drive directly ?

20:12 <yann-kaelig> I have an ssd connected to the SATA Port. The subboard is configured to work as PM Mode. Here is the document of the subboard https://elty.eu/public/assets/HDD-RAID%20Hardware%20Development%20Guide%20V1.0.pdf

20:13 <marex> yann-kaelig: I mean, it is likely SATA PMP (Port MultiPlier I think is what it stands for)

20:13 <marex> yann-kaelig: that is standardized, but not all controller drivers can handle it

20:15 <yann-kaelig> Without the subboard I can boot from the SATA. The u-boot-sunxi-with-spl.bin is on my sdcard

20:16 <marex> so PMP support in the driver is likely broken

20:18 <marex> is that drivers/ata/dwc_ahsata.c that you use on the machine ?

20:18 <yann-kaelig> I have no idea. How can I know it ?

20:19 <yann-kaelig> find it

20:19 <marex> grep AHSATA .config in the build directory

20:19 <marex> if it is =y , then that is it

20:20 <marex> or just grep SATA .config or grep AHCI .config , see what you get

20:20 <yann-kaelig> # CONFIG_DWC_AHSATA is not set

20:21 <yann-kaelig> CONFIG_AHCI=y CONFIG_SCSI_AHCI=y #CONFIG_DWC_AHCI is not set # CONFIG_MTK_AHCI is not set CONFIG_SUNXI_AHCI=y

20:22 <marex> yann-kaelig: does the PMP work in Linux ?

20:23 <yann-kaelig> I do not understand the question. But Ican access the ssd partition if I boot my OS from the sdcard

20:23 <yann-kaelig> I can mount /dev/sda1 which is the SATA port0 from the subboard

20:24 <marex> yann-kaelig: can you access both drives ?

20:25 <marex> yann-kaelig: do a quick test ... => dcache off ; sata reset (or sata init or whatever you do)

20:25 <marex> yann-kaelig: does that make things work by any chance ?

20:25 <yann-kaelig> I do not have two drive to test it, but both SATA port work. Also when I run the scsi reset a LED show me that the port is activated

20:26 <yann-kaelig> I do not have sata command line

20:26 <yann-kaelig> only scsi

20:26 <marex> then scsi init it is

20:26 <yann-kaelig> ok, wait

20:26 <marex> yann-kaelig: also, do you have the entire fail log ?

20:27 <marex> (not just a few lines ? use paste.debian.net please)

20:28 <yann-kaelig> ok

20:29 <yann-kaelig> there is no dcache command line. Unknown command

20:31 <marex> yann-kaelig: set CONFIG_CMD_CACHE=y

20:31 <marex> yann-kaelig: do you have the full log from scsi init or scsi reset or whatever you use ?

20:32 <yann-kaelig> Log and u-boot terminal output are two different things ? Because this is all the output I got from scsi reset

20:32 <marex> you may also want to modify drivers/ata/ahci.c and drivers/ata/ahci_sunxi.c and put #define DEBUG on line 1, then rebuild , that should give you more information

20:33 <yann-kaelig> ok

20:33 <marex> yann-kaelig: oh ... because a lot of the messages are debug(), right, see above ^

20:36 <yann-kaelig> Well, I have a really short time each day, I will try this tomorrow afternoon, so if you have some other advises I'm listenning and I'm going to take notes

20:42 <yann-kaelig> Ok, I have to go. Thank you marex. CU later