Learning how to bring a board up is valuable, but it is not an everyday task. It is unlikely that you will ever need to do it again unless you change the hardware and even then if you are developing a family of products it doesn't always require as much work as the initial board.
In my opinion the most important aspect of the embedded design is learning to work under heavy constraints. It not uncommon to have only a few megs of ram and what most people would consider a slow processor(300Mhz for example). Another common issue is I/O constraints typical disk speed. For example, we have SSD on our product that has horrendous random access write performance. Unfortunately, a live system tends write small chunks of data at random locations on disk pretty frequently. We had to build a caching mechanism into our file system that attempted coalesce adjacent disk blocks in order to serialize disk writes to achieve bearable performance.
When most people think of the embedded programing the pretty much only think of drivers or talking to the hardware. That is part of it, but most of the development effort is done a layer up. So, like I have already mentioned, most embedded work is about working with limited resource. I would focus my efforts there.
The book Programing Pearls has discussions on number problems that I think are valuable to all programmers, but it certain has a lot of practical value for embedded programming. A lot of the problems discuss how to approach a problem from different angles or different resource constraints. It is worth a look.