Problems booting Debian on 88f6283

Can confirm LED works correctly!

USB, though, acts weird:

usb flash drives do not work

[  320.362159] usb 1-1.3: rejected 1 configuration due to insufficient available bus power

usb hdd spins up, but does not detect partitions.

Also, bash welcome line shows a hieroglyph instead of hashtag sometimes... That's new!

Quote

Can confirm LED works correctly!

Cool! that GPIOs 38 (red) and 39 (green). These 2 were easy to see in the patch.

I did not think GPIO 45 is the right one. u-boot uses GPIO 48 and 47.

u-boot

+		MPP45_GPIO,	/* USB_IND */
+		MPP46_GPIO, 	/* USB_RS_IND */
+		MPP47_GPIO,	/* RST_GE */
+		MPP48_GPIO,	/* RST_USB */

So let's try 46 next. If that does not work, we'll go back to 48 and figure out if there is other indirect causes.

-bodhi
===========================
Forum Wiki
bodhi's corner

gt,

Here is the updated DTB.

- USB power is GPIO 46.

-bodhi
===========================
Forum Wiki
bodhi's corner

No, no changes in USB

But here's something interesting about leds: green and red leds are not independent.
green default-on + red none = green on
green hearbeat + red none = red flashing (maybe greeen then red flashing, green is way darker)
green default-on + red mtd = green on, none on mtd iops

Maybe usb logic is alike and non-evident?



Edited 1 time(s). Last edit at 11/08/2022 04:42PM by gt.

gt,

> But here's something interesting about leds: green
> and red leds are not independent.

That's how LEDs usually work. Becasue the status LED could be green or red, or a mix.

> green default-on + red none = green on
> green hearbeat + red none = red flashing (maybe
> greeen then red flashing, green is way darker)
> green default-on + red mtd = green on, none on mtd
> iops

The status LED should be green (normal). When you play with the setting (i.e. echo a value to each trigger), you'd need to turn off the other. When both are on, it'll be come orange (or a shade that close to amber), or don't work correctly.

How many LEDs are on the outside of this box? and what are they (i.e what did you mean by "red mtd")?

>
> Maybe usb logic is alike and non-evident?

No, USB power (enable) GPIOs are independent from USB LED GPIOs. They don't have any relationship. If this box had a mixing logic then I did not see it in the patch.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 2 time(s). Last edit at 11/08/2022 04:53PM by bodhi.

I thought so, that the "both on" would produce orange, i.e. they would be independent, but no, it is not so.
greeen default-on + red default-on = no led!
green none + red none = red on


Red mtd is one of triggermodes in /sys/devices/platform/gpio-leds/leds/wtplug\:green\:stat/trigger
There's just one physical led, but it has two color modes.

And by alike I meant, that maybe, for example, reset usb port is not oneshot, but should be flipped back? But you're right, this is smth I don't know anything... So, it's just a guess



Edited 3 time(s). Last edit at 11/08/2022 05:03PM by gt.

gt Wrote:
-------------------------------------------------------
> I thought so, that the "both on" would produce
> orange, i.e. they would be independent, but no, it
> is not so.
> greeen default-on + red default-on = no led!
> green none + red none = red on

This is the case when I said "or don't work correctly" ! to test the LED correctly, you would do:

red none
green default-on

and

green none
red default-on

And do the same for heartbeat, always set the green and red LED to none before setting the green (or red) trigger to hearbeat,


>
> Red mtd is one of triggermodes in
> /sys/devices/platform/gpio-leds/leds/wtplug\:green\:stat/trigger

Oh, that's not usable. MTD trigger is there because the kernel can control it for boards that have MTD LEDs (usually on the motherboard, but not outside).

This kernel is built for many Kirkwood boards, so you see a lot of different triggers, but only a few can be used for each board.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 11/08/2022 05:10PM by bodhi.

red none
green default-on

=green

green none
red default-on

=red

green none
red heartbeat

=red flashing

green heartbeat
red none

=red flashing

>Oh, that's not usable. MTD trigger is there because the kernel can control it for boards that have MTD LEDs (usually on
>the motherboard, but not outside).

It's not a third led, it is a trigger for red or greeen leds, and it seems to make a signal when mtd device is accessed.
But in overall, this is not important. Steady green is all I could wish for, all above is just a new knob to study for me.

Quote

And by alike I meant, that maybe, for example, reset usb port is not oneshot, but should be flipped back? But you're right, this is smth I don't know anything... So, it's just a guess

It's a good guess. Because there are 3 GPIOs for USB, but we don't know exactly how 2 are used. Perhaps somewhere in the patch, but I could not see how the other 2 are used.

In the patch, upon initialization, GPIOs 47 and 48 are activated by u-boot. Usually only 1 GPIO is used for power enable. And that jive with the fact that only 48 is used for USB in there.

But the hardware might be weird that a combo is needed... who knows :)

-bodhi
===========================
Forum Wiki
bodhi's corner

Quote

green heartbeat
red none

That should be in this order:

red none
green none
green heartbeat

-bodhi
===========================
Forum Wiki
bodhi's corner

Yep, red flashing.
I do beleive that the engineer who made this device had some quirks, is all am saying. And this is relevant for usb gpio.

> I do beleive that the engineer who made this
> device had some quirks, is all am saying. And this
> is relevant for usb gpio.

You're probably right. A prime example is the Zyxel NSA325. The network activation sequence on that box is the weirdest that I've seen. Once in a while I tried to remove the quirks to see if works (we could have misinterpreted the intent).

Perhaps we can look at the kernel patch. And see if these appear anywhere

+ MPP45_GPIO, /* USB_IND */
+ MPP46_GPIO, /* USB_RS_IND */
+ MPP48_GPIO, /* RST_USB */

-bodhi
===========================
Forum Wiki
bodhi's corner

I'd bet this is where:

CONFIG_USB_251XHUB

+#if defined(CONFIG_USB_251XHUB) && !defined(CONFIG_WTPLUG_THINCLIENT)
+static int usb2514_hub_to_smbus(void)

The code above seems to be for the wtplug only.

-bodhi
===========================
Forum Wiki
bodhi's corner

--- arch/arm/configs/wtplug_defconfig (revision 0)
+++ arch/arm/configs/wtplug_defconfig (revision 1416)

+CONFIG_USB_251XHUB=y

-bodhi
===========================
Forum Wiki
bodhi's corner

Here's lsusb output, if that's of any use: http://sprunge.us/Nrp9oJ

gt,

Here is the new DTB. Please try 2 tests: 1st test with usb power hub, 2nd without the hub. And pastebin the logs (entire serial log) of these 2 tests.

BTW, does this box have i2c ?

-bodhi
===========================
Forum Wiki
bodhi's corner

Hi!
Here are dmesg logs. Is it enough, or serial log really important?

Also, no ic2 and no usb...

gt,

> Here are dmesg logs. Is it enough, or serial log
> really important?

dmesg is OK.

Also I noticed that you were booting with different root device in these 2 tests. It is best that you boot both cases the same way (not important in this test, but we would want to eliminate any unkown).

I'll upload another DTB.

-bodhi
===========================
Forum Wiki
bodhi's corner

So in this attached DTB version, I tried to use both GPIOs 46 and 48 (similar to the kernel patch). Please try and post dmesg output.

-bodhi
===========================
Forum Wiki
bodhi's corner

tested quickly - it's actually worse, now not only usb devices are not powering up, but also not detected

OK so I've put it back to use single GPIO 48. And reverse the polarity (just in case my assumption was wrong). Please try.

-bodhi
===========================
Forum Wiki
bodhi's corner