As my knowledge about the booting flow of a (embedded) Linux platform, there's a bootloader (e.g. U-Boot) running on the CPU first, then load the Linux kernel into memory.
While both U-Boot and Linux kernel can configure pin-define (or pin-mux), where should I decide where to put the pin-define code? If they define a pin into different pin-mux, will the U-Boot's define be overriden by Linux kernel's define?
While both U-Boot and Linux kernel can configure pin-define (or pin-mux), where should I decide where to put the pin-define code?
Regardless of what U-Boot does, you want the kernel to fully configure all pins to a state that the kernel expects/requires. Then the actual HW state is always consistent with what the software knows/assumes. Pin definitions in the Device Tree specify both pin multiplexing as well as ownership by a device. So you need to provide the Linux kernel with a Device Tree that fully specifies all pin usage of all devices.
For many SoCs, a pin that in not muxed for a peripheral function becomes an unused GPIO. So if you only multiplex such a pin in U-Boot for the peripheral, then, if that pin is left out of Linux's Device Tree, it could be inadvertently used as a GPIO, and interfere with the operations of the Linux device driver.
Pins and GPIOs are resources managed by the pinctrl and gpio subsystems of the Linux kernel. Providing incomplete specifications through the Device Tree could be considered a bug.
If they define a pin into different pin-mux, will the U-Boot's define be override by Linux kernel's define?
Yes, the more recent operation supplants the prior operation.