When you've designed a complicated piece of consumer electronics you send off for the first boards to be made, and at that point what you have is a non-functional object.
You know it should be able to display an animating clock, play a movie, read SD cards, etc. but it just sits there.
The process of getting it so that it'll do something is "bringing it up". This is where you find out any hardware problems that weren't in the simulation. If you're very good or very lucky there won't be too many, but there will be a few. Your objective is to check that all the intended features are there, and any problems can be worked around, or else you re-design and go around the loop again. A command line app that can detect the touch sensor raw output proves that's wired up correctly for example, no need to wait for the whizzy UI that'll use it.
Usually the software that's eventually supposed to run on this device does not yet exist. Probably the schedule says it will be available "next week" but it said that last month too. Even when it does exist, it is untested, and the combination of untested hardware and untested software is a recipe for frustration. So using Linux for "bring up" even when you intend to develop something in-house for the finished consumer product could make sense.